TransferDatabase broken by new PC

[Guest]

The following code runs fine on my old computer (a Dell with XP SP2 on a
Windows SBS 2003 domain):
DoCmd.TransferDatabase acLink, "ODBC", "ODBC;" & _
strConnectionString, acTable, "dbo." & TableName, "dbo_" &
TableName
It links an existing table in a SQL Server database to an mdb.
When I run the same code on a new PC (also a Dell with XP SP2 on the same
domain) I get an error: "can't find the object dbo_TableName". This error
occurs booted into safe mode so it shouldn't be interference from another
application. The mdb references (Tools\References on the VBA menu) are the
same versions on both PCs. I've reinstalled Office 2003 and have been to the
Office Update site. Nothing works.
What am I missing here? Any ideas?
Thanks in advance.
Jay

 

[Nick Coe \(UK\)]

Firstly check ODBC configuration on the new machine. IIRC
it's in Control Panel/Administrative Tools on XP. You may
find there's no DSN for Access or SQL Server or both.

Second check the policy and permissions for your user in
SBS. Whilst unlikely, they could have been changed by
accident when you joined the new machine to SBS.

--
Nick Coe (UK)
http://www.alphacos.co.uk/




In jay typed:

 

[Guest]

Nick,
Thanks for your suggestions. There are various System DSN entries for
access and sql server, but I'm not having problems connecting to the sql
server db for other functions. For example, I can create the table in the sql
server db to which I want to link using the ADODB Command object with no
problems. It's just the DoCmd.TransferDatabase command which is failing on
the new PC only.
Permissions must be OK, because the code works on the old PC with the
same login.
Do you have any ideas on what DLL's the TransferDatabase depends?
Everything that is obvious to me is the same version on both comptuers.
Thanks again.
Jay

 

[Nick Coe \(UK\)]

Time to double and triple check your references I think,
read up at Allen's site below - he's got a table listing the
dll's :

Allen Browne's website :-

http://allenbrowne.com/ser-38.html

Doug Steele's website has a good write up on reference
problems and some very useful links:

http://www.accessmvp.com/djsteele/AccessReferenceErrors.html

Unregistering and re-registering a suspect dll can cure a
problem like that.

If you feel really ambitious you could try using Dependancy
Walker to establish _exactly_ what each dll's dependancy is
but that may prove over complicated at this stage - I
suggest you first do a boring old re-check of references
after checking out Allen and Doug's sites and then dive into
the glamorous and headachey world of dllhell )

http://www.dependencywalker.com/

--
Nick Coe (UK)
http://www.alphacos.co.uk/




In jay typed:

 

[Guest]

Nick,
Thanks for the great suggestions ... what I need now is direction. I'll
pursue this and get back to you at this thread.
Jay

 

[Guest]

Nick,
I gave in and phoned the Microsoft tech support line. The culprit:
-- Microsoft Office Plug-in in Norton AntiVirus.
I deactivated it and now everything works like a charm. I thought I'd
ruled out that sort of program interaction by demonstrating that the problem
existed in safe mode but that is apparently not the case.
Thanks for your help and your interest.
Jay

 

[Nick Coe \(UK\)]

Thanks for posting your findings Jay - I've learned
something there!

--
Nick Coe (UK)
http://www.alphacos.co.uk/




In jay typed: