15 мая 2023 года "Исходники.РУ" отмечают своё 23-летие!
Поздравляем всех причастных и неравнодушных с этим событием!
И огромное спасибо всем, кто был и остаётся с нами все эти годы!

Главная Форум Журнал Wiki DRKB Discuz!ML Помощь проекту


ODBC Classes on MFC 4.2: Incompatibilities anyone?

'Just Ask' Dan Maher -- dmaher@apdi.net
Tuesday, July 30, 1996

Environment:  VC++ 4.2, Win 95
Actually, any 32-bit platform has this problem.

I had a couple ODBC/CRecordset-based applications that were working just
fine when compiled under 4.1, but when I recompiled under 4.2, there seemed
to be a few problems.  Both applications would give a "field truncated"
warning message when accessing tables containing large text objects.  (I'm
connecting to a MS-SQL 6.0 server).  This was a problem that 4.1 had at one
time, but I had followed a knowledge base article (I don't remember which
one) that gave a workaround that replaced RFX_Text for these fields.  This
workaround would no longer compile under 4.2, so I had to remove it.  (That
was OK, since the bug that was mentioned was fixed in the RFX_Text included
in MFC 4.2).  In any case, I gave in on one of the apps, which basically
only read the database, and turned my CString variables that were used for
the Text fields into CLongBinary.  This worked fine on this app.  The other
one, which accesses the exact same tables, I tried doing this with, but
another problem arose.  When I turned the variables into CLongBinary, the
field immediately following the CLongBinary gave a warning message saying
that the address of the field had changed when I attempted to write the
record.

I apologize if I don't have enough detailed information, since I have tried
a few other things since without much success.

If anyone else has had a similar problem, I would be interested in finding
out how you were able to overcome it.  If nobody else has had this problem
- what could I have done wrong in my code originally to cause this to
happen?






Zafir Anjum -- zafir.anjum@autodesk.com
Monday, August 05, 1996

I just moved from VC++ 4.0 to VC++ 4.2 and had similar problems. The 
reason for this is that RFX_Text changed its interpretations of the 
third argument (int nMaxLength = 255) in its implementation. In 
VC++ 4.2 if you do not specify this argument then trying to read any
field with more than 255 characters causes the "field truncated" 
warning.

The solution is to add the third argument to RFX_Text() and give it
a value large enough to hold the largest text in the problem field.

Zafir

At 01:35 PM 7/30/96 -0400, you wrote:
>Environment:  VC++ 4.2, Win 95
>Actually, any 32-bit platform has this problem.
>
>I had a couple ODBC/CRecordset-based applications that were working just
>fine when compiled under 4.1, but when I recompiled under 4.2, there seemed
>to be a few problems.  Both applications would give a "field truncated"
>warning message when accessing tables containing large text objects.  (I'm
>connecting to a MS-SQL 6.0 server).  This was a problem that 4.1 had at one
>time, but I had followed a knowledge base article (I don't remember which
>one) that gave a workaround that replaced RFX_Text for these fields.  This
>workaround would no longer compile under 4.2, so I had to remove it.  (That
>was OK, since the bug that was mentioned was fixed in the RFX_Text included
>in MFC 4.2).  In any case, I gave in on one of the apps, which basically
>only read the database, and turned my CString variables that were used for
>the Text fields into CLongBinary.  This worked fine on this app.  The other
>one, which accesses the exact same tables, I tried doing this with, but
>another problem arose.  When I turned the variables into CLongBinary, the
>field immediately following the CLongBinary gave a warning message saying
>that the address of the field had changed when I attempted to write the
>record.
>
>I apologize if I don't have enough detailed information, since I have tried
>a few other things since without much success.
>
>If anyone else has had a similar problem, I would be interested in finding
>out how you were able to overcome it.  If nobody else has had this problem
>- what could I have done wrong in my code originally to cause this to
>happen?
>
>
>
>





| Вернуться в корень Архива |