|
|
|
|
|
These are advanced technical options. They should only be used on advice from Cardett Associates.
By default, AQT runs a query by issuing the following ODBC calls: SQLPrepare then SQLExec. If this option is selected, AQT will use an alternate method, which is to run an SQLExecDirect only. For most databases, both methods work equally well, except:
SQLExecDirect cannot be used if your SQL contains a parameter marker. AQT will check your query for parameter markers - if it finds one it will use SQLPrepare/SQLExec rather than SQLExecDirect.
This option can be useful if you're having trouble displaying some data, in particular, invalid timestamps (which can happen in Oracle).
When fetching data from your database, AQT maps your database columns to variables of a similar type on your PC; for instance numeric columns are mapped to numeric fields on your PC, timestamp columns are mapped to the PC date/time structure. If your database has invalid data in a column, the ODBC Driver will not be able to deliver the data to the AQT and you will not be able to display your data.
By setting this option, AQT will map all database columns to strings in AQT; this provides a more reliable way of displaying your data, however AQT will not be able to format the numeric and timestamp columns.
This is similar ot Bind all cols to strings. When this is checked this will only be done for timestamp columns and not for columns of other types.
This gets the data from the database one value at a time, rather than one row at a time (which is the way AQT normally works). In some rare cases this can be a more reliable way of displaying your data, though it will be slower.
A query (such as the running of a Stored Procedure or a code-block) is able to return more than one result-set (eg. set of data). When this option is selected, AQT will be able to display these multiple result-sets.
By default, this option is on.
AQT processes multiple result-sets by, once it has retrieved the data for a result-set, by issuing an SQLMoreResults ODBC call to see if there is another result-set for the query. However, this ODBC call can cause problems for some databases. In this case you may wish to switch this option off.
This option will not be in effect for Sybase and SQL Server databases unless Allow multiple result-sets for Sybase, SQL Server and Teradata is also selected.
For Sybase, SQL Server and Teradata, the use of multiple result-sets can cause a severe performance problem. This is discussed in Multiple result-sets for Sybase, SQL Server / Teradata.
As a result, multiple result-sets will not be in effect for Sybase / MS SQL Server / Teradata unless both Enable Multiple Result-sets plus this option are checked.
This option is not saved between AQT sessions.
By default AQT ony supports signed integers; these take values -2147483647 to 2147483647.
For an unsigned integers, values between 0 and 2147483647 are displayed correctly. Values above 2147483647 are displayed as negative values. For example 4294967200 will be displayed as -96.
To display unsigned integers correctly, check this option.
The normal ODBC interface does not distinguish between signed and unsigned integers. When this option is checked, AQT will need to do some extra processing to determine whether an integer column is signed or unsigned.
This option is unchecked by default, as there is a chance that this processing might not work on some of the simpler ODBC Drivers.
This option controls the syntax that AQT uses when running a Stored Procedure which has no parameters.
When running a stored procedure which has parameters, AQT uses the syntax:
{ call procedure (parm1, parm2) }
When the procedure has no parameters, by default AQT uses the syntax:
{ call procedure }
This is the correct syntax according to the ODBC specification. However some databases will not allow this:
To prevent these, select this option. In this case AQT will use the following syntax:
{ call procedure () }