[This is preliminary documentation and subject to change.]
The adapter provides support for the return of the standard error codes as defined in Appendix A of ODBC 2.0 Programmer's Reference and SDK Guide. These correspond to the SQLSTATE code as defined in the X/Open and SAG SQL CAE Specification (1992).
When the adapter finds an internal error, such as an invalid handle or memory allocation error, it returns the appropriate SQLSTATE code, which is a text string the component originating the error, and a text description of the error. This is in accordance with the guidelines established in ODBC 2.0 Programmer's Reference and SDK Guide.
For example, if the adapter fails to allocate memory, it reports the error with the following arguments:
| szSQLState | "S1001" |
| pfNativeError | NULL |
| szErrorMsg | "[Microsoft] [WBEM ODBC Adapter] Unable to allocate sufficient memory" |
| pcberrorMsg | 68 |
If WBEM returns an error code, the adapter qualifies the error message (szErrorMsg) to indicate that the error message originated in WBEM. For example, if the client attempts to get the columns (properties) of a particular table (class), the adapter invokes the IMOSProvider::GetClass method. If GetClass returns OLEMS_E_INVALID_CLASS, the adapter reports the error with the following arguments:
| szSQLState | "S0002" |
| pfNativeError | NULL |
| szErrorMsg | "[Microsoft][WBEM ODBC Adapter][OLE MS] Invalid class name;Class XXXX.YYYY could not be found" |
| pcberrorMsg | 94 |
The general method of discovering errors is to invoke SQLError iteratively until it reports no more errors. This is particularly, though not exclusively useful in multitier adapters where a downstream component can report an error, and the upstream component may want to add its own error to this error, identifying itself as the discoverer. In accordance with ODBC guidelines, the upstream component does not alter error messages; rather, it adds its own error message. The adapter has only one outstanding error per statement, connection, or handle.