Re: Accessing mdb file via VB code


"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





.

Relevant Pages

  • Re: Registry replacement advice
    ... The DAO runtimes are ... DAO whose install did not do version checking and everything would go all to ... having to write more code to ensure the integrity of the database itself ... productive working with XML than any of MS's database solutions...plus there ...
    (microsoft.public.vb.general.discussion)
  • Re: OT: Custom unattended XP install
    ... I have to build about six boxes a month and an customized unattended XP ... It's nice that I get to play with the latest stuff all the time and constantly sell off ... was about 3 times faster than my last box, for $379, including a ...
    (rec.crafts.metalworking)
  • Re: OT: Custom unattended XP install
    ... It's nice that I get to play with the latest stuff ... my personal boxes every few months and get new ones. ... I need to clone drives more often, ...
    (rec.crafts.metalworking)
  • Terminating phone service at a multiple unit building [Telecom] (was: AT&T U-verse)
    ... Those grey plastic boxes with the network interface are meant for single ... about to install. ... her permission to have the phone company install an outside box. ... telephone service and inside wire. ...
    (comp.dcom.telecom)
  • Re: Dao350.dll unsupported under Windows 7
    ... because I had problems when the installer of the VB5 version ... attemped to install the DAO 3.51 dll on Vista. ...
    (microsoft.public.vb.general.discussion)
Loading