What is this 'Multiple-step OLE DB' error?
You may have seen this error:
This is often a datatype problem. Make sure you are passing valid datatypes to whatever is going on in the database. For example, check that you are not passing a NULL or empty string value to a column that doesn't accept them (either manually defined or, say, a DATETIME column). Make sure that all VARCHAR lengths and numeric bounds are adhered to. Make sure that you SELECT column1, column2, columns3 instead of using SELECT * (for other reasons, see Article #2096).
Danny's solution: I solved it by changing the field's datatype from varchar to nvarchar.
Turn on on error resume next, and check the errors collection of the connection object. For example:
If this doesn't yield enough information, you might get a better error message out of the database itself, so take the results of the response.write statement and issue it directly against the DB. If you are using an ADODB.Command object, you might consider re-writing your code to execute the stored procedure directly, instead of using the command object. (If you are relying on output or return parameters from the stored procedure, you will have to alter the procedure to return those values as a resultset.)
If you are using "Persist Security info" in your connection string, try disabling it temporarily.
If you are using Driver={SQL Server} in your connection string, try Provider=SQLOLEDB instead (or vice-versa).
If you are connecting via an ODBC DSN, try using a DSN-less connection (see Article #2126).
If you are using the AddNew/Update methods of ADODB.Recordset, consider not doing so. Use an UPDATE or INSERT statement instead. If you must, make sure you do an .UPDATE or .CANCEL before attempting to continue further work on this or another record. See KB #294160 for more info.
For a couple of other possibilities, see KB #253157, KB #269495, and KB #228935.
Microsoft OLE DB Provider for ODBC Drivers (0x80040E21) Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done. |
This is often a datatype problem. Make sure you are passing valid datatypes to whatever is going on in the database. For example, check that you are not passing a NULL or empty string value to a column that doesn't accept them (either manually defined or, say, a DATETIME column). Make sure that all VARCHAR lengths and numeric bounds are adhered to. Make sure that you SELECT column1, column2, columns3 instead of using SELECT * (for other reasons, see Article #2096).
Danny's solution: I solved it by changing the field's datatype from varchar to nvarchar.
Turn on on error resume next, and check the errors collection of the connection object. For example:
|
If this doesn't yield enough information, you might get a better error message out of the database itself, so take the results of the response.write statement and issue it directly against the DB. If you are using an ADODB.Command object, you might consider re-writing your code to execute the stored procedure directly, instead of using the command object. (If you are relying on output or return parameters from the stored procedure, you will have to alter the procedure to return those values as a resultset.)
If you are using "Persist Security info" in your connection string, try disabling it temporarily.
If you are using Driver={SQL Server} in your connection string, try Provider=SQLOLEDB instead (or vice-versa).
If you are connecting via an ODBC DSN, try using a DSN-less connection (see Article #2126).
If you are using the AddNew/Update methods of ADODB.Recordset, consider not doing so. Use an UPDATE or INSERT statement instead. If you must, make sure you do an .UPDATE or .CANCEL before attempting to continue further work on this or another record. See KB #294160 for more info.
For a couple of other possibilities, see KB #253157, KB #269495, and KB #228935.
No comments:
Post a Comment