Re: CHANGING from DAO to RDO

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



Wait the APP(*.mde) is on a server? One of the key advantages of having a split DB is that each user has a copy of the Front End on his/her PC thus reducing network traffic. Also, are you using a true FE/BE configuration where there are two separate *.mdb files - one for the tables and one for everything else. Granted stripping out the non-table objects won't increase performance, but it will help when do COMPACT/REPAIRS and BACKUPS. As to the queries, to what degree have you looked into query optimization? If you haven't you should be able to find amble articles on it by doing a google.

CAUTION: If the MDE was built from the MDB DON'T delete the forms, queries, reports, etc. Once the original MDB that the MDE was created from is deleted or its objects deleted, you'll lose the source code.

R. Paulson wrote:
No its the MDE which is 70 Megs, the MDB is about 200mb. And I have 70+ Concurrent acctive users. To boost the speed we use Terminal Server 2003 and it definetly helps on the fact that we get less corruption, but certain queries take awhile and we want to add more users. The App/db is on a 2003 server sp1 Runtime 2002 on Dual Xeon 3.0 2.5 Gb Ram and a RAID 0 (two disks 155 Mb /sec write). We need more speed and able to handle more concurrent users I want atleast 200. Any suggestions.

"Larry Linson" wrote:


For a long while, Microsoft was heavily promoting ADO, but in recent times, knowledgeable Microsoft insiders (including one who was Product Manager for ADP and ADO in a previous version) recommend MDB-DAO-Jet-ODBC-Server as generally preferred over ADP-ADO-OleDB-SQL Server.

I don't know _where_ you got the idea that ADO and RDO were the only methods to access SQL Server. In fact, I have never heard of anyone using RDO with an Access database, only, in the past, with the separate VB product. The VB crowd abandoned it for ADO with SQL Server, even though they, too, could use DAO and, for them too, DAO was simpler and easier.

My experience with ADP and ADO did not convince me that there was any advantage at all. And, if you think the changes to your MDB to make it work well are extensive, those would just be the beginning of the changes you'd be facing.

70 MB is not an exceptionally large Access database -- you have 1930 MB more to go before you bump into the 2GB limit.

I presume you have split the database and are talking about the back end where data is stored. I also presume that you Compact the DB on a regular basis. If not, those are steps to take very soon.

You might take a look at MVP Tony Toews' site, http://www.granite.ab.ca/accsmstr.htm for the best tips and hints I have found about performance and avoiding corruption in the Access - Jet multiuser environment. I'd suggest that working to improve what you have would be a good idea, before going off half-cocked into an "upgrade" process that may well overwhelm you.

 Larry Linson
 Microsoft Access MVP



"R. Paulson" <RPaulson@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:519C9797-4901-435D-AB4A-23D2E16503E2@xxxxxxxxxxxxxxxx

Yes I can get that far, but its my program that stilll needs have a lot of
the syntax changed, and my App is pretty Big 70 Megs. Lotta Code. I found a
site that does the job but its a solution not a product and Im sure its big
bucks. www.convertertechnology.com


"David C. Holley" wrote:


It is my understanding that Access can setup links to a SQLServer DB
using ODBC. I just tried it as a test and didn't have any problems. I
was then able to use DAO to to read the data.

MVP's educate me please.

R. Paulson wrote:

Yes I do need to convert it, the db gets to big, and e have too many users I
have to repair it quiet often, so the plan is to move it to SQL, and in DAO
you can't connect only with ADO or RDO. Any Help?


"David C. Holley" wrote:



I can't answer that question, but perhaps the question to ask is - Do
you need to convert? I would put it as WHY do you want to convert it?

R. Paulson wrote:


Is there any shortcut (tools, etc) to change my app which is currently in
DAO, I would like to convert it to RDO or ADO. Any help?



.



Relevant Pages

  • Re: DAO vs ADO
    ... ADO ... > extra overhead retrieving metadata from the server for each query. ... > but I feel DAO is not as unsuitable as is often assumed. ... and ADO when working with SQL Server data. ...
    (microsoft.public.access.conversion)
  • Re: DAO vs ADO
    ... I believe it is not a universal truth that DAO/JET is less efficient than ADO ... extra overhead retrieving metadata from the server for each query. ... I'm not actually saying DAO is preferable to ADO for accessing server data, ...
    (microsoft.public.access.conversion)
  • Re: DAO vs ADO
    ... I believe it is not a universal truth that DAO/JET is less efficient than ADO ... extra overhead retrieving metadata from the server for each query. ... I'm not actually saying DAO is preferable to ADO for accessing server data, ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Excel reference in VB
    ... You can connect to any Access database using ADO or DAO. ... think it'll do Excel, as well. ... runs multiple exes (which accesses my db - that is on another server), ...
    (microsoft.public.vb.general.discussion)
  • Re: CHANGING from DAO to RDO
    ... I somewhat assumed that since ADO is younger than DAO that there were already a whole bunch of Access FE/SQLServer BE implementations out there. ... In fact, I have never heard of anyone using RDO with an Access database, only, in the past, with the separate VB product. ...
    (microsoft.public.access.modulesdaovba)