The text below is excerpted from a post I made on the hts_users group. The subject was about the problem of getting a "timeout" while using MvPACK on large DBIII files. This led to a discussion on ways to keep from MvPACKing in the first place. ============================================================= From: "Brian R. Bullock" To: hts-users Subject: Re: MvPACK'ing and large databases Date sent: Mon, 7 Sep 1998 14:39:13 +0000 For offline DBs you can set the Miva Mia timeout to zero(no timeout). For online DBs there are two reasons to MvPACK. 1) Removing deleted records. Bill Wieland's suggestion (which I use religiously) is to re-use deleted records. The d.deleted variable is a built-in Miva variable just like d.eof, d.recno, d.totrec, etc. It is automatically set to true for a record when you use MvDELETE on the record. You should already be using the d.deleted variable to exclude deleted records from display. So when you need to add a new record just use a function based on the skeleton function below: >>>>Code to assign ALL db variables<<<< To control db field "bleed-through" you should assign a value to ALL db fields (even if only a null) when using MvADD or MvUPDATE to add a new record. 2) To reduce the size of a .dbt file. When you change a MEMO field by assigning a value to it Miva appends the new value to the end of the .dbt file. This happens EVERY time you assign a value to the MEMO field even if that value is the same as the previous value of the field. There are two ways to control the .dbt file size. The first is proactive and is accomplished by using this type of code in your db MEMO field variable assignments when updating a record: The other way is reactive by using MvPACK. This removes all but the current MEMO value from the .dbt file.