ado, ms sql server 'text' columns
-
i'm stuck im trying to save a text file to sql server(in a 'text' column ); have no problem with unicode text, but with non-unicode strings after saving to the sql server i read garbage from the columns here's my code _bstr_t bstr_text = adoStream->ReadText(adoStream->Size); // dumping bstr_text shows the text here in bstr_text is ok recSet->Fields->GetItem(item)->Value = bstr_text; // debugging down to Field20::PutValue shows that correct data is being put in the field
-
i'm stuck im trying to save a text file to sql server(in a 'text' column ); have no problem with unicode text, but with non-unicode strings after saving to the sql server i read garbage from the columns here's my code _bstr_t bstr_text = adoStream->ReadText(adoStream->Size); // dumping bstr_text shows the text here in bstr_text is ok recSet->Fields->GetItem(item)->Value = bstr_text; // debugging down to Field20::PutValue shows that correct data is being put in the field
If your source data is 8-bit character-oriented, you should use a
textcolumn and ensure that the client's thread locale is the same as the locale used by the column. If your source data is 16-bit character-oriented, use anntextcolumn. You should also usentextif your client's locale will be different from the server's. If you're just interested in storing and retrieving a file with no conversions at all, use animagecolumn to treat it as binary. Obviously you can't do full-text search on animagecolumn. When you assign acharstring to a_bstr_t, the conversion to Unicode is performed using the thread's default code page. When the opposite process occurs to store the data in the database, SQL Server uses the configured locale's code page. If the two settings don't match, the conversions may not be a round-trip. Stability. What an interesting concept. -- Chris Maunder -
If your source data is 8-bit character-oriented, you should use a
textcolumn and ensure that the client's thread locale is the same as the locale used by the column. If your source data is 16-bit character-oriented, use anntextcolumn. You should also usentextif your client's locale will be different from the server's. If you're just interested in storing and retrieving a file with no conversions at all, use animagecolumn to treat it as binary. Obviously you can't do full-text search on animagecolumn. When you assign acharstring to a_bstr_t, the conversion to Unicode is performed using the thread's default code page. When the opposite process occurs to store the data in the database, SQL Server uses the configured locale's code page. If the two settings don't match, the conversions may not be a round-trip. Stability. What an interesting concept. -- Chris Maunderthank you, but i know all of this already. i think i found the problem: it turns out that whenever i call _bstr_t bstr_text = adoStream->ReadText(adoStream->Size); no matter if the file is unicode or not, the data is saved to the wide char member of _bstr_t so some hacking is needed to get correct results with C char* data
-
thank you, but i know all of this already. i think i found the problem: it turns out that whenever i call _bstr_t bstr_text = adoStream->ReadText(adoStream->Size); no matter if the file is unicode or not, the data is saved to the wide char member of _bstr_t so some hacking is needed to get correct results with C char* data
Yes, this is because ADO is an Automation interface designed for access from Visual Basic, and hence uses
BSTRs throughout. It isn't really designed for use with C++. You can accesschar-based data directly, without intervening conversions to and from Unicode, using the OLE DB interfaces. Visual C++ supplies the OLE DB Consumer Templates, which can simplify the task somewhat. If you need to getchar-oriented data back out of aBSTR, seeWideCharToMultiByte. Stability. What an interesting concept. -- Chris Maunder -
Yes, this is because ADO is an Automation interface designed for access from Visual Basic, and hence uses
BSTRs throughout. It isn't really designed for use with C++. You can accesschar-based data directly, without intervening conversions to and from Unicode, using the OLE DB interfaces. Visual C++ supplies the OLE DB Consumer Templates, which can simplify the task somewhat. If you need to getchar-oriented data back out of aBSTR, seeWideCharToMultiByte. Stability. What an interesting concept. -- Chris Maunder