>>John can you define a DSN as you use it above and in you opinion would this direction make the application run slower? The people who are forcing this issue on us are the Network folks, who claim our current operation of having EXEs and data residing on the network, is slowing the network down. They wanted us to investigate an SQL server configuration to alleviate the network slowness.


DSN stands for Data Source Name. These are maintained by the ODBC connection manager. While you can do DSN'less connections - creating DSN's simplify things a lot.

As far as your app running slower - it might and might not. There are many factors to consider:

1. Does the EXE reside on the client or server? Better performance can be achieved by having each client have a copy of the EXE. From a maint. standpoint - this stinks as you have de-centralized things. But, at times, it may be a necessary evil.

2. Where are your temp files getting stored? Your config.fpw should have TMPFILES, SORTWORK, and PROGWORK all pointing to something like C:\TEMP. This can greately reduce network traffic.

3. SYS(3050) settings. Setting foreground and background memory buffers can help. Mac Rubel has a nice article on performance in FoxPro Advisor.


Going to SQL/Server can help - but then again - it might not help as much. You may have many reasons for going to SQL/Server. But, performance should not be the number one reason. Rather, top reasons should include needs for replication, transaction logging/rollback, security, large data sets, etc. Often, performance degrades a bit when going to SQL/Server. It definitely changes the way you need to view your data. For example, with native access, we think nothing of doing a USE on a table with a million records or so. Doing the same thing in SQL/Server is very different as dragging a million records accross your network may make you and the network cops bitter enemies<g>. Just going to SQL/Server usually does not help. Going to SQL/Server and re-engineering your app may.

I would suggest checking your configuration, where temp files are going, memory settings, etc. before making the leap to SQL/Server.