Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Tip: VFP Handling of Use ... NoData
Message
 
 
À
Tous
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Titre:
Tip: VFP Handling of Use ... NoData
Divers
Thread ID:
00304054
Message ID:
00304054
Vues:
81
This one took me a while to figure out and never would have been seen in the debugger.

I have an automatoc logging of errors in my apps to make it easier for me to correct problems. I also use Aerror(), Message(1), Message(2) and Message(3) to populate memo fields in my errorlog table. When I first release an app, the project is built with Debug Information checked in the Project info.

I am looking through this error log, which now has about 200 records. But the same error is replicated throughout the table [10 errors propagated for each real error]. The error is spawned in the BeforeOpenTables method of Form1. Form1 is used because the form has not yet been instanciated so the name I have given the form does not exist yet. This is major PITA #1.

These propagated errors were like: Alias Not Found, No table is open in the current work area, Memo file myfile.fpt is missing or is invalid, etc. All very helpful in finding the cause of the problem since by the time I start troubleshooting, everything is working fine and no one is complaining about a problem.

In the memo field where I have Message(2) info, a SQL command is there that I could not identofy because it had a where clause like: where 1=0. It finally dawns on me [make mental note here] that this is how VFP opens a view when the NoData option is used. This eliminated the problem being with the form. Try finding that in the docs.

Now that events are starting to click mentally, I finally realized these errors were created because the server where the data reside had abnormally gone down [crashed] when the users were running the app. When the server came back up, the users started using the app again but the abnormal shutdown of the server caused some corruption with the DBC. There was no missing or invalid memo file and no tables or views were corrupt. After doing a VALIDATE DATABASE RECOVER and repairing corrupt indexes, all was well.

Moral of the story: You can not possibly track and log all information needed to debug your apps. I was lucky because our LAN Adminstrators log all server crashes in a notebook, and I was able to compare these dates and times to the DateTime in my errorlog [the errors occurred after the last crash].
Mark McCasland
Midlothian, TX USA
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform