Error 5 record out of range strangeness

[Dobs_seemore]

Usually this error is simple, you tried to go where a record does not exist, however this one is strange and is happening repeatedly on two computers out of 60 that run it. The rest of the people who use it have not seen the error which makes this all the more interesting, but could simply be that they use it in a slightly different way, now to the facts.

The application runs locally and it not a shared or network application. It is a form with a 6 tab page frame. The error 5 when trapped is telling me that on page frame 1 a list object with an SQL statement as it's row source is what's causing the problem. What is interesting is that when the error occurs it's happening while the user is interacting with objects on page frame 2 which programmatically does not touch page frame 1 or any of it's objects nor does it cause any type of requery. As a test I disabled everything on page frame 1 while they are on page frame 2 using .setall so every object was disabled, still the error persisted.

Example error messages
Error number : 5
Program : OE.FRAME.ORDERGUIDE.OITEMSEARCH.LOSTFOCUS
Line number : 32
Line of code : select invoice_date,lines,quantity,sales from saleshistory where customer_id=customer.customer_id order by invoice_date desc into cursor saleshist
Error message: Record is out of range.

Error number : 5
Program : OE.FRAME.ORDERGUIDE.OITEMSEARCH.GOTFOCUS
Line number : 11
Line of code : select invoice_date,lines,quantity,sales from saleshistory where customer_id=customer.customer_id order by invoice_date desc into cursor saleshist
Error message: Record is out of range.

Error number : 5
Program : OE.EXISTINGORDER
Line number : 173
Line of code : select invoice_date,lines,quantity,sales from saleshistory where customer_id=customer.customer_id order by invoice_date desc into cursor saleshist
Error message: Record is out of range.

oe.existingorder is a method on the base form that I call when they edit an order, the other two got and lost focus are on page frame 2 of a search text box. Again these objects/methods do not touch or refresh anything on page frame 1 where the list is with the SQL statement. It is one of those strange things that started out of nowhere and in happening on 2 of the 60 people who use it. We cannot duplicate the problem ourselves using the application, usually we can.

Now to make things more complex this message happens on occaision
Error number : 202
Program : OE.FRAME.ORDERGUIDE.DONE.CLICK
Line number : 99
Line of code : select invoice_date,lines,quantity,sales from saleshistory where customer_id=customer.customer_id order by invoice_date desc into cursor saleshist
Error message: Invalid path or file name.

BTW just to be clear on all of the errors above the "Line of Code" is the list box with a row source SQL statement that you see and is located on
OE.FRAME.CUSTOMER.SALESHISTORY <- Saleshistory being the list box object.

The error is related to the same object on page frame 1, the list with a SQL statement as the row source, yet there is nothing related to a path or file name,the statement returns results to a named cursor not a dbf file with a path. Very confusing and I'm beginning to think some other application on the local machines are causing it in some odd way. This is Windows 11 and Fox 9 with SP2 and the group header hot fix installed from article 968409

Thanks, this has been going on for a week and I've been through some strange issues with Fox over the years but this one finally has me asking for help here.

 

[Dobs_seemore]

Just in case I need to take this deeper, how do you get the debugger to show the trace window once you enter a form? When I traced the program that starts it all the trace window stops on "read events" and stays there while I interact with the form.

 

[Mike Lewis]

how do you get the debugger to show the trace window once you enter a form?

The easiest way is to set a breakpoint. You do this by double-clicking in the left-hand margin of the code window, or by right-clicking and selecting "Toggle breakpoint". Either way, do this at the line of code at which you want to start debugging.

Although you can (and should) remove the breakpoint when you have finished debugging, no harm is done if you don't do that. Breakpoints only exist in the development environment, and are not carried through to the executable.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dobs_seemore]

Well this is unreal. Used it all day with no errors while in FoxPro running the source code. He left and used the EXE and boom got the error.

 

[TamarGranor]

So the next question is what's different between the environment where you were running it and the one where the EXE is running:

- any FoxUser file?
- any Config.FPW?
- registry settings?
- paths?
- ...


Tamar

 

[Dobs_seemore]

We finally got the error twice while running the source in VFP. It was on a thisform.frame.xxxxxx.refresh

I looked at all the open tables to see if any of them were at EOF(), one was that should not be that is tied to a COMBOBOX. I think I have narrowed it down to a "LIST" and a "COMBOBOX" that are local tables that get wiped (zapped) and reloaded when a new order is created or an existing order is edited. I think the combo or list is pointing to a record that becomes unavailable when the underlying table is reloaded and a refresh is issued. Why this started happening now versus years of trouble free run time is strange however I think issuing a requery on these objects before a refresh might be what's needed to rebuild the list/combo listindex. I'm also going to convert the list to a grid, as I have no issus reloading the underlying table with grids and then a form refresh or grid refresh.

 

[Chris Miller]

You address an issue that's rarely talked about: Even when most controls are driven by data, i.e. a workarea, listbox and combobox are loading items into an internal items array. That's redone when you requery them, so REQUERY is not just a method to use when you use a rowsource type of SQL query, it's actually requerying the items of the control itself.

I made the experience this makes listbox and combobox more stable and less sensitive to lost rowsource. The grid is infamous to break, if the recordsource vanishes, even just for split seconds if you do a query INTO grid.recordsource and overwrite the existing grid cursor with new data. The grid is not sensitive if such a requery is done on a view, as the view workarea stays in place during the whole requery process (and here I'm talking about the REQUERY() function for views, the grid control has no requery method, as it works differently in that respect.

I can't answer why this didn't show up for years, but it's not the first time something works long lasting and finally breaks for some unknown reason.

I do remember commbo nd list breaking mostly when you change active forms. When something is askew while a form is reactivated it breaks. A form.refresh is quite similar to such a situation and I often see people putting way to much code into the refresh event, which they don't realize causes further refresh events in what is a cascading method anyway. I learned the hard w ost often a setfocus is the better alternative to a control.refresh, if it comes to a single control. If you want to refresh a form, the form.refresh() is a natural way, but you need to realize you're shaking up everything on the form. The less code you have in refresh, the less side effects. So that's a warning of what you say you plan to do.

I would take a "snapshot" of what happens with event tracking and coverage logging could also help. You might detect loopbacks where you don't expect them to happen.

But in detail you might be very right about the suspicion that a requery before a refresh would be good, as I think a refresh does cause many things but does not cause a requery in itself.

Chriss

 

[Dobs_seemore]

Chriss
To keep things simple do you think a .requery in the refresh method of lists and combos would cure this?

 

[Chris Miller]

It's worth a try. If not, you'd need to unbind the controls that trigger an error and rebind them after data has been redone.

Zapping a cursor is never disturbing a grid, it might so for combo/list because of the items, so changing to a grid also could already "heal" it.

Chriss

 

[Dobs_seemore]

I created a test form with a pageframe and a combo box with some buttons to refresh and requery. Damn if I can get it to error so I can understand specifically what is going on here.