Phantom record created with 2 specific data entries in find.

[DaveTolle]

Could use some help hunting this down. I have a relational database with one table containing 3 primary data fields to find records including a status which is Pending, Active or Complete. The other selection fields are Activity, Project type, Program type.

 

When the found set selection is status is Pending and Program type is Emergency Repair, a phantom record is created which I can delete. If I add the Project type to the find, no phantom. If I add the Activity to the search, a phantom is created.

 

When I search for Pending on all other Program types in the database, there are no phantoms created. It is only for this one program type, Emergency Repair.

 

Once parameters are met to switch the record to Active, there are no phantom records created for a search for Emergency Repair. Only when in the Pending status for Emergency Repair.

 

Baffled. Ideas?

 

Thanks,

Dave

[Kris M]

can you post the file and specific directions on how to reproduce the phenomenon your trying to fix?

[DaveTolle]

I performed a recover test on a backup and the problem is resolved. I am unable to attached the complete Recover log, but this is how it started:

2014-04-15 08:15:57.630 -0500    HCDMainBkUp4.14.14.fp7            808         FAILED consistency check, error 808

2014-04-15 08:16:42.491 -0500    HCDMainBkUp4.14.14.fp7            0              *** Started recovery of 'HCDMainBkUp4.14.14.fp7'

2014-04-15 08:16:42.532 -0500    HCDMainBkUp4.14.14.fp7            0              Scanning blocks and rebuilding file...

2014-04-15 08:16:42.559 -0500    HCDMainBkUp4.14.14.fp7            300         ERROR: Recovery of 'HCDMainBkUp4.14.14.fp7' failed

2014-04-15 08:17:14.351 -0500    HCDMainBkUp4.14.14.fp7            0              *** Started recovery of 'HCDMainBkUp4.14.14.fp7'

2014-04-15 08:17:14.421 -0500    HCDMainBkUp4.14.14.fp7            0              Scanning blocks and rebuilding file...

2014-04-15 08:17:18.562 -0500    HCDMainBkUp4.14.14.fp7            0              Scan complete, found 91522 page(s) to process

2014-04-15 08:17:24.015 -0500    HCDMainBkUp4.14.14.fp7            0              Rebuild processed 91522 page(s), completing end of file

2014-04-15 08:17:29.180 -0500    HCDMainBkUp4.14.14.fp7            0              Completed copy or rebuild of file blocks

 

And ended:

2014-04-15 08:25:59.753 -0500    HCDMainBkUp4.14.14.fp7            8495       WARNING: problems were detected while recovering the database.  The recovered file should NOT be used going forward; copy only the most recent work from it into a backup copy of the original file.

2014-04-15 08:25:59.762 -0500    HCDMainBkUp4.14.14.fp7            0              File blocks: scanned and rebuilt 91522 block(s), dropped 0 invalid data block(s)

2014-04-15 08:25:59.775 -0500    HCDMainBkUp4.14.14.fp7            0              Schema: scanned fields and tables; some problems were found...

2014-04-15 08:25:59.787 -0500    HCDMainBkUp4.14.14.fp7            0                fields created to match record data: 0

2014-04-15 08:25:59.799 -0500    HCDMainBkUp4.14.14.fp7            0                field values deleted due to invalid ID or repetition: 0

2014-04-15 08:25:59.812 -0500    HCDMainBkUp4.14.14.fp7            0                records deleted due to invalid ID: 0

2014-04-15 08:25:59.824 -0500    HCDMainBkUp4.14.14.fp7            0              Structure: scanned; 6 item(s) modified

2014-04-15 08:25:59.837 -0500    HCDMainBkUp4.14.14.fp7            0              File size after recovery is 374599680 bytes

2014-04-15 08:25:59.849 -0500    HCDMainBkUp4.14.14.fp7            0              *** Completed recovery to 'HCDMainBkUp4.14.14 Recovered.fp7'

 

I do not know when this problem started and I am not sure about what the "original file" should be as there has been consistent updating since migrating to 11. I may have no choice, but to place the recover file to the server. See any problems with that?

 

Thanks,

Dave

[DaveTolle]

I have found that creating a new Status field takes care of the problem in the non recovered version. That is a least case fix and I will test that for a few days.