>George (and others)
>The question and solution raised invites a more general question- Wherever there is a posibility that a table may, over time, grow larger than say some Tens of megabytes, should practices dictate a test for disk space before the SQL. perhaps what I am asking is just a normal practise anyway. What would be the ramifications on overhead if the call for disk space was made before every SQL as one of the ever growing framework components ?
>TIA
>John Harriss

John,

I don't think that there's a generic, "one size fits all" solution simply because of varying system requirements. I do think that there are some steps that can be implemented to help reduce the nature of the problem.

1. All my systems have a Archive and Un-Archive options. This allows users to remove old data, and restore it when, and if, necessary. Some even have compression functions to help further.

2. Since all the data I deal with resides on a LAN, I take particular care to make sure that each workstation is properly configured. This means sending all ttemporary files to the user's local drive.

3. My older systems write a batch file to the user's boot drive's root directory, that will be called if the system is re-booted during the running of one of my applications. This batch file deletes any temporary files. With Win 95, however, this method is less relizable than it was under 3.1, so I'm im the process of a re-design of the solution. Probably along the lines of checking the temporary files directory for files that were created prior to the current system date/time.

It should also be noted that queries aren't the only source of temporary files. You can also get an insufficient disk space error when trying to PACK.

Having said this, I think that it's wise to try to get a feel for how many records a day might be added, so that planning for limited disk space can be done in the design phase, rather than as a reaction to a problem.