DAO Exception
Mike Lechner -- Mike_Lechner@msn.com
Wednesday, December 04, 1996
Environment: VC4.2b, Win95, Access7.0
Hello,
I'm writing an MFC app that uses CDaoRecordset-derived objects to manipulate
a MS Access database. During a query of the database (using FindFirst), a
CDaoException (3077-Syntax error in number in expression) is thrown. When I
catch the exception, the query string looks fine, and furthermore, the query
is identical to others that worked fine during the same execution of the app.
When the exception is thrown, I've made over 4000 successful queries into the
database.
For completeness, here's a sample of code that is failing:
// fFactor was opened in the constructor.
char query[256];
try {
// Build the query.
sprintf (query, "ID=%d AND ProgramID=%d AND Gender='%s'",
ID, programID, sex);
if (fFactor.FindFirst (query)) {
TRACE ("fFactor.FindFirst(%s) succeeded\n", query);
return TRUE;
}
TRACE ("fFactor.FindFirst(%s) returned FALSE\n", query);
return FALSE;
} catch (CDaoException* e) {
TRACE ("fFactor.FindFirst(%s) failed (%d-%s)\n",
query, e->m_pErrorInfo->m_lErrorCode,
e->m_pErrorInfo->m_strDescription);
}
Has anyone else seen this sort of behavior using CDaoRecordsets?
Thanks,
Mike
Michael Potter -- mpotter@ns.ezl.com
Saturday, December 07, 1996
[Mini-digest: 2 responses]
if ID and programID are integers in a 32 bit operating system isn't your
sprintf statement supposed to use %ld instead of %d?
Mike
----------
> From: Mike Lechner
> To: mfc-l@netcom.com
> Subject: DAO Exception
> Date: Wednesday, December 04, 1996 11:34 AM
>
> Environment: VC4.2b, Win95, Access7.0
>
> Hello,
> I'm writing an MFC app that uses CDaoRecordset-derived objects to
manipulate
> a MS Access database. During a query of the database (using FindFirst),
a
> CDaoException (3077-Syntax error in number in expression) is thrown.
When I
> catch the exception, the query string looks fine, and furthermore, the
query
> is identical to others that worked fine during the same execution of the
app.
>
> When the exception is thrown, I've made over 4000 successful queries
into the
> database.
> For completeness, here's a sample of code that is failing:
> // fFactor was opened in the constructor.
> char query[256];
> try {
> // Build the query.
> sprintf (query, "ID=%d AND ProgramID=%d AND Gender='%s'",
> ID, programID, sex);
> if (fFactor.FindFirst (query)) {
> TRACE ("fFactor.FindFirst(%s) succeeded\n", query);
> return TRUE;
> }
> TRACE ("fFactor.FindFirst(%s) returned FALSE\n", query);
> return FALSE;
> } catch (CDaoException* e) {
> TRACE ("fFactor.FindFirst(%s) failed (%d-%s)\n",
> query, e->m_pErrorInfo->m_lErrorCode,
> e->m_pErrorInfo->m_strDescription);
> }
>
> Has anyone else seen this sort of behavior using CDaoRecordsets?
> Thanks,
> Mike
-----From: Curt Sutherland
Environment: VC4.2b, WinNT 3.51, Access7.0
Regarding the DAO Exception from a query that worked multiple time previously,
I have seen the same error in my own code and under similar circumstances.
In my case, the valid range of one of the fields was being exceeded. (I.e.
the field was a byte and a number > 255 was being written). You should
verify that the value for the IDs are within the valid range.
Hope this helps,
Curt
Tim Robinson -- timtroyr@ionet.net
Thursday, December 12, 1996
At 13:50 12/7/96 -0600, Michael Potter wrote:
>[Mini-digest: 2 responses]
>
>if ID and programID are integers in a 32 bit operating system isn't your
>sprintf statement supposed to use %ld instead of %d?
>----
> From: Mike Lechner
>> // Build the query.
>> sprintf (query, "ID=%d AND ProgramID=%d AND Gender='%s'",
>> ID, programID, sex);
Mike L's original problem aside, the %d may be acceptable. The declarations
are missing, so I can't tell. If I recall from wallowing through the C spec
long ago, %d is supposed to print value of type 'int' whatever 'int' happens
to be for the compiler/processor in question. If the type was specifically
'long' then %ld should be used even if int=long. And if the type is 'short'
then %hd should be used (again, even if int=short). Cross platform people
are acutely aware of this, but it's easy to get sloppy working in a single
environment (no exception claimed for myself).
| Tim Robinson, Esquire | Liberty means responsibility. |
| timtroyr@ionet.net | That is why most men dread it. |
| http://www.ionet.net/~timtroyr | George Bernard Shaw |
| Вернуться в корень Архива
|