The assertion occurs in line 274 of dbrfx.cpp. A trace message of also
appears:
Error: field address (column 6) has changed!
I am using VC 5 SP3. As far as I can see what's happening is this:
The application talks to an ODBC-compliant database, using the MFC ODBC
classes. My CRecordset-derived class holds a number of data members,
including a number of CStrings. At a certain point, AddNew() is called
on the open recordset. I believe that this performs an ODBC bind operation
with each of the data members' data. Then the new data is added to the
recordset. For primitive datatypes this isn't a problem - while the data
may have changed, the address in which such data is held has not.
However with a CString object, it is possible that in assigning a new
(larger) value, that the CString object is forced to re-allocate memory.
So now the earlier AddNew() operation which was meant to bind that CString's
data to a particular column is now invalidated. As a result, the debug
version of MFC throws up this assertion.
Questions:
1. Is my diagnosis essentially correct?
2. The best way around this?
Ed Barrett
Software Developer
Sysgenics Ltd.
We had problems when we used CString::Format() on the CRecordset data
members. Format() attempts to calculate the size of the destination string
based on the format characters. It's an estimate that is often way larger
than necessary.
You can get around this problem by using an intermediate CString:
CString strTemp;
strTemp.Format("%s", m_strField1);
m_strField1 = strTemp;
I hope this helps!
--
Steve
To reply, change .com to .gov
Ed Barrett wrote in message ...