TomCarnahan
Programmer
I did a search on this topic, but did not see much that helped.
Here is my situation:
I inherited a client-server application that has MS-Access (.MDB) as front-end and SQL-Server 2000 as backend. The developer used the backend only as storage (ie. no stored procedures, views, user-defined functions, triggers, etc.) and chose to use a combination of ODBC-linked tables and DAO for connecting to the backend.
The application has a lot of processing on the front-end with local tables linked to ODBC-linked tables and is very slow. Lots of joins. Lots of network traffic. We have just less than 100 users. Unfortunately, my customer won't pay for the much needed re-design so I am trying to make small incremental improvements in maintenance.
I would like to move most of the processing to the backend, but that is impractical right now. However, I have to start reducing network traffic and speed up some forms and processes that involve this "unholy" alliance between local and backend tables.
I read about "disconnected" ADO recordsets and saw them as a potental help in this situation, unfortunately, the author of the book dealt with .ADP front-ends only, not .MDBs.
Question: can I use disconnected ADO recordsets in my situation for sourcing forms and for some of the processes where I need a temporary join of a recordset from the backend with a local table?
Can someone point me to some examples of where this is done?
Thank you ahead of time for any help you can provide!
--- Tom
Here is my situation:
I inherited a client-server application that has MS-Access (.MDB) as front-end and SQL-Server 2000 as backend. The developer used the backend only as storage (ie. no stored procedures, views, user-defined functions, triggers, etc.) and chose to use a combination of ODBC-linked tables and DAO for connecting to the backend.
The application has a lot of processing on the front-end with local tables linked to ODBC-linked tables and is very slow. Lots of joins. Lots of network traffic. We have just less than 100 users. Unfortunately, my customer won't pay for the much needed re-design so I am trying to make small incremental improvements in maintenance.
I would like to move most of the processing to the backend, but that is impractical right now. However, I have to start reducing network traffic and speed up some forms and processes that involve this "unholy" alliance between local and backend tables.
I read about "disconnected" ADO recordsets and saw them as a potental help in this situation, unfortunately, the author of the book dealt with .ADP front-ends only, not .MDBs.
Question: can I use disconnected ADO recordsets in my situation for sourcing forms and for some of the processes where I need a temporary join of a recordset from the backend with a local table?
Can someone point me to some examples of where this is done?
Thank you ahead of time for any help you can provide!
--- Tom