Hi Jim,

The user doesn't have direct access/control of the table. I't the program that does a data import from some flat files that does the adding of records. The user only picks the file(s) to process from a list and the program does the rest. The records are mainly start and end messages i.e. 'Begin download file FILE0001.TXT' and when new records are added to the data tables i.e. 'Added Part No. #AB12345 to PartsList table'.

It runs fine the first few days after the table is deleted and the system will recreate an empty free table when the app restarts and the table does not exist.

Thanks,
Arriyel

>Arriyel,
>
>Then I would surmise that THAT user is doing something 'different'.
>
>You might, for instance, want to ask the user to demonstrate exactly HOW they do their thing, and don't just stop once they've described the initial entry.
>For instance, they may believe that they can and should change the content of the MEMO field, for whatever reason.
>
>You may need to more "air-tighten" the program for odd-ball thingds that a user might do.
>
>good luck
>
>
>>Hi Jos,
>>
>>Thing is this only happens at one installation (customer) only. We have over a dozen other customers that does not have this problem.
>>
>>We've tried deleting the files then recreating them as new but the problem just recurrs after a while. We never delete records in this file (well maybe after a year or so when they archive the database). Most of our other clients naver have this table over 1Mb in a year.
>>
>>We only use INSERT SQL command to add records to this table.
>>
>>Thanks,
>>Arriyel
>>
>>>Hi Arriyel,
>>>
>>>1) If your note is never over 50 chars long then dont use a memo field at all. Rather use a char field which can be up to 254 chars. This is better and less prone to file corruption issues and completely removes memo field bloat as an issue.
>>>
>>>2) If record size is 89 bytes and you have 44 records taking up 20Mb then clearly there is a problem. I would suggest to scrap the file and create a new one which you can do when implementing (1) above.
>>>
>>>3) If the new file also grows so quickly are you sure the file does not have deleted records i.e. 44 non-deleted and many other deleted?
>>>
>>>4) What method are you using to add records? Simple APPEND's or something else?
>>>
>>>
>>>>Hi,
>>>>
>>>>We only add new records and never edit an existing one. The memo field content is never over 50 characters long, just some note about what occured.
>>>>
>>>>Also, the DBF is just too big at 20Mb. The recsize() is only 89 Bytes and it only has 44 records.
>>>>
>>>>Thanks,
>>>>Arriyel
>>>>
>>>>>Arriyel, because of what Yuri has already pointed out using a memo field for log operations is a bad idea if the same record's memo field is going to be re-used or added to often.
>>>>>
>>>>>If you are just adding records and each record has some memo data thats fine. But the bloat starts when you try to add to and/or keep changing an existing memo field.
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>We're getting a very strange problem with one of our log files. The table has 9 fields with 1 memo field.
>>>>>>
>>>>>>The file acts like an audit log and just keeps track of start and stop events and addition/modification of tables when a custom data import program is running.
>>>>>>
>>>>>>The problem is that when the data import program runs, the file seems to grow very fast very quickly within a couple of weeks. The last time this occured, the DBF file was 20Mb and the FPT file was 80Mb with only 44 records. We can browse the table (and memo fields) fine but when we packed the table, the DBF file remained at 20Mb but the FPT was just 20Kb.
>>>>>>
>>>>>>We've tried deleting the table and recreating a new one, but this works for only a few days then were back to the same problem.
>>>>>>
>>>>>>Any help is greatly appreciated.
>>>>>>
>>>>>>Thanks,
>>>>>>Arriyel