Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Variable ..... is not found
Message
From
27/10/1997 08:08:15
 
 
To
25/10/1997 09:43:40
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00056580
Message ID:
00056781
Views:
28
To clarify the situation a little more, I was brought on in the last week to assist the company with straightening out their "Standard Application". The original application had been developed by 2 programmers with less than 2 years combined of FoxPro 2.x experience and their first exposure to VFP. Tracing through the code of this application has been frustrating, to say the least.

There have been multiple problems with DBC and DBF corruptions, due to the transaction handling coded into the app. They failed to do any proper documentation, and I am having to sort back through this stuff and find the problems. Almost feel like throwing everything but the initial interface design, and starting from scratch. Trying to run and test this app, I have begun finding the table and database corruptions, and have been trying to find out if tables are supposed to be FREE or belong to the DBC in the app.
As we all now, when a table is freed from a database container, any field names that are more than 10 characters lose any chars beyond that. This has been causing multiple problems here, because of all the references in DE's, DBC persisent relation, referential integrity, and such. All of this confusion has lead to me missing some problems that are not very visible.

Oh well, time to get off my soapbox... :-)
Thank you very much for your responses. Sometimes just a little reminder keeps me on the right track.....

>>GOT IT!!! Goes to show that if you leave something for a couple of
>>months, your memory begins to fade... Problem being the table is indexed
>>on the response_id field. How could I miss that?? After posting the
>>message, I did find out that the table was supposed to be contained in a
>>DBC. When the table was freed, the response_id field name was shortened to
>>10 chars. Thank you for kicking me in the head and waking me up..... :-)
>
>Getting it in the head from us is far easier than hitting it against a
>wall. Once I got that message I played around it all day, though I knew
>the cause (can imagine you not knowing it at the time).
>
>I've seen a worse scenario, with free tables:
>
>Use table1 order codefield
>sele 0
>use table2
>set rela to codefield into table1
>index on table1.namefield tag name
>close data all
>use table2
>
>This is pretty unstable, but it did work, provided both tables were
>opened using the first four lines. It crashed only if someone not
>knowing it tried to open the table2 without opening table1 and setting
>the relation.
Previous
Reply
Map
View

Click here to load this message in the networking platform