Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
When is Private DE not Private?
Message
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Miscellaneous
Thread ID:
00090627
Message ID:
00090638
Views:
35
>I have a strange problem I can't seem to resolve. I have an old VFP3.0 app that has a main form that displays a typical contract information. This form's DE is set to private. Within this form there is a routine that enables the user to pop open a different modal screen which is use to print contract information to the printer. This second modal screen's DE is also set to private and it enables the user to print more than one contract info. (eg specific date rage). Upon entering a user-defined criteria, a SQL-SELECT is used to create a cursor and then a report form is call to print the records in the cursor. So far, so good.
>
>The problem is, after this routine is run, the record pointer of the contract table is somehow moved to the BOF, regardless of which rec the form was at before the routine is run! I've checked and rechecked the code to make sure I'm not issuing any command that would do this. What could cause this???
>
>The code in the routine is very simple:
>
>*--contr_id is PK that is passed to the modal form to give the
>*--user the option to print only this particular contract.
>DO FORM contrcov WITH contract.contr_id
>
>I get an error message saying that "Data environment have already been unloaded" after closing the modal form.
>
>TIA
>John.

John, you probably can try to set second form to Modeless for the test, and then when it is run check in the View window if you really have 2 different private datasessions.
I use similar way with print options form in VFP 5, except that I use the datasession of calling form. Everything works fine.
I always prefer to work with the views, but in one VFP 5 app where the complicated form was working on tables with relations I found that SQL SELECT moves record pointer some way in the FROM table. To avoid this I opened the same table as myTable1 and made SELECT ... FROM myTable1. In this case you probably need to make sure that all edited data were TABLEUPDATEd before you run the report.

HTH,
Nick
Nick Neklioudov
Universal Thread Consultant
3 times Microsoft MVP - Visual FoxPro

"I have not failed. I've just found 10,000 ways that don't work." - Thomas Edison
Previous
Reply
Map
View

Click here to load this message in the networking platform