They are local views, Hector, but thanks.

>I am not sure about the increase/decrease of performance that you will get.
>
>Yet, if you decide to create dozen views make you they share the connection. Establishing the connection takes a long time - sharing the connection reduces this time to a one-time-penalty (as opposed to a doze-times penalty.)
>
>Also, sharing the connection will allow you to use transactions on the server to commit/revert changes to all of them at once. Having separate connections for your views make the transaction processing a nightmare.
>
>>Hi Folks,
>>
>>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!