rdoError Object

Contains details about remote data access errors.

Remarks

Any operation involving remote data objects can potentially generate one or more ODBC errors or informational messages. As each error occurs or as messages are generated, one or more rdoError objects are placed in the rdoErrors collection of the rdoEngine object. When a subsequent RDO operation generates an error, the rdoErrors collection is cleared, and the new set of rdoError objects is placed in the rdoErrors collection. RDO operations that don't generate an error have no effect on the rdoErrors collection. To make error handling easier. you can use the Clear method to purge the rdoErrors collection between operations.

Generally, all ODBC errors generate a trappable Visual Basic error of some kind. This is your cue to check the contents of the rdoErrors collection for any and all errors resulting from the last operation which provide specific details on the cause of the error.

Not all errors generated by ODBC are fatal. In the normal course of working with connections, default databases, stored procedure print statements and other operations, the remote server often returns warnings or messages that are usually safe to ignore. When an informational message arrives, the rdoEngine InfoMessage event is fired. You should examine the rdoErrors collection in this event procedure.

If the severity of the error number is below the error threshold as specified in either the rdoDefaultErrorThreshold or ErrorThreshold property, then a trappable error is triggered when the error is detected. Otherwise, an rdoError object is simply appended to the rdoErrors collection. To control trappable errors in Microsoft SQL Server, you should use the Transact SQL RAISERROR statement coupled with an appropriate Severity argument to indicate the error or other information.

Use the rdoError object to determine the type and severity of any errors generated by the RemoteData control or RDO operations. For example, you can:

• Use the Description property to display a text message describing the error.
  
  
• Use the Number property to determine the native data source error number.
  
  
• Use the Source property to determine the source of the error and the object class causing the error.
  
  
• Use the SQLRetCode and SQLState properties to determine the ODBC return code and SQLState flags.
  
  
• Use the Clear method on the rdoErrors collection to remove all rdoError objects. In most cases, it is not necessary to use the Clear method because the rdoErrors collection is cleared automatically when a new error occurs.

Members of the rdoErrors collection aren't appended as is typical with other collections. The most general errors are placed at the end of the collection (Count -1), and the most detailed errors are placed at index 0. Because of this implementation, you can often determine the root cause of the failure by examining rdoErrors(0).

The set of rdoError objects in the rdoErrors collection describes one error. The first rdoError object is the lowest level error, the second is the next higher level, and so forth. For example, if an ODBC error occurs while the RemoteData control tries to create an rdoResultset object, the last rdoError object contains the RDO error indicating the object couldn't be opened. The first error object contains the lowest level ODBC error. Subsequent errors contain the ODBC errors returned by the various layers of ODBC. In this case, the driver manager, and possibly the driver itself, returns separate errors which generate rdoError objects.

The rdoErrors collection is also used to manage informational messages returned by the data source. For example, messages returned back from PRINT statements, showplan requests, or DBCC operations in SQL Server are returned as rdoError objects in the rdoErrors collection. This type of message causes the InfoMessage event to fire, but does not trip a trappable error. Because of this, you must check the rdoErrors collection's Count property to see if any new errors have arrived.