CONNECT MDB FILE FROM ADP FILE

T

TL

Hello.

From a adp project connnected to a MSDE database, i have local setting in a
local mdb file.
The connection with ADO to the mdb is only read access.
The connexion with DAO works fine but always give me a log windows and a
error message at the first connection to the mdb database. The second
connection is successfull without any log window or error.
I whant to connect to the mdb file with DAO without error message and
without log window.
Can someone hepl me? Thank you.

My code:

Global MyWorkSpace As dao.Workspace
Global MyDbMdb01 As dao.Database
Global rs As dao.Recordset

Private Sub Form_Open(Cancel As Integer)
Set MyWorkSpace = DBEngine.CreateWorkspace("PciWS01", "TheLogOfThierry",
"ThePwdOfThierry")
Set MyDbMdb01 = MyWorkSpace.OpenDatabase("C:\MyLocalDB.mdb")
Set rs = MyDbMdb01.OpenRecordset("SELECT * FROM ListCrit01",
dbOpenDynaset)
Set Me.Recordset = rs
.....
 
S

Sylvain Lafontaine

Don't know what kind of workspace is the default under ADP, so maybe you
should add the fourth parameter and try with either dbUseJET or dbUseODBC.
The following articles gives you all the details:

http://support.microsoft.com/kb/164481
http://support.microsoft.com/kb/208804
http://support.microsoft.com/kb/209953
http://support.microsoft.com/kb/210259

Some people are also using the value dbDriverCompleteRequired as the second
parameter to the OpenDatabase call, for example:

http://download-east.oracle.com/docs/cd/B10501_01/win.920/a97262/ch5.htm

Using ADO should be the easiest way to do this and the fact that you got a
read-only access indicate that maybe you have used the wrong parameters or
that you have a permission problem.

Finally, even if you are doing this in a ADP project, this is pure
ADO/DAO/VBA code with no direct relation to ADP or SQL-Server; so you should
ask in a more appropriate newsgroup is you want some more useful answers.
 
A

aaron.kempf

yeah dude.. Just use ADO

ADO is bigger, better faster; anyone using DAO is too rusty
 
T

TLPCI

yeah dude.. Just use ADO

ADO is bigger, better faster; anyone using DAO is too rusty







- Show quoted text -

Thank you all for the answers. The way you gave me even if it doesn't
give me the solution are interesting and I will return the solution as
soon as I finf it.
I dont need preformance to use the local setting stored in my local
mdb file so dao is not a bad solution.
The code I gave work fine in a mdb file so my problem seems to be
specific to adp files.
There is something about a conflict between the default workspace
logged onto MSDE and the one I create to log to the mdb database.
I comme back as soon as possible.
Thank you again
Thierry
 
R

Robert Morley

Contrary to what Aaron apparently said (see explanation below), DAO is
*MUCH* faster than ADO. ADO has several advantages that DAO doesn't (such
as disconnected recordsets, asynchronous access, and a whole lot more), but
on Jet databases, speed is NOT one of them.

Aaron: somewhere along the line, your messages are being blocked, and it's
not on my end. Since there's only my newsreader and Microsoft's servers
involved here, I'm forced to assume that someone at MS finally got sick of
your trolling and put you on a black list of some sort. If you want to
respond to this and try to prove me wrong (and believe me, I've done the
tests, so I know I'm not), I'm not likely to receive it unless someone else
responds to it and quotes the whole thing.



Rob
 
P

PFC Sadr

Rob;

what the hell are you talking about dude

speed is faster, who gives a flying **** about MDB; use SQL Server

and Rob; for the ****ing record-- yeah; Microsoft started censoring me
long beforeI started swearing.

Microsoft should not block ANYTHING in a PUBLIC FORUM

I got fired for bitching at Microsoft on a PRIVATE FORUM.
So the morale of the story is-- don't bitch about Microsoft or they
will CENSOR YOU

I just want to know-- how can I use the internal newsgroups; aren't I
eligibile because i'm a triple MCP?

-Aaron
 
O

onedaywhen

Contrary to what Aaron apparently said (see explanation below), DAO is
*MUCH* faster thanADO. ADOhas several advantages that DAO doesn't (such
as disconnected recordsets, asynchronous access, and a whole lot more), but
on Jet databases, speed is NOT one of them.

I do not dsagree with your 'speed is NOT one of them' comment but how
significant is this issue e.g. would it be fair to say that there is
unlikely to be any significant difference in performance between ADO
and DAO for at least 90% of operations across all Access users?

Jamie.

--
 
R

Robert Morley

Oh, there's no question of that; the speed would be irrelevant for many
users in many situations, and in fact the OP said that speed was not a
factor for him in this case. I simply wanted to correct the assertion that
ADO was faster than DAO. Better in any number of other ways, definitely,
but definitely not faster (and let's not even talk about ADOX Catalogs on
Jet databases <eg>).



Rob
 
O

onedaywhen

Oh, there's no question of that; the speed would be irrelevant for many
users in many situations, and in fact the OP said that speed was not a
factor for him in this case. I simply wanted to correct the assertion that
ADO was faster than DAO. Better in any number of other ways, definitely,
but definitely not faster (and let's not even talk about ADOX Catalogs on
Jet databases <eg>).

FWIW I've not had a problem with the OpenSchema method rowsets (ADOX
uses OpenSchema itself!) and often working with a recordset (Filter,
Sort, GetRows, GetSting, etc) is preferable to a VBA.Collection.

Jamie.

--
 
R

Robert Morley

I've seen extreme sluggishness out of the ADOX methods of retrieving things
like table/query lists. I don't remember the specifics, as it was a long
time ago, but I just remember that you did NOT want to use them if you had
any other choice. I can see the benefits of being able to filter and so
forth, though. Not really a concern for me at this point, as we've moved to
SQL Server for what we're doing, so we have no Jet databases whatsoever
(which is why I'm getting so rusty!).


Rob
 
A

aaron.kempf

Rob

please take your DAO crap and shove it

this person has already seen the light

ADO _IS_ faster than DAO if nothing else; because
currentproject.connection returns an ado connection

does that exist in ADP?

STFU mdb newbie
 
A

aaron.kempf

Robert;

you should use Data Projects, dog




I've seen extreme sluggishness out of the ADOX methods of retrieving things
like table/query lists. I don't remember the specifics, as it was a long
time ago, but I just remember that you did NOT want to use them if you had
any other choice. I can see the benefits of being able to filter and so
forth, though. Not really a concern for me at this point, as we've moved to
SQL Server for what we're doing, so we have no Jet databases whatsoever
(which is why I'm getting so rusty!).

Rob







- Show quoted text -
 
A

aaron.kempf

and for the record; I've never ONCE had to use ADOX.

I mean -- ADOMD _YES_

ADO on the clientside YES
but ADOX?

I just dont' think that it's necessary for anyone; sortof like DAO
 

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.

Ask a Question

Top