1

I'm working on some legacy C++ code that uses OLE DB to connect to a SQL Server database. I need to move from the old SQLOLEDB provider to a more modern one (SQLNCLI, SQLNCLI10, SQLNCLI11, or MSOLEDBSQL). Suposedly, this should be possible by just changing the provider, but I'm running into an 80040e21 error ("Multiple-step OLE DB operation generated errors") when I switch to any of the newer providers (the exact same error with all four listed providers). This happpens when calling Bind after adding bind entries for all columns. Digging around a bit, the error appears to be thrown when Bind calls IAccessor::CreateAccessor, and one of the columns is returning a bad bind status (DBBINDSTATUS_BADBINDINFO). The column in question is a VARCHAR(15), and the other column in my test table (an INTEGER) does not show a bad bind status. The DB type for the column is DBTYPE_STR, and the buffer has 24 bytes allocated for it (16 for data, 4 for length, and 4 for status).

The only documentation I've found related to DBBINDSTATUS_BADBINDINFO is at https://msdn.microsoft.com/en-us/library/ms720969.aspx, and none of the possible causes discussed there appear to apply to my case. Everything works fine (with the exact same table and parameters) when I switch the provider back to SQLOLEDB, so something must have changed in the SQLNCLI providers (as well as the new MSOLEDBSQL provider). Does anyone have any ideas about what might have changed in the newer providers to cause this (and what I might be able to do to resolve the error)?

the klaus
  • 81
  • 2
  • 5
  • Could this be a datatype compatibility issue described [here](https://learn.microsoft.com/en-us/sql/connect/oledb/applications/using-ado-with-oledb-driver-for-sql-server?view=sql-server-2017)? – Frank Alvaro Feb 04 '19 at 18:09
  • 2
    It turns out that the newer providers do some additional parameter checking. Our mistake was that the maximum buffer length we specified included the size of the length and status fields in addition to the data field. This meant that the data buffer could theoretically overlap with the length and status fields (which were located after the data field). This never actually happened, since we assumed that the maximum buffer length was the maximum size of all three fields, and we never put in more data than would fit in the data field. Thanks to Microsoft support, who helped us to resolve this. – the klaus Feb 27 '19 at 15:43
  • 1
    Good to hear it got straightened out, and +1 for the update – Frank Alvaro Feb 28 '19 at 16:22

0 Answers0