Sanity check

Nancy Palmquist nlp at vss3.com
Wed Nov 18 09:04:00 PST 2009


Richard Kreiss wrote:
> Having an odd problem at a client's site.  Windows Server 2008, Windows XP Pro client running through Terminal Server, filepro 5.6.06
>
> In this particular file, I am logging changes made to specific fields. A new record in log_file is created with the original value and the new value plus code number, who made the change, date and time. 
>
> They are getting a sanity check error when they try to change values for only one doctor code  and not for all of the records associated with this doctor.
>
> The program does a lookup free, posts the data, and then I have a write
>
>        ◄ If:                                                                   ◄
>        Then: lookup log = logfile  r=free  -n                                  ◄
> 1567 -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>        ◄ If:         NOT log                                                   ◄
>        Then:         RETURN                                                    ◄
> 1568 -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>        ◄ If:                                                                   ◄
>        Then:         log(1)=@fi;log(2)=master_code;log(3)=@td;log(4)=@tm;log(5)>
> 1569 -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>        ◄ If:                                                                   ◄
>        Then:         log(7)=whoareyou;log(8)=fd;log(9)=fieldname(-,fd);log(10)=>
> 1570 -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>        ◄ If:                                                                   ◄
>        Then:         write log;fd="";ivalue="";nvalue=""                       ◄
>
> The sanity check crash comes at line 1570 with the write.
>
> I went in and changed this field on dummy records that are in this file and had no problem.
>
> Sunday night I deleted all of the index for the log file and rebuilt them per fpsupport's suggestion.  This has not solved the problem.
>
> Any suggestions as to what I might need to be looking for.  
>
>
> ───────────────────────────────────────────────────────────────────────────Bad──
> ┌──────────────────────────────────────────────────────────────────────────────┐
> │  Sanity check failure!  split() len < 0                                      │
> │ tptr = tptr=(6,26932,12845,1,0)                                              │
> │ file='logfile@' index=?which=1, nodesize=1024, entries[which]=13365          │
> │ which=1, nodesize=1024, entries[which]=13365                                 │
> │ count=12845, bound=7195, entries[1]=13365                                    │
> │                                                                              │
> │ Write this information down, save a copy of the above                        │
> │ index, and press  Enter  to generate a core dump to                          │
> │ send to fpsupport, along with the index.                                     │
> └────────────────────────────────────────────────────────────── Press  Enter   ┘
>
>
> ┌──────────────────────────────────────────────────────────────────────────────┐
> │  Sanity check failure!  split() len < 0                                      │
> │ tptr = tptr=(6,27063,12589,1,0)                                              │
> │ file='logfile@' index=?which=1, nodesize=1024, entries[which]=13364          │
> │ which=1, nodesize=1024, entries[which]=13364                                 │
> │ count=12589, bound=7194, entries[1]=13364                                    │
> │                                                                              │
> │ Write this information down, save a copy of the above                        │
> │ index, and press  Enter  to generate a core dump to                          │
> │ send to fpsupport, along with the index.                                     │
> └────────────────────────────────────────────────────────────── Sarah CastroPress  Enter   ┘
>
>
> Richard Kreiss
> GCC Consulting
> rkreiss at gccconsulting.net
>   
>
>
>
> _______________________________________________Filepro-list mailing listFilepro-list at lists.celestial.comhttp://mailman.celestial.com/mailman/listinfo/filepro-list
>
>   
Richard,

What are the indexes built on?  Are there any edits that are other than 
system edits on the indexed fields?  If so, do they exist in both files 
or on the global table for all files to share. 

Since this just adds records to the log file, try removing the indexes 
and see how it works.

If you get the log entries to post without the indexes, go from there.

If you have to you can bust down the update.  Create a free record, get 
the record number. write the record.

lookup and lock to the record number, post one piece of data, write the 
record,

repeat until you locate the piece of data that makes it crash. 

I guess this file is not more than tracking who changed what, for an 
audit.  The indexes could be run as demand indexes, when you need to 
look for something.  It is awkward but avoids the automatic indexes that 
are probably causing your issues.

I have been fighting an issue with Windows and filepro, that always 
occurs on the WRITE line - index updates are crashing is my best guess.  
Mine causes a memory error, with no info, so we have no way to track it 
down.  It seems to be network related or index location related.  It can 
not be reproduced on command.  It will fail 50 out of 20000 times it is 
executed.  No way to do that with the debugger.  Rebuilding indexes for 
the files in question, seems to fix it for a while.  Once it starts to 
crash, it cascades into worthlessness quickly.  I have changed the 
indexes as best I can to try to keep it solid.

I never have these kinds of issues on Unix/Linux machines, I think it 
has to be in the System calls or I/O stuff on a Windows Server.  Also 
the system seems to be tolerant of bad switches and network issues.  A 
Unix system, being server-side processing, does not traipse the data all 
over the network.  I think that makes a huge difference.

Nancy



-- 
Nancy Palmquist 		MOS & filePro Training Available
Virtual Software Systems	Web Based Training and Consulting	
PHONE: (412) 835-9417		   Web site:  http://www.vss3.com



More information about the Filepro-list mailing list