We have a client that had a GFE in a data table, FIXLH fixed the GFE but it deleted 630 records in the process. FIXLH said it saved these to the SYSTEMP file. I beleive that it wrote a list of keys out to the SYSTEMP file, but I haven't been able to locate it (the client's SYSTEMP is many thousands of records).

1. Will FIXLH write just the key or the entire record to SYSTEMP?

2. I assume that all the keys will be in one file in SYSTEMP - How could I determine the name of that file?

Thanks,

James Caldwell

It's been a while but:

1) It will write out as much of the record that it recover. Thus records can be truncated or otherwise corrupted.

2) I'm not familiar enough with the changes between 2.x and 3.x to answer that. Previous versions would clear then write to DUMP_FIX_RECOVER and DUMP_FIX_GARBAGE and you just had to know what the last file was that you ran the recover/fix on.

Thanks for the response.

I was thinking that DUMPLH would throw the records out to DUMP.FIX.GOOD and DUMP.FIX.GARBAGE (or whatever they are called), do you think that FIXLH also dumps out to those tables?

When FIXLH was finished it told me that it wrote them out to the SYSTEMP, that's why I'm confused.

(Running AREV 3.12)

Thanks,

James

It's a case of the blind leading the blind. I have not the 3.x documentation handy and have never had to fix GFEs in 3.x thanks to the NLM and NT Services so I'm not familiar with the changes made between 2.x and 3.x.

The Sprezz fellows need to jump in on this one: Andrew? Aaron? Carl?

It appears that all the data (whatever is recovered) is saved directly in the SYSTEMP file under the name :

claim_file_group_107098_1_16265*00a02485fb58

claim_file is the table name, group_107098 is the correct group, but what is all the extra stuff at the end??

Only 1 of the 639 records was present in this row.

There are 831 other rows with a similar name in the SYSTEMP, each one of them seems to contains parts of records.

Is there any way to determine when these rows were written to the SYSTEMP table?

The last part looks like your station id. Do a WHO at TCL to check. The part prior to the "*" is a sequential session counter, which is stored in the arevpid.dat file. What I have done in the past when I need to find something in the SYSTEMP file is to create a symbolic to get the station id or the date (some record ids also contain the date) to narrow down the search.

Note that the SYSTEMP file is used for temporary storage. With all users logged off, it should be empty. If it is not, you should consider clearing it (of course recover your missing data first).

Dare I ask why you are not recovering from a backup?

James..

Well, you've got a fine kettle of fish, but here's what I have done in the past:

I have a global table called SAVEDATA. The process to get the records is (assuming that no other users are fixing the table:

CLEARTABLE SAVEDATA (S)

SELECT SYSTEMP WITH @ID 'table_name_with_records'

IF I GET ANY HITS THEN ..

COPY SYSTEMP (D) TO:(SAVEDATA

This will remove the data from SAVEDATA so it won't be there again.

Next is the God_Awful part.

SELECT SAVEDATA

EDIT SAVEDATA

.. check the record. Note that the original key is in the first field along with some other caca. If the record is worth saving, then edit the first field to remove the key stuff. Use the editor's block commands and cut it to a buffer. Then SHIFT+F1 to edit another. Enter the original table and the correct key. You should see a New Record message. Paste the contents into the record and save it. Exit back and do an ALT+F. Don't save your changes. Keep on truckin until you're done or out of patience.

Don Miller

C3 Inc.

FIXLH copies the good records to DUMP_FIX_TEMP, and then copies them back again. If you interrupt the copy back process, you can do it manually. SYSTEMP only seems to get used for the records that AREV can't unpick itself.

SYSTEMP will be CLEARED if you do another FIXLH, so copy the contents of the file to a new temporary file before you do anything else.

The backup is run every Friday, this was on Tuesday so they would have lost Monday's work. Talked to the IS guy on site and he informed me that the last TWO backups failed! His explanation was something along the lines of "the lady didn't put the tape drive in right"!!!

So they would have lost over two weeks of data. :)

View this thread on the forum...