[MFC/ODBC]- Problem with 'Query is too complex.'
oster David Phillip Oster
Wednesday, February 28, 1996
Kevin writes:
> I got an Error "Query is too complex." when executing Update(). But if I
>use m_pSet.AddNew() to add a new record, I can Update()then.
By chance, I just spent Tuesday solving this problem. I have a big Access Table:
roughly 70 double fields, with long field names. In general, I can AddNew into
the table, but I can't Edit(). My testers tell me that under Win95 I can't
even AddNew.
In the following discussion, in order to keep things terse, I've combine the
notions of a Class an a Object that is an instance of that Class. I trust my
meaning will be clear form context.
I solved the problem by defining two recordsets CSet1 and CSet2
CSet1 has the key fields and the front half of the fields of CSet,
CSet2 has the key fields and the back half of the fields of CSet.
I overrode CSet's Update handler so that if we are doing an Edit we
allocate a CSet1, set the filter string and the parameters to the key values
of the CSet, cset1.Open(), cset1.Edit(), cset1.CopyFrom(cset), cset1.Update()
where cset1.CopyFrom(cset) means copy the appropriate values from the CSet to
the CSet1.
CSet2 is handled the same way.
AddNew is handled the same way, except when the cset.IsNull(&cset.m_keyField)
since Update will create a new record, with a new m_keyField value, and like
the mean bully it is, it won't tell you what the value is.
I handle that by creating a new recordset that has a single field in it:
long m_maxValue;
then I open an instance of that recordset with the second parameter, the sql
string set to:
SELECT Max(keyField) AS maxValue FROM WideTable
this gives me the max value of my keyfield in CMaxSet.m_maxValue.
If the wide table has no entries, then cmaxSet.IsNull(&cmaxSet.m_maxValue)
will be true.
I assign the cset.m_keyField = cmaxSet.m_maxValue + 1,
do the addnew using CSet1, then do an Edit using CSet2.
--------------------------------------------
The above works fine in my test-bed program. My real program is another matter
however:
But, I still have a related problem. If I just write a few records and quit
the program, MFC's post-mortem memory dump says that I'm not leaking memory.
If I write 100 records, the system complains that I've run out of virtual
memory and my program (and all the other programs) hang. I can't pull
down menus without getting a system out-of-memory alert.
How do I begin debugging this?
What tests should I be doing with MFC's debugging allocator, or with PView
or what have you to track down what is going wrong?
Maybe you even know the answer to my problem off the top of your head?
Chris Newbold -- ChrisN@lpa.com
Monday, March 04, 1996
>But, I still have a related problem. If I just write a few records and quit
>the program, MFC's post-mortem memory dump says that I'm not leaking
memory.
>If I write 100 records, the system complains that I've run out of virtual
>memory and my program (and all the other programs) hang. I can't pull
>down menus without getting a system out-of-memory alert.
>
>How do I begin debugging this?
>What tests should I be doing with MFC's debugging allocator, or with PView
>or what have you to track down what is going wrong?
I don't know if the following applies in your situation, since you are (I
think)
using an Access database but...
In the course of developing our application (a front-end for an Oracle 7
database) we upgraded to VC++ 4.0 and installed the ODBC drivers that
were included on the CDROM. Sometime later, I noticed that our app was
bogging down badly, and the system (NT 3.51) was swapping like mad.
A little check with PView showed our app had over 48MB committed! A
serious memory leak. The MFC object dump was always clean, however.
Further invesigation revealed that we "lost" about 124KB _per database
query_.
It turned out to be the ODBC driver.... After switching to a third-party
ODBC
driver, all the problems vanished.
So, I'd be extremely suspicious of the drivers in the VC++ 4.0 box.
-Chris
| Вернуться в корень Архива
|