DB_E_ERRORSOCCURRED

inline void Field20::PutValue ( const _variant_t & pvar )

{

HRESULT _hr = put_Value(pvar); > where pVar is datetime value

if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));

}

The put_Value() method returns "DB_E_ERRORSOCCURRED" and the error description which i'm getting is "Multiple-step operation generated errors. Check each status value"

Can anyone please help me out of this.

Note: The above piece of code is working fine in SQL server 2000 but after migrating to SQL server 2005, i am getting this error.

http://www.support.microsoft.com/kb/223180

http://search.microsoft.com/results.aspx?mkt=en-US&setlang=en-US&q=DB_E_ERRORSOCCURRED

|||

I am also facing a similar problem

Any ideas, code working fine in sql 2000 is not working in sql 2005?

What could be the probable reasons?

|||

Hi,

The DB_E_ERRORSOCCURRED (with the Multistep operation failed...) is quite a generic message and may be raised in multiple locations in the Provider code.

My suggestion is to attack the problem from 2 sides:

(a) Capture a SQL Server 2005 Profiler trace, see if any errors would be indicated or anything alarming would show when attempting to set the Value property

(b) On the client, capture a BID trace to attempt to narrow the op which is returning the error. Detailed instructions can be found in the following article:

Data Access Tracing in SQL Server 2005 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/data_access_tracing.asp

Since SQL Native Client OLEDB provider contains more detailed BID tracing points, good idea is to use SQLNCLI as your Provider.

Based on the findings from these two, you should be able to determine what is wrong with the field's Value you are trying to set. Most likely you are running into a compatibility requirement for SQL 2005 or a case of a more strict requirement being enforced. If you don't manage to narrow the issue down, please provide a script for the underlying table/field creation + a simplified C/C++ repro code.

HTH,

Jivko Dobrev - MSFT

--
This posting is provided "AS IS" with no warranties, and confers no rights.

|||

Just to follow up on Jivko's points.

SQL 2005 is much stricter than SQL 2000 when evaluating incoming data at the lowest level (the TDS layer). We do this to ensure 100% data purity when data is inserted into the database. So one thing I would do is examine very closely the value of the incoming variant value that is failing, it is most likely an invalid datetime value like Feb 30th for example. Running a sql profiler trace that includes all errors should turn up some errors like:

The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Parameter X: The supplied value is not a valid instance of data type Y. Check the source data for invalid values. An example of an invalid value is data of numeric type with scale greater than precision.