>I got a VFP5.0a application running on an NT server. The app goes over ODBC to Oracle to pull down personnel data into a remote view. The pull from Oracle is not fast, but since the data is not time critical, it only happens when the forms are first brought up.
>There is no update allowed back to Oracle.
>
>Was plagued with performance problems, especially on the last page of a pageframe that had a grid bound to a local view of a local table as a lookup mechanism. Upon activate, did a select of the view and a requery.
>
>I did finally get the response time I was looking for somewhere in drivers or settings. We have no idea what sped it up, but didn't ask questions and cloned the test machine's hard drive over to the user's computer.
>
>The remaining problem is; it runs fine unless I go to a second computer and run the app again. The second instance runs slow as can be, and also bogs down the first one. When I exit, then the first one speeds up again.
>
>I open the database shared. All the forms have the tables and views in the data environment. The DBFs,DBC, etc. are all out on the NT server. Did I miss a property or command somewhere?
>
>Thanks in advance

So its a Remote View into Oracle which is slowing things down? So that it seems as if the View is being re-started?

Make sure that the packet size is optimum for both Oracle and however its connected to the NT Server (and if there's any Netware in the way then the packet size has to be 256 as I recall). You should find that in the documentation for the Oracle ODBC driver.

Make sure its an up to date Oracle driver, I tripled the performance of a Btrieve connection by using the driver from Intersolv, they do try before you buy packages too.

You can try tweaking the number of records to transfer at a time, i think the default is 100, reducing the number means that its a little more responsive.

You can also set the Forms so that they don't automatically load the data.

When you first make a connection into a backend (grandmothers and sucking eggs warning on) it has to logon and verify you so the initial connection will always be slower. You can hide some of that by not using a View but SQL passthrough, i.e. building the SQL programmatically; for a tiny connection to the database to get you through the login verification and put that in a part of the application where the user won't notice the difference so much, say in a splash screen for the application's startup.

Mind you, subsequent connections to the Oracle backend may also startup login verification.

Personally this kind of thing just makes my day, diverts me from all sorts of other worthy tasks, but I know its a real gumption killer when you get it on an installed app.

Simon