Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Sporadic lost data from array elements
Message
From
24/06/2006 09:20:24
Thomas Ganss (Online)
Main Trend
Frankfurt, Germany
 
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
01130365
Message ID:
01131406
Views:
14
>I have inherited a very old FoxPro application that uses array elements for editing in the VFP screens. I moved the application from VFP 5 to VFP 9 with minor changes to the code, most of which is in prg files anyway. About a year ago, I added a fairly complicated report. All of the logic for the report, including the SQL statements, report processing and printing, is encapsulated within the private data session of a new form. This new form is called from a command button on the old screen. Sporadically--perhaps one time in 1000--when control is returned from the new process, the values in the arrays are gone and the screen displays empty fields, sometimes causing the application to crash. Any ideas what might be happening? I've run out of ideas....

Linda,

the idea of saving and restoring is the correct one, since it protects your client from problems. BUT you should not stop there: use this new feature to track down the error source.
When restoring the array contents from the safe place, *check* for equalitiy first - if the error has cropped up, log it, restore and let the client work on. THEN sprinkle call to the compare method of your logging class iside the report forms methods at various times to find the error. Might take a while, let the user's find the correct place.

Your description of empty fields might come from moving sometimes to eof() and refilled array's - dunno the code. But having the copy-restore mechanism in place might help you locate the error even if it happens somewhere different than you believe, since now you have can check and log. Key fields in numeric fields definitely sound wierd unless you have separate arrays for text and numeric data.

Regarding "creaky" software: First of all I would NOT go for a total rewrite. Too many risks business wise too often and not factored in. Make it clear that every time you touch the code you will enhance it SLIGHTLY around the places you touch - I usually target 33% of refactoring. Use the analogy of an older car that needs more maintance <g>. Do it upfront, and most of the time you have no problem. Just guarantee that the app will ALWAYS be runnable and will be getting healthier.

my 0.02 EUR

thomas
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform