R
R. Paulson
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?
DAO, I would like to convert it to RDO or ADO. Any help?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
D
David C. Holley
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?
you need to convert? I would put it as WHY do you want to convert it?
R
R. Paulson
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?
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?
D
David C. Holley
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.
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
R. Paulson
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
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
L
Larry Linson
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
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
D
David C. Holley
THX. I thought that I was on the right track. 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. If I recall correctly,
Access 2.0* came out circa '93-'94, SQLServer early-mid 90's, and ADO
late 90's (1998 or so?).
*Yes I used A2.0. If you never used A2.0, A95 or A97 you don't know what
your missing - thankfully.
David H
since ADO is younger than DAO that there were already a whole bunch of
Access FE/SQLServer BE implementations out there. If I recall correctly,
Access 2.0* came out circa '93-'94, SQLServer early-mid 90's, and ADO
late 90's (1998 or so?).
*Yes I used A2.0. If you never used A2.0, A95 or A97 you don't know what
your missing - thankfully.
David H
R
R. Paulson
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.
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.
D
David C. Holley
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.
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
R. Paulson
Yes they are split, but We use the FE in W2k3 terminal server, which reduces
evn more reduces network usage for the db is never sent just tiny images, and
also it increses overall speed, when we jumped to terminal server speed
increased over 65% in overall db usage acces and even program load, I can
have a Celeron 333 or less running the The App/db fine (on a terminal
session). And curruption has decresed from 3 times a week to maybe once a
month, if that, th the backend is never replicated then updated, its all
locally as if one user on his machine has both FE/BE and opens many sessions
of the FE and works simultaniously.
evn more reduces network usage for the db is never sent just tiny images, and
also it increses overall speed, when we jumped to terminal server speed
increased over 65% in overall db usage acces and even program load, I can
have a Celeron 333 or less running the The App/db fine (on a terminal
session). And curruption has decresed from 3 times a week to maybe once a
month, if that, th the backend is never replicated then updated, its all
locally as if one user on his machine has both FE/BE and opens many sessions
of the FE and works simultaniously.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.