I have experienced the problem described below only occasionally, but it seems to recur so I thought I would ask for any thoughts.
Every now and then, one of the tables in my app appears for a while to have lost data in a group of records. This usually happens to (or at least I notice it)a table with an auto-increment field used for id numbers. It becomes noticable when the auto-increment field starts over at "1". At this point, I open the default browse for the affected table, switch to record number order, and move to the end of the table. If I "page-up," several screens of what look like completely blank records appear (logical fields display a defalut value). If I copy the affected table (using NT Explorer) to my local hard drive, all the records appear normally. I then rename the production copy of the table (the affected one that I have just copied from) to something like "myTable_bad.dbf", and copy the copy back into its place. This solves the problem. Within a day or two, the original copy of the table ("myTable_bad.dbf") no longer has the problem - i.e. all of the records that appeard to contain no data now appear correctly.
The production copy of this app exists on a Novell network, and the problem appears irregularly - about once a month. Some of the tables in the app include lots of records (over a million in a couple of cases), but the problem affects both big tables and relatively small ones. (The latest occurance was with a table with about 40,000 records.) I am running A5v4.
My guess is that I am experiencing some form of partial fragmentation of the .dbf files (because copying the file to a new location seems to solve the problem). But any thoughts on this would be helpful. Thanks,
-Bill
Every now and then, one of the tables in my app appears for a while to have lost data in a group of records. This usually happens to (or at least I notice it)a table with an auto-increment field used for id numbers. It becomes noticable when the auto-increment field starts over at "1". At this point, I open the default browse for the affected table, switch to record number order, and move to the end of the table. If I "page-up," several screens of what look like completely blank records appear (logical fields display a defalut value). If I copy the affected table (using NT Explorer) to my local hard drive, all the records appear normally. I then rename the production copy of the table (the affected one that I have just copied from) to something like "myTable_bad.dbf", and copy the copy back into its place. This solves the problem. Within a day or two, the original copy of the table ("myTable_bad.dbf") no longer has the problem - i.e. all of the records that appeard to contain no data now appear correctly.
The production copy of this app exists on a Novell network, and the problem appears irregularly - about once a month. Some of the tables in the app include lots of records (over a million in a couple of cases), but the problem affects both big tables and relatively small ones. (The latest occurance was with a table with about 40,000 records.) I am running A5v4.
My guess is that I am experiencing some form of partial fragmentation of the .dbf files (because copying the file to a new location seems to solve the problem). But any thoughts on this would be helpful. Thanks,
-Bill
Comment