Freechain errors

[Bob Stockler]

Top Post . . .

If you care about the info in the "filePro" 20-character header
in each record you'll adopt a different tack. and - even if you
don't - this might be a better strategy.

Create an Alien filePro file that uses the "key" file of your
significant file as its "real" file.  It will have a 20-byte
first field and one or more fields that encompass the balance
of the "main" file's records (these fields in the Alien file
don't have to have a 1-to-1 correspondecne to those of the file
of interest - just be fields (other than the 1st 20-byte field)
of 999 characters or less to make the record length be the same
as the "real" file's actual total record length).

Have that Alien file read its "real" file and then (using filePro
file I/O) write all records whose first character is \001 to a
temporary file. 

Copy or move the temporary file to the "key" file and then run
'freechain' on it.  (You may have to add one blank record after
the end of using the Alien file to write its temporary file - if
so, make the 1st character of that record a \000.)

Done nightly, this -should- give you a fresh "key" file for your
application, with a minimum number of records and a 'freechain'
that's looking for the -next- free record.  And it can be easily
automated as a nightly task.

Bob (who offers this without any warranty or guarantee)

PS - You may also need to rebuild indexes after this is done.

Don Coleman wrote (on Thu, Dec 21, 2006 at 11:58:21AM -0500):

| I have a client (fP v5.0.13, Windows 2000 & XP Pro. Clients, Windows 2000
| Advanced Server) who is having frequent freechain issues.  Unfortunately
| they occur most frequently at the worst time of the day, near their pickup
| time for their FEDEX carrier, which is crunch time.  An automatic freechain
| rebuild will occur in one of their *clerk processes and bring their system
| to a halt.  Standard resolution is to have everyone exit fP, kill the
| automatic freechain rebuild, rebuild the freechain manually, and they
| continue normally until the next occurrence.  Unfortunately the customer
| doesn't have the luxury of 5-10 minutes of down time during crunch time to
| have everyone finish their record, exit, execute freechain, and start again.
| 
| Several observations; first the automatic freechain rebuilds seem to
| increase in frequency the larger this file gets.  For example, this AM I
| compressed this file (copied the key to a mirrored file key, then ran a
| process to copy and write the "used" records back to my original file),
| effectively shrinking the file from 157,000 records to 16,000 records.  This
| file would normally grow to a maximum of 40,000 records on any given day.
| All "completed" records are then archived to another file each evening after
| the close of business.  So if I understand freechain correctly, this file
| should never grow larger than the max size of 40,000 records.  However,
| within a week or 10 days it will be > 100,000 records.  I assume this occurs
| because the application is "taking" new records when there are free
| (previously deleted) records available.  My understanding of the freechain
| function is it acts as a pointer for the next record to be used.  If there
| are previously deleted records available to be reused they would be reused
| first before the app. takes a new record.  
| 
| As mentioned above, the frequency of the freechain errors increases with the
| file size.  When the file was >150,000 records it was happening at least
| daily, if not twice daily.  Any suggestions? 
| 
| 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

-- 
Bob Stockler  +-+  bob at trebor.iglou.com  +-+  http://members.iglou.com/trebor