John,

Probably too simplistic, but not to be overlooked -- can you segment the data or even archive off some of the older stuff? I recall an old Fox 2.6 app we had that was just too darn big, so for older data we split into different folders and then just set our path accordingly once the user chose a data segment. Of course, if your app allows lots of multiple records up at once or if the users need to see everything all the time, disregard my silliness. *smile*. We just liked the data segmentation because it meant the rest of the app was left unchanged.

Otherwise I like the use of separate docs instead of Generals. I used to have a database table full of screen shots until the FPT reached 400MB in about 2 months. I split off the screenshots now (and store as JPG), and everything is MUCH better...

JoeK

>I have an application that's a secure document management system. Each document is composed of contract clauses, each of which is stored in a General field. Each client can have multiple documents.
>
>This application evolved over time and the document child table now has about a dozen General fields. The document table is represented in the main application screen by a view (for simplicity, I'll call it lvdocuments). Lvdocuments is optimistic table buffered and in the application it's requeried if the user clicks on a list of documents for the current client and when the client is changed. The client table is a table and is optimistic row buffered.
>
>The client is concerned about the speed of the application. It's a bit more sluggish as time goes on. I have been considering moving each document clause (read: General field) into a grandchild table, but my main question is this:
>
>Will the general application speed increase or decrease by remiving all of the General fields from the documents table and putting them in child tables? Each table is much more lightweight, but then I have a dozen more views to requery...and then there's the issue of updating and reverting if the user changes the current document while editing.....
>
>This is the only application I maintain that uses a slew of General fields and I'm thinking the answer is not so obvious....
>
>Opinions and ideas are welcome!