Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Andrzejek on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Error 5 while sitting on 'read events'?

Status
Not open for further replies.

tetsuo3030

Programmer
May 5, 2005
16
US
Hi.

I am getting Error 5: Record out of Range..but in a manner I haven't seen before. Usually, the origin of this error is some piece of code that is directly setting the record pointer outside of the current range of the table...this case is a little different.

The Error 5 origin in this case is a method who has been sitting on a call from 'read events' since the .exe starts running. There is a form active at the time of the error which holds a grid. The grid's datasource is the 'Currently Selected Table' when the Error 5 occurs. This error happens randomly, of course, to the user..

I just can't figure out how I could be getting this error from a method who is sitting on 'read events'? I've heard that perhaps some VFP "native code" might be causing the error before it ever gets a chance to enter our code..and that would explain why the origin of the error appears to be this method. But if that's the case, what kind of VFP Native Code would cause an Error 5?

Anybody got any ideas? Thanks alot.
 
This is caused by an index problem, or by a call to move the record past the EOF or before BOF.

When the error happens make sure you record it to another dbf with the line, error message, current dbf, open form etc. Send the exe out with debug set on also to help in debugging.

The read events has nothing at all to do with the error. Read events just puts fox in a wait state.

Don Higgins
 

There are several reasons why an error can appear to occur while you are at READ EVENTS. It's usually because of some code being executed that's not in the event loop. For example, it might code in an ON KEY LABEL, or in an Access or Assign method, or even in a stored procedure.

By the way, a similar situation can arise with modal forms, where the debugger shows you are sitting on the DO FORM command.

Your best bet is to do as Don suggests: output as much information about the error as possible, and ignore the fact you are on READ EVENTS.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
Thanks for the reply. I've actually had debugging turned on and the line number is pointing to the 'read events' call. I know the currently active form at the time of the error is the one that contains the grid..and I know the currenlty selected table at the time of the error is the record source for that grid.

I've debugged a few Error 5 messages before and think I have a pretty good idea of what to look for..it's just in this case the only thing I've got to go off of is what I mentioned above..Usually, when I have the line number that the Error 5 occurs on, that line number points to command that is moving the record pointer on the table, which makes sense. since this occurs when the call stack is empty(that's why I'm sitting on 'read events') I don't even have any defined variables at the time to help search down the cause any further..

It just seems like whatever is causing the error is "behind the scenes" because of where it's telling me the error is coming from. I'm really looking for ideas on code that executes *outside* of my written code..after all, if the Error 5 was coming from our code directly, it seems that one of our methods other than one sitting on 'read events' would be the culprit..

thanks.
 
Hi tetsuo,

such an error that does not happen at a certain line of code but at READ EVENTS could happen, if you return to a form from a subform, so reactivating that "erroneous" form. And if at that moment some recordsource or rowsource is missing or has less records (is missing the record the grid recordmark is set at), then you can get such errors.

So be careful if you work with forms within the default data session, that you don't interfere with the tables, views or cursors shown in other forms in a way, that harms these. Eg not closing an alias, which is bound to some control on another form.

Bye, Olaf.
 
Hello Tetsuo3030.

I know the currently active form at the time of the error is the one that contains the grid..and I know the currenlty selected table at the time of the error is the record source for that grid.

You have started to put your finger on the problem here. I have had this happen to me before and next next time it does, I am going to write the solution down ;-)

The problem here is that the error message has nothing to do with the real cause of the error. To the best of my recollection, I think I fixed the problem by refreshing the grid after executing code that did some updates on the grid's RecordSOurce.

Sorry I can't be more helpful - but I do remember it was the grid and I am pretty sure that refreshing it at the right point in time resolved the issue.


Marcia G. Akins
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top