Freechain question

[Nancy Palmquist]

Don Coleman wrote:
> List:
> 
> Ken posted a response several weeks ago stating that it was not required to
> have all users exit a file before rebuilding a freechain.  He stated fP
> effectively locked down anyone trying to add or delete records while the
> freechain was running (if I remember correctly, certainly not his wording).
> Over the past week I had two freechain rebuilds occur as a result of running
> an archive process while other users were one the system and in this file.
> The archive process copies the appropriate records from the source file to a
> mirror destination file, then deletes the record in the source file.

Don,

Make sure you do a WRITE  after the DELETE, and also make sure you do a 
WRITE ARCHIVE after you COPY to the archive.

Is the socket running from this file?

Is the IMPORT running in this file?

If the IMPORT is running in this file, can you run it from another file 
and just post the records to this file as they are read?

Same with the socket logic.  Run it from a work file and just write 
records to the file that requires the data.

Then if those functions somehow misfire the live file is not generally 
affected.

Especially if these functions tend to run overlapped and often.

The steps that effect the freechain are a lookup with r=free, adding a 
record live, or a DELETE.  Review those items and make sure any lookup 
has a -p (lock), make sure you issue a WRITE after any DELETE or ADD.

This has all but eliminated any freechain builds on my systems.


If there are users adding records, turn off the BREAK key until you 
finish posting.

For example, issue BREAK OFF when you start posting.  Then I always add:

Break ON to the @wef processing for the first data entry field on the 
screen.

That allows the user to BREAK during data entry or when they get to a 
new record and they do not want to add anymore.

This depends on your functionality, but maybe it will give you some ideas.

You can not do anything about the idiot that RESET's the computer, 
interrupts the power or hits the X to close the window while a record is 
being updated.  These are only under your control to the extent that the 
hardware is maintained properly, the humans are trained possible and the 
Microsoft gods smile on you.

Nancy






> Typically, if I am going to have a freechain rebuild occur it is when I turn
> two interfaces (one an ascii import, one a socket connect) back on after
> running the archive process.  If I run the archive process while these two
> interfaces are left on I will surely get a freechain rebuild, so I turn them
> off.  This lessens the odds to less than 50%.
> 
> Now to my question.  This AM I turned one of the interfaces back on and it
> posted 10-20 records and then the "rebuilding qs1 freechain" popped up on
> the interface window.  I exited the application and then immediately started
> it again.  No freechain error has popped back up, the interface is still
> posting its data and has been doing so for about 75 minutes.  If fP
> automatically detects a files' freechain needs to be rebuilt why didn't it
> pop up when I re-started the interface the second time?  There are
> 100,000-200,000 records in this file and if I manually run freechain it will
> take approx. 60 seconds to complete.  When the interface was re-started I
> can't believe it completely rebuilt the freechain since I closed the
> interface displaying the freechain with 2-3 seconds of it appearing.
> 
> Windows 2000 Advanced Server, Windows 2000 & WINXP Pro. Clients, fP v5.0.13.
> 
> Don Coleman
> Donald G. Coleman, Consultant
> 402 Andrew Circle
> Indiana, PA 15701
> dcoleman at dgcreact.com
> (724) 349-6302
> 
> 
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> 


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