REPLACE field WITH value IN alias. Another good things about this is the shortness of it as opposed to what I was doing replace alias.fieldname, alias.fieldname which makes for long replace statements.
I understand that now, I thought the alias.fieldname was telling it IN the other work area as I'm not referring to anything in the current one. Strange after all these years I run across this, always finding something new to me, old to others.
Thanks for all the replies. Still seems logical that you could update other tables while the current area is at bof/eof using alias.fieldname or fieldname in alias. I'll have to start switching my code over to IN ALIAS.
thanks again
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.
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"...
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.
I just put it in the form init. Good idea. Today we will use the application in VFP running the source code so I can get an accurate error.
Thanks will update when I know more later this afternoon.
Chris Miller:
I replied that Debug info is checked.
mjcmkrsr:
Read more of the thread, that is not the actual line of code that is the error. For some reason the .EXE is returning different results then when in development and it's driving me a little crazy. Also that select SQL statement...
Chris thanks for all the replies on your comment about the "SQL query line of code should be it" when I put a "go 50000" just to trip the error it reports "go 50000" when running it in FoxPro, when it's an executable it reports an SQL statement instead of the "go 50000" as it should. Strange...
Finally getting somewhere.
I found out that using the application as a stand alone .EXE the error routine is reporting the WRONG line of code. If I run the application in FoxPro development and force a record out of range by running "go 50000" where there is only 3900 records the error routine...
Understood. It's not the case though. All of the tables are empty to start with, our server loads the tables with new info from scratch. Once they are loaded they are not touched and are copied down to the laptop/desktop when they update their system. Each user has a folder on the server...
I was not considering the index of the table (selecting from). The table it selects from is using an index on the customer_id however that table and index are copied over to their laptop or desktop every morning when they update their system. I'd think that everyone would get the error as the...
Normally yes I'd agree however the offending line of code is a SQL statement returning records to a SQL CURSOR. A DBF and or Index does not exist in this case which has me really confused.
However I'm wondering if it is a local DBF/Index issue and the line of code returned by the error is not...
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...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.