From: Martin on
On Mon, 15 Mar 2010 16:39:06 -0000, "Dave O." <nobody(a)nowhere.com>
wrote:

>
>"Martin" <ironwoodcanyon(a)gmail.com> wrote in message
>news:g6ksp5h3pj33q2k80v5bkglmbmucri1l13(a)4ax.com...
>> Yes, I could set a breakpoint here in my office on the development
>> machine but the problem is occurring only on the production version
>> running in a client's warehouse.
>
>Ask the customer for a copy of their database, I would not be shocked if
>they have managed to corrupt their database, perhaps they had a power outage
>or the PC crashed, or maybe they have cleared a table you never expected to
>be cleared.
>Eliminate user error before you waste ages looking for a programming error
>which may not exist.
>If you do find a problem with their database, then you should modify your
>program to allow for such issues.
>
>Dave O.
>

That's an excellent point, Dave. I probably need to persue that more
than I have.

FWIW, my program (which runs 24 hours a day), automatically shuts down
every night and launches another program which does a file clean up
(among other things it runs a DBEngine.CompactDatabase) and then it
re-starts. But, it could very well be that something is getting
damaged at random during the day and causing the crash.

We have instructed them to run the file cleanup program after the
program has crashed but I don't know for a fact if they are doing
that.

It still bothers me that the error trapping routines don't seem to be
catching anything though.


From: Martin on
On Mon, 15 Mar 2010 16:14:28 -0000, "Jon Lewis"
<jon.lewis(a)cutthespambtinternet.com> wrote:

>Replies in line:
>
>
>"Martin" <ironwoodcanyon(a)gmail.com> wrote in message
>news:g6ksp5h3pj33q2k80v5bkglmbmucri1l13(a)4ax.com...
>> Yes, I could set a breakpoint here in my office on the development
>> machine but the problem is occurring only on the production version
>> running in a client's warehouse.
>
>What about a compiled exe on your development m/c?
>
>>
>> FWIW, I have reviewed and exercised this whole thing throughly in the
>> office. Every record-access (edit / update / etc.) is preceeded by a
>> .NoMatch check.
>
>.NoMatch is different to .EOF though so have you tried .EOF?

No, I haven't. Where ever I'm doing a .seek the next statement is
always a .NoMatch. If it didn't find a record, then I take some action
and, if it did find the record, then I go on to .edit / .update it.

I did a little Googling just now but didn't come up with what the
difference is between .EOF and .NoMatch.

>>
>> I added the error trapping to try to identify where in the program
>> this is happening. And, BTW, the error trapping DOES trap this error
>> when I force it to occur while I'm running in the VB editor.
>>
>
>If you mean by Raising the same error number then I'm not sure that this
>would be the exact same circumstances or indeed the same error and also
>compile options may have a bearing on the different behaviour, others may be
>able to elucidate more.
>
>HTH
>

From: Jon Lewis on
..NoMatch being True means that a specific sought record could not be found.
A test for .EOF being true (immediately after opening the RecordSet) means
that there are no records i.e. the recordset is empty.

Like I said 'No Current Record' errors as most likely to occur with an empty
recordset.

HTH

"Martin" <ironwoodcanyon(a)gmail.com> wrote in message
news:u7qsp51t36bl48cr69o3fq73e0aufprfvc(a)4ax.com...
> On Mon, 15 Mar 2010 16:14:28 -0000, "Jon Lewis"
> <jon.lewis(a)cutthespambtinternet.com> wrote:
>
>>Replies in line:
>>
>>
>>"Martin" <ironwoodcanyon(a)gmail.com> wrote in message
>>news:g6ksp5h3pj33q2k80v5bkglmbmucri1l13(a)4ax.com...
>>> Yes, I could set a breakpoint here in my office on the development
>>> machine but the problem is occurring only on the production version
>>> running in a client's warehouse.
>>
>>What about a compiled exe on your development m/c?
>>
>>>
>>> FWIW, I have reviewed and exercised this whole thing throughly in the
>>> office. Every record-access (edit / update / etc.) is preceeded by a
>>> .NoMatch check.
>>
>>.NoMatch is different to .EOF though so have you tried .EOF?
>
> No, I haven't. Where ever I'm doing a .seek the next statement is
> always a .NoMatch. If it didn't find a record, then I take some action
> and, if it did find the record, then I go on to .edit / .update it.
>
> I did a little Googling just now but didn't come up with what the
> difference is between .EOF and .NoMatch.
>
>>>
>>> I added the error trapping to try to identify where in the program
>>> this is happening. And, BTW, the error trapping DOES trap this error
>>> when I force it to occur while I'm running in the VB editor.
>>>
>>
>>If you mean by Raising the same error number then I'm not sure that this
>>would be the exact same circumstances or indeed the same error and also
>>compile options may have a bearing on the different behaviour, others may
>>be
>>able to elucidate more.
>>
>>HTH
>>
>


From: John Simpson on

"Martin" <ironwoodcanyon(a)gmail.com> wrote in message
news:66gsp5p87is3hfngv9evg0fer91655ojmo(a)4ax.com...
> Using VB6 - SP5 MS Access (MDB) data file.
>
> I'm having problems with Error 3021 "No Current Record" error. I have
> reviewed the code - every .Update statement is preceded by either a
> .AddNew or a .Edit.
>
> In an attempt to find where this is occurring, I have every instance
> of data file access (seek/read - edit - addnew - update) surrounded
> with a "On Error GoTo" structure which will log the error to an event
> log that is already part of the program. But the program has crashed
> several times (with Error 3021) since that trapping was added.
>
> I just read KB106494 which is about this error. There is a sentence in
> there that says: "The On Error statement fails to trap this error."
> Huh ? Is this true?
>
> So, I have two questions:
>
> * does anything else besides .Update cause this error?
>
> * is it really true that this error is not caught by On Error?
>

Can you post the code?


__________ Information from ESET Smart Security, version of virus signature database 4946 (20100315) __________

The message was checked by ESET Smart Security.

http://www.eset.com



From: John Simpson on

"Martin" <ironwoodcanyon(a)gmail.com> wrote in message
news:jnpsp5paus1rlf160ousfl37o3dn7ba1kj(a)4ax.com...
> On Mon, 15 Mar 2010 16:39:06 -0000, "Dave O." <nobody(a)nowhere.com>
> wrote:
>
>>
>>"Martin" <ironwoodcanyon(a)gmail.com> wrote in message
>>news:g6ksp5h3pj33q2k80v5bkglmbmucri1l13(a)4ax.com...
>>> Yes, I could set a breakpoint here in my office on the development
>>> machine but the problem is occurring only on the production version
>>> running in a client's warehouse.
>>
>>Ask the customer for a copy of their database, I would not be shocked if
>>they have managed to corrupt their database, perhaps they had a power
>>outage
>>or the PC crashed, or maybe they have cleared a table you never expected
>>to
>>be cleared.
>>Eliminate user error before you waste ages looking for a programming error
>>which may not exist.
>>If you do find a problem with their database, then you should modify your
>>program to allow for such issues.
>>
>>Dave O.
>>
>
> That's an excellent point, Dave. I probably need to persue that more
> than I have.
>
> FWIW, my program (which runs 24 hours a day), automatically shuts down
> every night and launches another program which does a file clean up
> (among other things it runs a DBEngine.CompactDatabase) and then it
> re-starts. But, it could very well be that something is getting
> damaged at random during the day and causing the crash.
>
> We have instructed them to run the file cleanup program after the
> program has crashed but I don't know for a fact if they are doing
> that.
>
> It still bothers me that the error trapping routines don't seem to be
> catching anything though.

Have you tried:

If Err.Number = 3021 Then
do something
end if

John


__________ Information from ESET Smart Security, version of virus signature database 4946 (20100315) __________

The message was checked by ESET Smart Security.

http://www.eset.com