Is my database corrupted?

Panorama X
1

A procedure in a database that I use every day has stopped working correctly.
I used Time Machine to recover the previous day’s version of this file, and the procedure works correctly there.
I copied the text of that procedure to the one in the current version of the file, in case it might have changed by accident, but the problem remains.
The two versions of the database are the same in every other way, except for a few new records and a new form.
In the current version of the file I made a new procedure to do the same work, using the Record function, but the problem remains.
Maybe there’s a clue in what goes wrong. Here’s the procedure that works right in the old version of the file but wrong in the current version:
__
Field "Start_date"
SortUp
Field "Start_time"
SortUpWithin
Field "Start_date"
Find Start_date = date(|||04/08/17|||)
__
Note: If I change the last step to Select instead of Find, it works correctly.
Q: Is the current version of the file corrupted?

2

A test that I’ve found can detect a corrupted database is:

SelectAll
Loop
    Left
Until Info("Stopped")
Loop
    SortUp
    Right
Until Info("Stopped")

This merely verifies that the entire database can be sorted. If there is corruption within the data, this will typically find it.

3

I think this just means that the record with the date you are trying to find isn’t currently selected. If a record is currently invisible, it can’t be find. Just add a selectall before the find and you’ll probably be fine.

Also, the second to the last line

field "Start_Date"

isn’t necessary. It doesn’t hurt anything, it’s just an extra step that isn’t doing anything useful for you (unless you have some other reason to want Start_date to be the current field.

4

<I think this just means that the record with the date you are trying to find isn’t currently selected.>
No, I don’t think that’s the problem. The procedure works if I substitute Select for Find.

5

Interesting results: I ran that procedure is both versions of the file, the one that works right and the one that doesn’t. In both files it stopped after a few seconds on one particular record—the same one in each file.
So working in the good version of the file, I recreated that record in every detail—typing, not copying. Then I ran the file test procedure again. This time it didn’t stop t=on that record, but it stopped on another one.
Any idea what’s happening here?

6

That’s what makes me think that IS the problem. When using the select statement, it doesn’t matter what is previously selected. When using the find statement, it is absolutely critical.

7

Not sure what you mean by it stopped on that ‘record’. The procedure is sorting each field.

What I’ve typically found is that if there is any corrupted data in a record, the sort of the field where the corruption exists will get stuck when sorting that field. I can then typically see the garbage in the cell and by deleting that record or correcting that cell, I can typically ‘repair’ that file. But I too have found that sometimes just trying to delete that record is a task unto itself.

I use the procedure as I often have databases that have a significant number of fields and the procedure just makes it happen more quickly.

Robert Ameeti