Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Index corrupted
Message
From
10/06/2021 06:46:35
 
 
To
10/06/2021 00:17:22
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Title:
Miscellaneous
Thread ID:
01681084
Message ID:
01681128
Views:
49
>>>I have a customer where the cdx file continues to be corrupted.... I rebuild indexes (i use for this operation an old version of Stonefield Database Toolkit) and after a few time (even 3 times in same morning) i have to rebuild it..... Table's size is 450Mb and in the cdx files i have 35 tags. We works in rdp session on a server with Windows Server 2012 R2 and 32Gb ram. (this is a phisical machine). The users are using my app are from 6 to 10 and this is the table that probably is used by all the users (both for write and read access)......... Someone has had similar problems ? Some suggests.... This customer uses my app since 2005 and we never have had this problem and the table thta now has problems was in some periods larger (near foxpro limits) and we have moved data to another table....
>>
>>For completeness you might want to check that your version of Stonefield fully supports the version of VFP you're using.
>>
>>I've seen persistent index problems happen because a character-type field (character, memo etc.) in the table data contains CHR( 0 ) somewhere. No reindexing process could fix it. You could write a utility to check character-type fields in your data for CHR( 0 ).
>
>Oooohhhh, yyyeeeaahhh.... Chr(0) can mess you up totally. In vfp6 plus table buffering plus transactions we sometimes were unable to control Chr(0) messing up a fresh created record - ditched transactions for a while until two pronged attack of vfp9 and heavy fixes in error handling allowed turning transactions on again...
>

CHR(0) can be an issue not just in code. I inherited an enormous procedure file that had all kinds of weirdness about it (crashed some tools, etc.) Finally figured out it had a CHR(0) somewhere. Removed that and it was still awful to have a multi-megabyte procedure file, but it no longer crashed things.

Tamar
Previous
Reply
Map
View

Click here to load this message in the networking platform