SQLError (Core)
The WMI ODBC adapter provides support for the return of the standard error codes as defined in Appendix A of the ODBC 2.0 Programmer's Reference and SDK Guide. (This resource may not be available in some languages and countries or regions.) These error codes correspond to the SQLSTATE code as defined in the ISO/IEC 9075-3:1995 CALL-LEVEL INTERFACE (SQL/CLI).
Note For more information about support or requirements for installation on a specific operating system, see Operating System Availability of WMI Components.
When the adapter finds an internal error, such as an invalid handle or memory allocation error, the adapter returns the appropriate SQLSTATE code, which consists of a text string that represents the component that originated the error and a text description of the error. This is in accordance with the guidelines that are established in the ODBC 2.0 Programmer's Reference and SDK Guide. (This resource may not be available in some languages and countries or regions.)
For example, if the adapter fails to allocate memory, the adapter reports the error with the following SQLSTATE codes.
| SQLSTATE code | Description |
|---|---|
| szSQLState | "S1001" |
| pfNativeError | NULL |
| szErrorMsg | "[Microsoft] [WBEM ODBC Driver] Unable to allocate sufficient memory" |
| pcberrorMsg | 68 |
If WMI returns an error code, the adapter qualifies the error message (szErrorMsg) to indicate that the error message originated in WMI. 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 SQLSTATE codes.
| SQLSTATE codes | Description |
|---|---|
| szSQLState | "S0002" |
| pfNativeError | NULL |
| szErrorMsg | "[Microsoft][WBEM ODBC Driver][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 useful in multiple-tier adapters. In accordance with ODBC guidelines, the adapter must have only one outstanding error per statement, connection, or handle. Thus, it is easy to discover where an error originated because an upstream component cannot alter error messages.