Configuration using DbInfo() Professional
Once a table is opened via the ODBCDBE, information about the used workarea can be obtained by calling function DbInfo(). Constants are available in ODBCDBE.CH that can be used for this purpose.
|ODBCDBO_CONCURRENCY||ro||N||ODBC concurrency setting as numeric ID.|
|ODBCDBO_CREATE_INDEX||a||L||If .T., INDEX ON will issue CREATE INDEX|
|ODBCDBO_CURSORTYPE||ro||N||ODBC cursor type as numeric ID.|
|ODBCDBO_DELETED_NAME||a||C||Name of the column to be used for DbDelete()|
|ODBCDBO_MORE_RESULTS||ro||N||Number of result set if more expected.|
|ODBCDBO_ODBC_TO_XPP||a||A||Array holding data type mapping information.|
|ODBCDBO_SCROLLABLE||ro||N||Scroll attribute of ODBC cursor as numeric ID.|
|ODBCDBO_SELECT_STMT||ro||C||SQL SELECT statement as string.|
|ODBCDBO_SENSITIVITY||ro||N||ODBC cursor sensitivity as numeric ID.|
|ODBCDBO_UNIQUE_FIELDS||a||A||Use these fields in SQL WHERE clauses for update/delete operations. It is an array of numeric field positions.|
Returns the current concurrency update scheme in use.
If this property is set to .T., the INDEX ON command will issue an CREATE INDEX to the data source. Normally, creating an index on the server should be left to the data model of the connected data source.
Returns the type of the cursor, see "Values for the ODBC cursor type".
The default behaviour of DbDelete() is not to delete the record physically but to mark for later deletion executed by DbPack(). This behaviour can only be achieved if the table has a field named "_DELETED" of the type Char(1). In some cases, the ODBC data source forbids this name or the appliaction already has such a delete field. Using the ODBCDBO_DELETED_NAME info slot allows the reconfiguration of that field name used by the ODBCDBE.
If the result set of interest is known in advance, it can be selected by setting the session property ODBCSSN_MORE_RESULTS before the execution and and ODBCDBO_MORE_RESULTS can be inquired to get the number of the result set after the execution. In this case, only one result set can be made available at a time. The numbering of result sets starts with 1.
If all result sets are to be retrieved, ODBC_MORE_RESULT_NEWAREA must be passed as soon as the current result set is not any longer of interest. After calling DbInfo( ODBCDBO_MORE_RESULTS, ODBC_MORE_RESULT_NEWAREA ), the next result set is made available in a new work. The work area of the previous result set is still open and status information are functional, but no operations like skipping, updating etc. can be performed any more. The new workarea will become the current workarea. If the current value is read by calling DbInfo( ODBCDBO_MORE_RESULTS ), zero is returned if the new area is opened, or ODBC_MORE_RESULT_NOMORE is returned to indicate that there are no more result sets available.
The special value ODBC_MORE_RESULT_AUTO will position to the first result set having columns, that is, it will skip all returned result sets that are produced by statements like INSERT, UPDATE etc.
This is is current the data type mapping how an ODBC data type is seen by Xbase++. A remap is possible if the data types are conversion compatible, like "C" and "M", or "D" and "T", or "N" and "I".
Returns ODBC_SCROLLABLE if a bidrectional navigation is possible. In other words, DbSkip(-1) won't work otherwise. Please pay attention to this flag if the application (ie. a browse function) requires this.
Returns the current SQL Select-statement.
Returns the current update-sensitivity.
An update (REPLACE) or delete operation should affect only one row of a table, but a result set of a SQL statement does not always have a unique record identifier, ie. no primary key defined, or the cursor is is not directly updatable. In this case, all available fields will be used to uniquely identify a row by default. This property can be retrieved to know which fields the record (row) identification is based on.
Normally, a primary key is set up on the table on the SQL server. However, since ODBC also works on drivers which might not have this feature or simply don't return the information, this property tells ODBCDBE what the primary fields are. The statements will be shorter, and probably will execute faster - but that also depends on the backend. It has no effect if updates are made on the cursor.
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.