Re: Accessing mdb file via VB code


"AK" <nospam@xxxxxxxxxxx> wrote in message
news:%23t6Y07GoGHA.4736@xxxxxxxxxxxxxxxxxxxxxxx
Hello All

None of the previous installs re-registers etc worked but I got it fixed
as
indicated below by doing what BobOBob calls banging uranium together..

Go Figure!

If any of you know why my string would not work, please reply. I want to
learn.


*************
Solution -
*************

I goggled around and came across a reply by Veign at:

http://www.codecomments.com/archive344-2005-10-672548.html

Where he says :

<SNIP>
You need a connection string like:
oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=c:\somepath\mydb.mdb;" & _
"Jet OLEDB:Database Password=MyDbPassword"
<SNIP>


OK I bit at the bait - rather I grabbed at the straw out of desperation.

My connection string was:


strConn = "Provider=Microsoft.Jet.OLEDB.4.0;Data " & _
"Source=" & m_sDataFile & ";" & _ 'm_sDatafile is my
path to my Database
"Jet OLEDB:Database Password = MyPassword; &
Mode=ReadWrite;"

Note how my connection string had a Mode=ReadWrite at the end.


I removed this and everything worked. (till it blows up in a mushroom
cloud
at least)

strConn = "Provider=Microsoft.Jet.OLEDB.4.0;Data " & _
"Source=" & m_sDataFile & ";" & _ 'm_sDatafile is my
path to my Database
"Jet OLEDB:Database Password = MyPassword"



I hope this solution provides insight to the nature of the problem and
helps
any others out there comment on why the Mode parameter killed things.
Although I did not write the previous code, I looked at the ado books and
it
appeared to me that the only thing that the Mode parameter was doing was
telling the connection what the premissions were that the data consumer
could have. Apparently there is more to it. Hummm maybe the mode is only
if
the premissions are at a level less than ReadWrite?

Ralph, lets post this "Solution" to our memory banks as I bet we see this
problem again.

AK


"Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
news:3r6dnW6HVrK0sDbZnZ2dnUVZ_sCdnZ2d@xxxxxxxxxxxxxxx

"AK" <nospam@xxxxxxxxxxx> wrote in message
news:OzsFjZ5nGHA.1248@xxxxxxxxxxxxxxxxxxxxxxx
My Reply In line

I am using MS VB 6.0 SP6 the about says it is Ver9782, Forms3:
11.0.6550
Win XP SP2
Access being used "out of the box". My application works fine when
running
without a password.



<Snip>
If you are using ADO and ADO providers are you by any chance using a
"DAO"
control (DataGrid) on this second form?



How did you know? Yes I am.
Works for the form that had a flexgrid. It is when I click to the form
having the datagrid when I get the error.


Ok, then Personally I would blow off all DAO controls. You don't need
them,
unless you are using DAO, and it sounds like this is the problem.



If so you will need to make sure the DAO components and typelib are
installed and registered. You should find them in Progr~Files\Common
Files\Microsoft Shared\DAO. This is the simple fix.

OK, I reregistered the dlls, Dao350.dll and Dao360.dll with regsvr32

In the folder there is also type lib in there named DAO2535.TLB

Am I supposed to do somthing with this file. I tried the regsvr32 on it
but
that says it is not an exe or dll. Am I supposed to do some other
action
on
it??


To register typelibs checkout this utility...

http://www.vbaccelerator.com/home/VB/Utilities/Type_Library_Registration_Utility/article.asp
There are others, but this at least explains what's going on.
The DAO2535.tlb is used for development - ignore it in this situation.



[Occasionally these files are not correctly installed or registered
on
WinXP
boxes with Jet4. Also be aware - the problem is not that you are
using
or
accessing DAO from your program, the problem is that these controls
need
the
DAO to be properly installed. Therefore this has nothing to do with
project
references.]

If that doesn't solve the problem then try this...
http://support.microsoft.com/default.aspx?scid=kb;en-us;299457
Make sure you have only one MSVBVM60.dll on your machine.

I did a scan and I only have one MSVBVM60.dll on my machine.
I looked over the KB article you mentioned above and under the
"resolution"
section is says:

*********
"To resolve this problem, make sure that the version of MSVBVM60.dll is
the
same version that is distributed with Visual Basic 6.0 SP4 (which is
6.00.8877 for SP4 and 6.00.8964 for SP5). MSVBVM60.dll is located in
the
\WINNT\System32 or \Windows\System folder.""
************

OK Mr Gates, are you sure that you are really telling me here that I
need
to
roll my MSVBVM60.dll which was installed with VB6 SP6 and is version
6.0.97.82 BACK to a version from an earlier service pack, i.e to dll
version 6.00.8877??? (I mean I am reading the language as telling me
exaclty
that but...... Additionally, if so, where do I get the dll that is
distrubuted with VB6 SP 4?

Ralph is this correct? Am I really supposed to get an earlier SP4
version
of
the dll and register it, even though I have VB6 w/ SP6 installed?
Sounds
odd
to me. If this is what I need though, do you know where to get the
earlier
version from a "clean" site?


That does appear to be the 'cure' in many cases. but I never get the
followup, thus I have no knowledge of long-range consequences. To my
mind
it
seems like there would have to be.

Since running into this problem several times myself, and doing a bit of
research (googling, inventoring components, ...) I don't have an answer.
MS
remains mute (or at least I can't find the blog). Also what works for
one
often doesn't work for another.

Some people report it as happening to an entire new suite of boxes.
Others
report scattered behavior. In cases where I have been called in, it has
been
the latter. Each incident though isolated appeared on boxes that showed
no
obvious difference between its inventory and configuration than its
brethren.

I am only rattling on in hopes someone else out there that KNOWS, will
jump
in.

So the only 'cure' I know of is to install an old version of
MSVBVM60.dll
or
completely re-install everything. I usually do the latter, because while
a
lengthy PITA - it will at least eventually provide a solution. I have
wasted
days popping components in and out and still didn't get it to work. <g>


-ralph



Thanks


AK


If that doesn't seem to resolve the problem, then it is caused by
another
miss-match of components. If you are still having trouble report back
with
all the specifics of your problem domain. (Data Access Libraries, OS
version, Jet, MDAC, etc.) You can fiddle away one by one, or simply
burn
everything MDAC/Jet down to the water line and start over.

hth
-ralph



My "memory banks" are incredibly faulting and are not to be trusted. I have
been bitten by an odd connection string causing odd problems so often it
isn't funny, yet since you said one Form worked and another didn't - I
assumed the connection was OK.

[Note that word - "assumed".]

Glad it is working.

-ralph


.

Relevant Pages

  • Re: Accessing mdb file via VB code
    ... pasture "over there" that we would not have seen otherwise. ... None of the previous installs re-registers etc worked but I got it fixed ... You need a connection string like: ... Some people report it as happening to an entire new suite of boxes. ...
    (microsoft.public.vb.general.discussion)
  • Re: Accessing mdb file via VB code
    ... None of the previous installs re-registers etc worked but I got it fixed as ... You need a connection string like: ... then Personally I would blow off all DAO controls. ... Some people report it as happening to an entire new suite of boxes. ...
    (microsoft.public.vb.general.discussion)
  • Multipart connectionstring question
    ... I’ve got an asp.net site that contains an access database. ... running the same app both on my machine and my host without making changes. ... How could one even use a server.mappath with a database connection string? ...
    (microsoft.public.dotnet.general)
  • Installer - Custom Textboxes in UI problem
    ... void Install function. ... I've tested it by writing the string out to a text file ... put the connection string and I intend to test the db connectivity and write ... throw new InstallException("The database conection information is not ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: EXEC master..xp_cmdshell Prevention
    ... way to significantly reduce vulnerabilities around dynamic string execution. ... > I found that my web application did use a connection string in a file ... I have created a new login account ...
    (microsoft.public.sqlserver.security)