FIXLH writing out to the SYSTEMP file (AREV Specific) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]


==== FIXLH writing out to the SYSTEMP file (AREV Specific) ====
=== At 29 SEP 1999 01:45:58PM James Caldwell wrote: ===
 
{{tag>"AREV Specific"}}
 
<QUOTE>
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

 
</QUOTE>
----

=== At 29 SEP 1999 02:13PM Warren wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 30 SEP 1999 01:37PM James Caldwell wrote:  ===

<QUOTE>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

</QUOTE>

----

=== At 30 SEP 1999 04:38PM Warren wrote:  ===

<QUOTE>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?

</QUOTE>

----

=== At 30 SEP 1999 04:59PM James Caldwell wrote:  ===

<QUOTE>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?

</QUOTE>

----

=== At 01 OCT 1999 11:49AM Victor Engel wrote:  ===

<QUOTE>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?

</QUOTE>

----

=== At 01 OCT 1999 03:31PM Don Miller - C3 Inc. wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 04 OCT 1999 12:28PM TimS@miles33.co.uk wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 06 OCT 1999 11:10AM James Caldwell wrote:  ===

<QUOTE>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. :)

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=342DD212522E2281852567FB006197B8|View this thread on the  forum...]]