Thank you.

I really did not want to move the dbc for some of the reasons you mentioned. I also did not want to change the dbc, remove all views and place them locally, as I did not want to create a new level of complexity.

We have been investigating many issues and have found that the speed issue involves one view. It is quite complex, so that it cannot be handled by the view designer, but must be created in code.

The issue is not if one person is using it, it is when the second user does. The first user has fairly good response, in the less than 10secs range when loading the form / using the form when it needs to be re queried. The speed issue happens when two users are accessing / using the form. Speed then crawls to minutes, sometimes as much as 2-3 minutes for the same re query.

Using the coverage profiler, gave me the line that takes the most time. It is the requery line.

Any ideas what might be going on?

The following things have been tried with no success.
1. Turn off anti-virus scans at the server/user machine levels.
2. Upgrade the network hardware. It is now a gigabit ethernet network.
3. Do no data on load, remove the re query to a separate method, only called when a change in parameters of the view are changed.
4. Confirm all indexes exist on all fields involved in parameters or table joins.


The original code was written in VFP 5, and I then upgraded the application to VFP 9. This is when the speed issues occurred. I did try using the set database behavior command to try and leave the view in VFP 5 format, but it made no difference in speeding it up.

Any other ideas?

TIA,
Mike


>Hi Mike.
>
>While putting DBCs on a local drive is fine for DBCs that contain only views, I'm not a fan of that technique for DBCs with tables. The reason is that if the DBC and tables are on separate drives, VFP uses absolute paths in the DBC (the path to the table) and DBF header (backlink to the DBC). That means all users have to have the same drive mapping.
>
>>1. How do I place the DBC locally and still have the data on the server?
>
>For a new DBC, simply create the tables on the server; VFP will store the paths in the DBC and DBF header. For an existing DBC, you'll need to use one of the utilities that comes with SDT to change the paths in the DBC and DBF headers. I'm at home right now and don't have access to the SDT docs, but it's described in the SDT help file.
>
>>2. How does this affect Stonefield updates?
>
>It doesn't. SDT properly handles the paths to the tables.
>
>>3. and How do I develop locally, and then deploy the finished product on a server? i.e. dbc local, data on server.
>
>You have to develop using the same pathing structure e.g. DBC on C: and tables on J:.
>
>>Therefore where would the Stonefield files go?
>
>It doesn't matter where they go; when you instantiate DBCXMgr, you specify the path to the SDT files.
>
>>If local, how do I get them to all of the workstations on load?
>
>You can copy the files from the server to the workstation as part of the app startup.
>
>Having said all this, I recommend you spend some time looking at the performance issues rather than assuming having the DBC locally will help.
>
>Doug