Any idea why this is not working with the 2005 driver?
Thanks
_______________
Fabio F, Fullin
cel: 15-5479-1821
But in general I have not seen this happen with any of my .NET applications
as it is handled properly in ADO.NET.
HTH,
Plamen Ratchev
http://www.SQLStudio.com
"Plamen Ratchev" <Pla...@SQLStudio.com> wrote in message
news:a6qdnYVrYZawdqvV...@speakeasy.net...
"Plamen Ratchev" <Pla...@SQLStudio.com> wrote in message
news:876dnV-psaS_lKrV...@speakeasy.net...
while (!oRecordset->IsEOF())
{
oRecordset->GetFieldValue(1,oData);
if (oData.m_dwType == DBVT_ASTRING)
{
sAux = *oData.m_pstringA;
}
oRecordset->MoveNext();
}
If myText is Text or varchar(n) it works fine. But if myText is varchar(max)
*oData.m_pstringA points to an empty string.
My workaround for now is to change the query: "select cast(myText as
varchar(5000)) from myTable"
Thanks,
Diego
"Plamen Ratchev" <Pla...@SQLStudio.com> wrote in message
news:876dnV-psaS_lKrV...@speakeasy.net...
By the way, 1399 is the RTM version of SQL 2005. Maybe this is a bug
that is fixed in SP1 or SP2. So try installing SP2 and see if it helps.
--
Erland Sommarskog, SQL Server MVP, esq...@sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Wait, didn't you say that you were using ODBC? This looks like ADO
to me.
What does your connection string look like? If you have
PROVIDER=SQLNCLI, try adding DataTypeCompatibility=80 to the
connection string. ADO does not understand the new data types
added to SQL 2005 very well.
"Erland Sommarskog" <esq...@sommarskog.se> wrote in message
news:Xns9AA7F14D4...@127.0.0.1...
oRecordset->MoveNext looks awfully much like ADO to me.
> I define the connection using the odbc control panel and all.
But how does the connection string look like? If you are using ADO,
use the SQLNCLI provider, and add DataTypeCompatibility=80 to the
connection string.
Since you talk about ODBC, I assume that you use MSDASQL, that is
OLE DB over ODBC. I find it difficult to see any particular reason to
do this.
I am really not sure how those MFC classes recognize the new data types in
SQL Server 2005. Probably worth trying what Erland suggested to set
DataTypeCompatibility=80 in the connection string. I know that does the
trick for ADO.
Did you step through the code to see if the return type is really
DBVT_ASTRING? Just a guess here, but what if you add checks for DBVT_STRING
or DBVT_BINARY. Some frameworks recognize the new data types as binary
objects, so maybe reading as binary and then converting to string will do
it.