This section explains the URL syntax supported by the JDBC driver.

You must not specify any spaces within an item or between items in a URL. Note that the item names are case sensitive.

(a) URL syntax

 
  jdbc:hitachi:hirdb[://[DBID=additional-connection-information]
                    [,DBHOST=database-host-name]
                    [,ENCODELANG=conversion-character-set]
                    [,HIRDB_CURSOR=cursor-operation-mode]
                    [,STATEMENT_COMMIT_BEHAVIOR=Statement-object-status-after-commit-execution]]
 

(b) Explanation of URL items

jdbc:hitachi:hirdb

This item consists of the protocol name, subprotocol name, and subname. You must specify this item. This item is case sensitive.

DBID=additional-connection-information

Specifies the port number of the HiRDB server (corresponds to the PDNAMEPORT value in the client environment definitions). You can also specify a HiRDB environment variable group for this item.

If no port number is specified for the HiRDB server, one of the following values becomes effective:

• The PDNAMEPORT value in the HiRDB client environment variables specified by HiRDB_for_Java_ENV_VARIABLES in the Properties argument of the getConnection method
• The PDNAMEPORT value in the environment variable group specified by DBID in the URL

For details about the specification priorities, see 17.11 Connection information priorities.

If neither value is specified, the getConnection method throws an SQLException when it executes.

Notes

You should note the following points about specifying an HiRDB environment variable group for the additional connection information:

• When you specify the name of the HiRDB environment variable group, specify @HIRDBENVGRP= followed by the absolute path name. If no value is specified after the equal sign, such as @HIRDBENVGRP=,, the JDBC driver assumes that no value is specified for this item.
• Note that an environment variable group name is case sensitive. Also, the environment variable group name depends on the OS.
• If the environment variable group name contains any single-byte space or single-byte @ characters, you must enclose the name in single-byte double quotation marks ("). When an environment variable group name is enclosed in single-byte double quotation marks, the characters from the closing single-byte quotation mark to the next setting item or to the final character are ignored. Note that an environment variable group that includes a single-byte quotation mark or a single-byte comma cannot be specified.
  Below are examples of specifications that trigger an error:
  

  @HIRDBENVGRP=/HiRDB_P/Client/HiRDB.ini @HIRDBENVGRP=/HiRDB_P/Client/HiRDB.ini @HIRDBENVGRP=/HiRDB_P/Client/HiRDB.ini @HIRDBENVGRP=/HiRDB_P/Client/HiRDB.ini

  Note: represents a single-byte space character.
  

DBHOST=database-host-name

Specifies the name of the HiRDB host.

When this specification is omitted, one of the following values becomes effective:

• The PDHOST value in the HiRDB client environment variables that were specified by HiRDB_for_Java_ENV_VARIABLES in the Properties argument of the getConnection method
• The PDHOST value in the HiRDB environment variable group that was specified by DBID in the URL

For details about the specification priorities, see 17.11 Connection information priorities.

If neither value is specified, the getConnection method throws an SQLException when it executes.

ENCODELANG=conversion-character-set

Specifies the conversion character set for the HiRDB character codes of the connection destination when the JDBC driver uses the String class to exchange data with HiRDB. Select a specifiable conversion character set from the encoding list shown under Internationalization in the Java^TM 2 SDK, Standard Edition documentation.

Table 17-2 lists the character codes of HiRDB and their corresponding conversion character sets.

Table 17-2 HiRDB character codes and corresponding conversion character sets

HiRDB character codes (character code set with pdntenv or pdsetup command)	Conversion character set to be specified
lang-c	ISO8859_1
sjis	SJIS or MS932#
ujis	EUC_JP
utf-8	UTF-8
chinese	EUC_CN

#

The specification of SJIS or MS932 depends on the handling of Windows special characters in the application.

When OFF is specified, the JDBC driver operates assuming that the conversion character set for the HiRDB character codes shown in Table 17-2 was specified. If the HiRDB character code set is sjis, the conversion character set determined by the OS running the JDBC driver is as follows:

For UNIX: SJIS

For Windows: MS932

Note that the specification is case sensitive (except for OFF).

If a conversion character set that is not supported by the Java Virtual Machine is specified, the JDBC driver throws an SQLException during connection with the HiRDB server.

If this specification is omitted, the JDBC driver converts characters using the appropriate conversion character set shown in Table 17-2. However, if one of the following is specified, the JDBC driver converts characters by using the default conversion character set of the Java Virtual Machine:

• Specification value for the UAP name (value specified by the UAPNAME property)
• Authorization identifier or password (value specified by the getConnection method)
• Specification value for the client environment definition specified by EnvironmentVariables
• Specification value for an environment variable specified by the environment variable group name of the HiRDB client

HIRDB_CURSOR=cursor-operation-mode

Specifies whether objects of the ResultSet class are to be validated or invalidated after HiRDB executes commit processing.

TRUE: Validate objects of the ResultSet class even after commit processing.

FALSE: Invalidate objects of the ResultSet class after commit processing.

If this specification is omitted, FALSE is assumed.

If a value other than TRUE or FALSE is specified, the JDBC driver throws an SQLException.

If an invalidated ResultSet object executes an operation other than calling the close method, the JDBC driver throws an SQLException.

Note

For notes about specifying HIRDB_CURSOR, see (c) Notes about specification of HIRDB_CURSOR and STATEMENT_COMMIT_BEHAVIOR.

STATEMENT_COMMIT_BEHAVIOR=Statement-object-status-after-commit-execution

Specifies whether objects of the Statement and PreparedStatement classes (referred to collectively hereafter as Statement) are to be validated or invalidated after HiRDB executes commit processing.

TRUE: Validate Statement objects even after HiRDB executes commit processing.

FALSE: Invalidate Statement objects after HiRDB executes commit processing.

The entities that are invalidated after commit execution are SQL statements that were precompiled by the prepareStatement method of the Connection class, and ResultSet class objects obtained by the executeQuery method of Statement.

If this specification is omitted, TRUE is assumed.

Note

For notes about specifying STATEMENT_COMMIT_BEHAVIOR, see (c) Notes about specification of HIRDB_CURSOR and STATEMENT_COMMIT_BEHAVIOR.

(c) Notes about specification of HIRDB_CURSOR and STATEMENT_COMMIT_BEHAVIOR

The notes that follow apply to specification of HIRDB_CURSOR and STATEMENT_COMMIT_BEHAVIOR.

When TRUE is specified in HIRDB_CURSOR or STATEMENT_COMMIT_BEHAVIOR

• If the value of the PDDDLDEAPRP client environment definition is NO and another user executes a definition SQL statement for a schema resource (table or index) to be accessed by a SELECT, INSERT, DELETE, UPDATE, PURGE TABLE, or CALL statement, the definition SQL statement remains in lock-release wait status until the connection that was accessing the schema resource is disconnected.
• If the value of the PDDDLDEAPRP client environment definition is YES and another user executes a definition SQL statement for a schema resource (table or index) to be accessed by a SELECT, INSERT, DELETE, UPDATE, PURGE TABLE, or CALL statement, the preprocessing result of the SELECT, INSERT, DELETE, UPDATE, PURGE TABLE, or CALL statement becomes invalid. If an SQL statement with an invalid preprocessing result is executed, an SQLException occurs (the value obtained by the getErrorCode method is -1542).
• When TRUE is specified for HIRDB_CURSOR or STATEMENT_COMMIT_BEHAVIOR,^#1 the only precompiled SQL statements^#2 that are valid after execution of commit processing^#3 are the SELECT, INSERT, DELETE, UPDATE, PURGE TABLE, and CALL statements.

#1

This also applies to either of the following specifications:

• TRUE is set for the following items in the properties specified by the getConnection method:
  HIRDB_CURSOR
  HiRDB_for_Java_STATEMENT_COMMIT_BEHAVIOR
  
• true is specified by the following methods of the PrdbDataSource, PrdbConnectionPoolDataSource, or PrdbXADataSource class:
  setHiRDBCursorMode
  setStatementCommitBehavior
  

#2

SQL statements are precompiled by execution of the prepareStatement method of the Connection class.

#3

In addition to explicit commit processing by the commit method, the following cases also apply:

• Implicit commit processing by the AUTO commit mode
• Execution of a definition SQL statement
• Execution of the PURGE TABLE statement
• Implicit rollback processing by the rollback method
• Implicit rollback processing because of an SQL execution error

In the case of SQL statements other than SELECT, INSERT, DELETE, UPDATE, PURGE TABLE, and CALL, precompiled SQL statements become invalid during commit processing.

If a PreparedStatement class object that stores an invalidated precompiled SQL statement is used in executing the SQL statement, an error occurs. Shown below is an example that triggers an error:

PreparedStatement pstmt1 = con.prepareStatement("lock table tb1"); PreparedStatement pstmt2 = con.prepareStatement("lock table tb2"); pstmt1.execute(); //Triggers an error. con.commit(); pstmt2.execute(); //Does not trigger an error. pstmt1.close(); pstmt2.close();

Because the SQL statements to be executed in this example are LOCK statements, after commit processing is executed, PreparedStatement becomes invalid and an error occurs, even if TRUE is specified for STATEMENT_COMMIT_BEHAVIOR.

• When TRUE is specified for HIRDB_CURSOR, the JDBC driver uses the holdable cursor facility of HiRDB.

Combinations of HIRDB_CURSOR and STATEMENT_COMMIT_BEHAVIOR specification values

Table 17-3 shows whether ResultSet and Statement objects are validated or invalidated after commit execution for each combination of HIRDB_CURSOR and STATEMENT_COMMIT_BEHAVIOR specification values.

Table 17-3 Status of ResultSet objects and Statement objects after commit execution

STATEMENT_COMMIT_BEHAVIOR specification value	HIRDB_CURSOR specification value
	TRUE	FALSE
TRUE	ResultSet object: Valid Statement object: Valid	ResultSet object: Invalid Statement object: Valid
FALSE		ResultSet object: Invalid Statement object: Invalid

Table 17-4 shows the return value of the DatabaseMetaData method for each combination of HIRDB_CURSOR and STATEMENT_COMMIT_BEHAVIOR specification values.

Table 17-4 Return values of the DatabaseMetaData method

STATEMENT_COMMIT_BEHAVIOR specification value	HIRDB_CURSOR specification value
	TRUE	FALSE
TRUE	supportsOpenStatementsAcrossCommit: true supportsOpenCursorsAcrossCommit: true	supportsOpenStatementsAcrossCommit: true supportsOpenCursorsAcrossCommit: false
FALSE		supportsOpenStatementsAcrossCommit: false supportsOpenCursorsAcrossCommit: false

Examples of JDBC driver operation during COMMIT execution

The operation of the JDBC driver during COMMIT execution depends on the specification values of HIRDB_CURSOR and STATEMENT_COMMIT_BEHAVIOR.

Specification examples

[A] pstmt1=con.prepareStatement("select c1 from tb1"); [1] [B] rs1=pstmt1.executeQuery(); [2] [C] rs1.next() [3] [D] v1=rs1.getInt(1) [4] [E] rs1.next() [5] [F] v1=rs1.getInt(1) [6] [G] rs1.close() [7]

Driver operation at COMMIT execution

COMMIT timing	H=T and S=T#1	H=F and S=T#2	H=F and S=F#3
[A]	[1]-[7]: Operates normally.
[B]	[1]-[7]: Operates normally.		[1], [2], and [7]: Operates normally. [3]-[6]: Throws an SQLException.
[C]	[1]-[7]: Operates normally.	[1], [2], and [7]: Operates normally. [3]-[6]: Throws an SQLException.
[D]	[1]-[7]: Operates normally.	[1]-[3] and [7]: Operates normally. [4]-[6]: Throws an SQLException.
[E]	[1]-[7]: Operates normally.	[1]-[4] and [7]: Operates normally. [5] and [6]: Throws an SQLException.
[F]	[1]-[7]: Operates normally.	[1]-[5] and [7]: Operates normally. [6]: Throws an SQLException.
[G]	[1]-[7]: Operates normally.

#1: This represents the case when TRUE is specified for both HIRDB_CURSOR and STATEMENT_COMMIT_BEHAVIOR.

#2: This represents the case when FALSE is specified for HIRDB_CURSOR and TRUE is specified for STATEMENT_COMMIT_BEHAVIOR.

#3: This represents the case when FALSE is specified for both HIRDB_CURSOR and STATEMENT_COMMIT_BEHAVIOR.

Other notes

For notes about the PDDDLDEAPRP client environment definition, see 6.6.4 Environment definition information.

For details about the rules for the DECLARE CURSOR holdable cursor, see the manual HiRDB Version 8 SQL Reference.

Table 17-5 shows the properties that you can specify in the getConnection method of the DriverManager class. If the null value is specified for a property, the JDBC driver assumes that specification was omitted.

Table 17-5 Properties that can be specified in the getConnection method

(a) user

Specifies the authorization identifier.

If the null value is specified, the JDBC driver assumes that no authorization identifier was specified. If the character string has a length of 0, the JDBC driver throws an SQLException.

If this specification is omitted, either the PDNAMEPORT specification value in the HiRDB client environment definitions specified by HiRDB_for_Java_ENV_VARIABLES in the Properties argument of the getConnection method, or the PDUSER specification value in the HiRDB environment variable group specified for DBID in the URL becomes effective. For details about the specification priorities, see 17.11 Connection information priorities.

If neither value is specified, the JDBC driver throws an SQLException when the getConnection method is executed.

(b) password

Specifies the password.

If the specification value is the null or has a length of 0, the JDBC driver assumes that no password was specified.

For details about when this specification is omitted, see 17.11 Connection information priorities.

(c) UAPNAME

Specifies UAP identification information (UAP identifier) for accessing the HiRDB server.

In the following cases, the JDBC driver assumes that no authorization identifier was specified:

• The null value is specified.
• A character string with a length of 0 or a character string of only single-byte space characters is specified.

For details about character strings that can be specified, see the description of the PDCLTAPNAME client environment definition in 6.6.4 Environment definition information.

For details about when this specification is omitted, see 17.11 Connection information priorities.

Note

The UAP specified by this property is encoded in the conversion character set specified by ENCODELANG, and the first 30 bytes of the encoded UAP identifier are transferred to the HiRDB server (if the UAP identifier consists of more than 30 bytes, it is truncated to the first 30 bytes). Therefore, the UAP identifier that the HiRDB server can obtain is up to the first 30 bytes after the identifier has been encoded.

(d) JDBC_IF

Specifies whether or not a JDBC interface method trace is to be obtained.

ON: Obtain a JDBC interface method trace.

OFF: Do not obtain a JDBC interface method trace.

If this specification is omitted, OFF is assumed.

If any other value is specified, the JDBC driver throws an SQLException.

If the setLogWriter method has not specified valid log data, the specification of this property is disabled.

For details about the JDBC interface method trace, see 17.12 JDBC interface method trace.

(e) TRC_NO

~<unsigned integer>((10-1000))<<500>>

Specifies the number of entries in the JDBC interface method trace.

The specification of this property is enabled when both of the following conditions are satisfied:

• The setLogWriter method has set valid log data.
• ON is specified for JDBC_IF.

If the specification of this property is enabled but the specification value is invalid, the JDBC driver throws an SQLException.

For details about a JDBC interface method trace, see 17.12 JDBC interface method trace.

(f) ENCODELANG

Specifies the conversion character set for the HiRDB character codes of the connection destination when the JDBC driver uses the String class to exchange data with HiRDB.

Select a specifiable conversion character set from the encoding list shown under Internationalization in the Java^TM 2 SDK, Standard Edition documentation.

For details about the HiRDB character codes and their corresponding conversion character sets, see Table 17-2.

When OFF is specified, the JDBC driver operates assuming that the conversion character set that Table 17-2 shows for the HiRDB character codes was specified. If the HiRDB character codes are sjis, the conversion characters determined by the OS running the JDBC driver are as follows:

For UNIX: SJIS

For Windows: MS932

Note that the specification is case sensitive (except for OFF).

If a conversion character set that the Java Virtual Machine does not support is specified, the JDBC driver throws an SQLException during connection with the HiRDB server.

If this specification is omitted, the JDBC driver converts characters using the conversion character set specified by ENCODELANG in the URL.

(g) HIRDB_CURSOR

Specifies whether objects of the ResultSet class are to be validated or invalidated after HiRDB executes commit processing.

TRUE: Validate objects of the ResultSet class even after commit processing.

FALSE: Invalidate objects of the ResultSet class after commit processing.

If this specification is omitted, the value specified by HIRDB_CURSOR in the URL becomes valid. If a value other than TRUE or FALSE is specified, the JDBC driver throws an SQLException.

If an invalidated ResultSet object executes an operation other than calling the close method, the JDBC driver throws an SQLException.

Note

For notes about specifying this property, see (1)(c) Notes about specification of HIRDB_CURSOR and STATEMENT_COMMIT_BEHAVIOR.

(h) LONGVARBINARY_ACCESS

Specifies the method of accessing a JDBC SQL-type LONGVARBINARY (BLOB and BINARY types, which are HiRDB data types) database.

REAL: Access the database using real data.

LOCATOR: Access the database using the locator facility of HiRDB.

If this specification is omitted, REAL is assumed.

If any other value is specified, the JDBC driver throws an SQLException.

Note

For notes about specification of this property, see (q) Notes about specification of LONGVARBINARY_ACCESS.

(i) HiRDB_for_Java_SQL_IN_NUM

~<unsigned integer>((1-30000))<<300>>

Specifies the maximum number of input ? parameters in the SQL statements to be executed.

This specification becomes the number of input ? parameters that are obtained during SQL preprocessing. If the actual number of input ? parameters is greater than the specification value of this property, the JDBC driver gets the input ? parameter information from the HiRDB server after SQL preprocessing.

If the specification value is invalid, the JDBC driver throws an SQLException.

Note

If you will not be executing SQL statements that have input ? parameters, you should specify 1.

(j) HiRDB_for_Java_SQL_OUT_NUM

~<unsigned integer>((1-30000))<<300>>

Specifies the maximum number of output items for the SQL statements that are to be executed.

This specification becomes the number of output items obtained during SQL preprocessing. If the actual number of output items is greater than the specification value of this property, the JDBC driver gets output item information from the HiRDB server after SQL preprocessing.

If the specification value is invalid, the JDBC driver throws an SQLException.

Note

If you will not be executing SQL statements that have output items, you should specify 1.

(k) HiRDB_for_Java_SQLWARNING_LEVEL

Specifies the retention level for warning information that is issued during execution of SQL statements. For details about the retention levels for warning information, see 17.4.10(2)(b) Issuing conditions for SQLWarning objects.

IGNORE: Retain warning information at the IGNORE level.

SQLWARN: Retain warning information at the SQLWARN level.

ALLWARN: Retain warning information at the ALLWARN level.

If this specification is omitted, SQLWARN is assumed.

If the specification value is invalid, the JDBC driver throws an SQLException.

(l) HiRDB_for_Java_ENV_VARIABLES

Specifies environment variables of the HiRDB client, using the following format:

 
  variable-name=value;variable-name=value;...;variable-name=value
 

For details about client environment definitions supported by the JDBC driver, see 17.10 Supported client environment definitions. If a client environment definition that is not supported by the JDBC driver is specified in a variable name, the JDBC driver ignores the specification. Note that variable names are case sensitive.

For details about the priorities for connection information that can be specified in multiple ways, see 17.11 Connection information priorities.

Specification example

java.util.Properties prop;
prop=new java.util.Properties();
prop.setProperty("HiRDB_for_Java_ENV_VARIABLES",
 "PDFESHOST=FES1;PDCWAITTIME=0");
 

(m) HiRDB_for_Java_STATEMENT_COMMIT_BEHAVIOR

Specifies whether Statement objects are to be validated or invalidated after HiRDB executes commit processing.

TRUE: Validate Statement objects after commit processing.

FALSE: Invalidate Statement objects after commit processing.

The objects that are invalidated after commit execution are SQL statements that were precompiled by the prepareStatement method of the Connection class, and ResultSet class objects obtained by the executeQuery method.

If this specification is omitted, the value specified for STATEMENT_COMMIT_BEHAVIOR in the URL becomes effective.

Note

For notes about specification of this property, see (1)(c) Notes about specification of HIRDB_CURSOR and STATEMENT_COMMIT_BEHAVIOR.

(n) HiRDB_for_Java_LONGVARBINARY_ACCESS_SIZE

~<unsigned integer>((0-2097151))<<0>> (kilobytes)

Specifies the length of JDBC SQL-type LONGVARBINARY data to be requested at one time to the HiRDB server. If LONGVARBINARY_ACCESS specifies data other than LOCATOR data, this specification is invalid.

For example, suppose that 20 is specified for this property and the getBytes method of ResultSet attempts to get 100 kilobytes of JDBC SQL-type LONGVARBINARY data stored in the database. In such a case, the JDBC driver gets and returns the data by dividing the operation into five executions of 20 kilobytes each. If 0 is specified, the JDBC driver requests the data all at once.

If the specification value is invalid, the JDBC driver throws an SQLException.

Note

For notes about specification of this property, see (q) Notes about specification of LONGVARBINARY_ACCESS.

(o) HiRDB_for_Java_MAXBINARYSIZE

~<unsigned integer>((0-2147483647)) (bytes)

Specifies the maximum data size during acquisition of JDBC SQL-type LONGVARBINARY data.

When the JDBC driver is getting JDBC SQL-type LONGVARBINARY data, it allocates memory of the defined length because it cannot determine the actual data length until it actually gets the data. Therefore, to get the value of a string for which the specified size is large (for example, 2,147,483,647 bytes, which is the maximum length for HiRDB's BINARY and BLOB data types), the JDBC driver attempts to allocate 2,147,483,647 bytes of memory, because that is the defined length. Consequently, a memory shortage may occur, depending on the execution environment.

You should specify for this property the maximum length of the data that is actually stored. If the data length of the BINARY or BLOB data to be acquired is larger than the size specified by this property, the JDBC driver truncates the acquired data to the specified size. When the JDBC driver does truncate data, it receives a warning from the HiRDB server when it executes the next method of ResultSet. In response to the received warning, the JDBC driver throws an SQLException or generates (or ignores) an SQLWarning, as determined by the specification of setLONGVARBINARY_TruncError.

If no upper limit is set by this property, the defined length of the target acquisition data becomes the upper limit.

If the specification value is invalid, the JDBC driver throws an SQLException.

Note

When LOCATOR is specified for LONGVARBINARY_ACCESS, the specification value of this property becomes invalid. The JDBC driver allocates an area based on the actual data length and gets the entire data.

(p) HiRDB_for_Java_LONGVARBINARY_TRUNCERROR

Specifies whether an exception is or is not to be thrown if truncation occurs during acquisition of JDBC SQL-type LONGVARBINARY data.

TRUE: Throw an exception if truncation occurs.

FALSE: Do not throw an exception if truncation occurs.

If this specification is omitted, TRUE is assumed.

If IGNORE is specified for HiRDB_for_Java_SQLWARNING_LEVEL, the JDBC driver operates as if FALSE were specified for this property.

Any truncation that occurs during acquisition of JDBC SQL-type LONGVARBINARY data indicates that the following condition is satisfied:

 
Actual length of JDBC SQL-type LONGVARBINARY data obtained during SQL execution > data length specified by HiRDB_for_Java_MAXBINARYSIZE
 

(q) Notes about specification of LONGVARBINARY_ACCESS

These notes apply to specification of LONGVARBINARY_ACCESS.

When LONGVARBINARY_ACCESS is specified together with HiRDB_for_Java_LONGVARBINARY_ACCESS_SIZE

Table 17-6 describes the differences in how the JDBC driver gets BLOB and BINARY data (HiRDB data types) based on the HiRDB_for_Java_LONGVARBINARY_ACCESS_SIZE and LONGVARBINARY_ACCESS specifications.

Table 17-6 Differences in how the HiRDB driver gets BLOB and BINARY data (HiRDB data types)

Execution method		LONGVARBINARY_ACCESS specification value
		REAL	LOCATOR
ResultSet.next		Gets all of the BLOB or BINARY data from the connected database.	Gets the locator that indicates the BLOB or BINARY data in the connected database, instead of all of the BLOB or BINARY data.
ResultSet.getBytes ResultSet.getString ResultSet.getObject		Uses the BLOB or BINARY data obtained by ResultSet.next.	Divides the BLOB or BINARY data into ACCESSSIZE x 1024-byte units and gets all of the data from the connected database.
Blob.getBytes		Extracts and gets the data range specified by the argument from the BLOB or BINARY data obtained by ResultSet.next.	Divides the BLOB or BINARY data range specified by the argument into ACCESSSIZE x 1024-byte units, and gets the data range from the connected database.
ResultSet.getBinaryStream ResultSet.getAsciiStream ResultSet.getUnicodeStream Blob.getBinaryStream		When the InputStream read method obtained by the executed method is executed, the JDBC driver extracts and gets data from the BLOB or BINARY data obtained by ResultSet.next.	When the InputStream read method obtained by the executed method is executed, the JDBC driver gets data from the connected database.
Blob.length		Gets the data length from the BLOB or BINARY data obtained by ResultSet.next.	Gets the data length from the connected database.
Blob.position		Gets the position of the data matching the search pattern from the BLOB or BINARY data obtained by ResultSet.next.	Gets the position of the data matching the search pattern from the connected database.
InputStream obtained by ResultSet.getBinaryStream or Blob.getBinaryStream	InputStream.available	Returns a value equal to or less than the length of the actual data indicated by the locator.	Returns a value equal to or less than ACCESSSIZE x 1024 bytes.
	InputStream.skip	Skips reading of the range up to the length of the actual data indicated by the locator.	Skips reading of the range up to the maximum ACCESSSIZE x 1024 bytes.
getCharcterStream ResultSet.getCharacterStream		When the Reader read method obtained by getCharcterStream is executed, the JDBC driver extracts and gets data from the BLOB or BINARY data obtained by ResultSet.next.	When the Reader read method obtained by getCharcterStream is executed, the JDBC driver gets data from the connected database.

Legend:

ACCESSSIZE: Specification value of HiRDB_for_Java_LONGVARBINARY_ACCESS_SIZE

InputStream and Reader: Classes of objects returned by getBinaryStream, getAsciiStream, or getCharacterStream of the JDBC driver

Notes about execution performance

When LOCATOR is specified for LONGVARBINARY_ACCESS, execution performance may drop compared to when REAL is specified.

When REAL is specified, the JDBC driver accesses the connected database once during ResultSet.next processing to get the locator. On the other hand, when LOCATOR is specified, in addition to the one access during ResultSet.next processing, the JDBC driver accesses the connected database once to get the data length and once to get the data during execution of a data acquisition method such as getBytes.

Notes about data operations after the transaction terminates

When LOCATOR is specified for LONGVARBINARY_ACCESS, data operations cannot be performed if the transaction terminates during the period between acquisition of the SQL execution results (ResultSet.next) and the data operation (such as Blob.getBytes or InputStream.read). Data operations cannot be executed after the transaction terminates even if the HIRDB_CURSOR specification is TRUE.

Thus, you must ensure that all data operations will execute before the transaction terminates.