I just finished fixing a database for a client where part of the data seemed to be missing in one table. The funny/weird part is that the missing records could not be found while using Select or Browse but one of the reports based on a view, that included the table in question, would display all the data. Rebuilding the indices did not fix the problem but R:Scope did find a broken link in the data. After the link was manually fixed and the indices re-built, everything is working correctly now. Afterwards I found out that the MIS department had been working on replacing network cards on workstations and tweaking the server.which would seem to be the likely culprit, at least in this case, and as you so eloquently put it. Javier, Javier Valencia, PE 913-829-0888 Office 913-915-3137 Cell 913-649-2904 Fax <mailto:[email protected]> [email protected] _____
From: [email protected] [mailto:[email protected]] On Behalf Of Bill Downall Sent: Monday, April 26, 2010 9:44 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Strange problem? Marc, It could be not index but actual data pointers that were broken a week before. In that case, you need R:Scope, to chain forward from the beginning of the table to where the pointers run out, and to chain backward from the last row of data to where the pointers run out, and then manually reconnect the previous-row and next-row pointers and the row counts to repair it. It is possible that they restored a backup erroneously, too. If it is broken data pointers, they could have continued entering new data, but probably wouldn't have been able to look up any data entered after the "break." Could they really have worked for a week of data entry without noticing? These breaks are almost certainly caused by network interruptions while data was being written to the server: power loss or fluctuation, or bad connections in cables, ports, switches or hubs. No matter how poorly or even maliciously any of us writes an R:BASE program, Our R:BASE programs could not cause these kinds of errors, accidentally or intentionally. Bill On Mon, Apr 26, 2010 at 10:25 AM, MDRD <[email protected]> wrote: Paul and Buddy They did an Unload all but there was still No data for the last week. Also, it would seem strange the Index file would be bad for 4-5 tables at the same time? Thanks Marc From: Walker, <mailto:[email protected]> Buddy Sent: Monday, April 26, 2010 8:36 AM To: RBASE-L <mailto:[email protected]> Mailing List Subject: [RBASE-L] - RE: Strange problem? Marc It could be corrupt index. I would either reload the database and if that isn't possible then pack the index. If I remember right a bad index will not show as error with autochk. Buddy From: [email protected] [mailto:[email protected]] On Behalf Of MDRD Sent: Monday, April 26, 2010 9:06 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Strange problem? Friday I had the 2nd user this year call and say that Rbase lost a weeks worth of data. I am sure RBase had nothing to do with this and I explained that it is impossible for a weeks worth of data to get deleted without corrupting the data base. The user said there were no errors on Autochk. I told them it appears that somehow they connected to an older backup copy of the data. They said they were missing Customers, transactions, recap stats everything from X date on. I explained how PK's, FK's .... and such I would have to delete the data in reverse order such as I can not delete a customer until I deleted their transactions because the data is linked... The user seemed to understand but is there any way I can prevent this or make it easier to prove it was a staff error or computer error not an RBase error? Another strange problem, a user called and they had transactions in the Daily table for customer 0 which does not exist in the customer table, there are PK's and FK's on those tables. I told them I thought they had to have some kind of short on their network because we can't even enter a transaction for customer 0... so for it to get in there there was some kind of computer hiccup. The normal start up routine is to run Autochk, if it passes make a copy of the DB files called Bck, then Zip them up with the day of the weeks name on it such as Monday.zip. Strange thing is they swear they do this everyday yet some of those files were dated March 17. I am now going to add some code to check the date of those files and if they are too old give them a warning. Any suggestions? Marc
