I'd strongly recommend one of two options:
1) Start looking into the ability to purge data
2) Split the file into a few smaller pieces, using a hash function if
necessary

There will likely be plans to increase the size limit in the future, but
having files of this size is just asking for trouble...
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: November 16-19, 2004: See our web site for details!


"Karl A. Sørensen" wrote:

I know of one company that has a "current" file and a "history" file
(or files). When the current file gets full (actually they schedule
this when it is near full at ~60GB) it is rotated to a history file.
For them it works well as their data has to stay on-line for a given
amount of time. When they no longer need their oldest they just stop
reading it.

As to the expanding the records.
1) If you can run it on the server there will not be a round trip
network delay (300 million network delays is quite significant).
2) When populating the new file, drop the indexes in it first,
populate it, then add the indexes back. Dropping the indexes in the
new file is "free" and prevents the database engine from having to
update all the indexes for every record inserted. This can save a
tremendous amount of time. Of course you will have to add the indexes
back after populating the file, but this is typically quite a bit
faster than adding the records into the indexes one by one.

I do not believe that the new database engine will be released before
you predict the file to be full, expecially if you are increasing the
size of the records.

As a thought, could you store the new portions of the records in a
separate file? It would eliminate having to change the record size.

Leonard

On Mon, 18 Oct 2004 08:21:49 GMT, "Karl A. Sørensen"
<kas (AT) kamstrup-ems (DOT) no> wrote: