Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Library Problem

Status
Not open for further replies.

LittleSmudge

Programmer
Mar 18, 2002
2,848
GB
A have a Access 2000 database split FrontEnd / Back End and using Access standard security model

Both Front and Back are in the same public server folder along with the xxx.mdw file

I use ADO so I need the ADODB library reference linked
C:\PROGRAM FILES\COMMON FILES\SYSTEM\ADO\msado21.tlb

I use Catalogues so I need ADOX library reference linked
C:\PROGRAM FILES\COMMON FILES\SYSTEM\ADO\MSADOX.DLL

and I use Recordsets so I need ADOR library reference linked
C:\PROGRAM FILES\COMMON FILES\SYSTEM\ADO\MSADOR15.DLL

This all works fine on almost all of the machines that need it

HOWEVER,
On one machine ( A Dell Lap Top - Don't laugh ) I have the following problem
When I link in the ADODB file using the Tools, References it displays at the bottom of the dialog box the path as being
C:\PROGRAM FILES\COMMON FILES\SYSTEM\ADO\MSADO15.DLL

Now this is doubly wierd because that files does NOT exist ANYWHERE on the C: drive - I've searched and deleted every occurance I could find.
However, I cannot get it to see the correct file which is there.
I've also used a piece of code to link the library based on the path/filename which works on other machines but to no avail here.

Any ideas ? Anyone seen something like this before ?



SECOND PROBLEM MACHINE
( Also a Dell LapTop - now I told you before not to laugh ! )
The Tools References dialog box lists all of the correct library links.
However, using a VBcode investigator that lists the links
The ADOX library reference
C:\PROGRAM FILES\COMMON FILES\SYSTEM\ADO\MSADOX.DLL
never shows up.

If I unlink it via the dialog box I can use the code linker to link it again. This appears to work successfully.
The dialog box shows it as being linked again but the code lister still does not find it.
More importantly - dispite the Tools References dialog box showing it as successfully linked, the code crashes when it tries to execute code that need the ADOX library.

Any ideas ?


I don't like it when machines lie to me !





G LS
accessaceNOJUNK@valleyalley.co.uk
Remove the NOJUNK to use.
 
I don't know if this helps but on my machine, which hasn't been used more than a few months
MSADO15.DLL is the ADO 2.6 Library
MSADO21.TLB is the ADO 2.1 Library

Can you try the
Set object = References.AddFromFile(filename)

to do it?
And put them somewhere central?
 
Yes, I'm using

Code:
Set object = References.AddFromFile(filename)

already. It reports back that it has been successful - then when I use

Code:
For Each ref In Application.References
        txtLinks = txtLinks & IIf(ref.IsBroken, "Broken", "Ok") & " " _
                            & ref.Name & " " & ref.FullPath & vbCrLf
    Next

It fails to find it.



G LS
accessaceNOJUNK@valleyalley.co.uk
Remove the NOJUNK to use.
 
you've got me intrigued, so I was experimenting.
I deleted the file that the reference indicated it was using, but I could still add it using AddReference or the menu. I renamed it; same. I moved it to the A:drive. I could still add it with AddReference (using the a:\ path) but in your code to display the path it showed up as the original path:

So
Set MyRef = References.AddFromFile("a:\msado20.jun")
worked ok

then
For Each REF In Application.References
txtLinks = txtLinks & IIf(REF.IsBroken, "Broken", "Ok") & " " _
& REF.Name & " " & REF.FullPath & vbCrLf
Next
gave
Ok ADODB C:\Program Files\Common Files\system\ado\msado20.tlb

And when I rebooted, the original reference was back in
program files\common files\system\ado

There's something about these DLLs that I've heard about that I don't exactly remember ... Windows figures out what they are and what their file names should be even when you move them, rename them etc.
Maybe this helps ... I'm at the outer limits of ignorance here.
Alasdair
 
Alasdair - Thanks .

I little clue here - and another there, it all adds up .

You experiment confirms that it is a real issue - which is useful in its own right.


I'm beginning to wonder if this is something to do with a Regestry issue.
These machines are all 'locked down' but the corporate IT dept and I wonder if things like DLLs have a 'presence' in the file structure - but the real data/workings are connected via info that is locked in the registry - Which we cann't get to.



G LS
accessaceNOJUNK@valleyalley.co.uk
Remove the NOJUNK to use.
 
Now, in frustration I tried:-

Moving a copy of the FrontEnd .mdb file onto the offending machine's C:\ drive rather than being on the network.

NOW IT WORKS FINE !

What IS going on ?



Fundimental question to my understanding:
When I link a library : Am I linking it to my running copy of Access.Exe or am I linking it to the xxx.MDB file.

Or is there some interaction between them ?

Therefore, If I change the linking on one person's machine when the xxx.mdb is on the network in a central location - does that affect everyone else ?


Confused, of Coventry.



G LS
accessaceNOJUNK@valleyalley.co.uk
Remove the NOJUNK to use.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top