Copied DB remembers old path; gives error (2000)

Topic

New Reply

I copied an Access 2000 database to a new directory on the Novell network
(same drive letter). I provided the users a shortcut to run the database
(the command is the path of the DB, and the startup directory is the new
path). I also deleted the old directory. I gave the new directory all the
same network permissions as the old one (the users have full permissions).

Now, for some users (but not all), whenever they start up the DB using the
shortcut, they get the message “Microsoft Access can’t change the working
directory to ‘.’ Verify the drive is valid and the path is
260 characters or less in length.”

This message doesn’t appear when the same user just runs Access, then opens
the database using File – Open, but of course I need them to be able to use
the shortcuts. I’ve tried several things, including changing the default
directory in Tools – Options – General, and running a database
repair/compress (more than once). How do I get rid of this “old memory” the
database doesn’t seem to want to give up?

Thanks for any info — Warren

P.S. Yes, I’ve thought of changing all the shortcuts to have a command like
“C:Program files….Msaccess “, but just using the path name
seems somehow cleaner. And I’d rather not change ALL those shortcuts, and
besides–it just bugs me that I don’t know why this is happening!

Reply | Quote

Replies

By chance are you using security? If so, Access may be trying to find the security file on the old path. Another possibility is that there is a working directory set on some of the shortcuts and not on others. Hope this generates some ideas.

Reply | Quote

No, not using security. And no, the problematic shortcut I’m using as a test case definitely has the correct working directory listed (I’ve changed it, and changed it back, several times to make sure).

Reply | Quote

When you say “working directory”, are you talking about the target directory or the “start in” directory in the shortcut? I’ve occasionally run into this when I copied a shortcut to another machine and remembered to change the target but forgot to fix the “start in” folder.

Reply | Quote

> I’ve occasionally run into this when I copied a shortcut to
> another machine and remembered to change the target
> but forgot to fix the “start in” folder.

Quoting from the 2nd sentence of my original post: “I provided the users a shortcut to run the database (the command is the path of the DB, and the startup directory is the new path).” I’ve gone back and checked that several times, just to make sure.

Reply | Quote

I read your post, I just wasn’t sure we were talking about the same things.

Reply | Quote

I see this problem sometimes on our Academic network. I’m no nethead but I think the problem goes as follows:
Access is installed with the default directory for saving new files etc. set as U:. All Student profiles have a U: drive (their user area).
My log in as a Staff member does not have a U: drive so I get that message. Access seems to work OK after clicking OK. Maybe that will ‘jog a cog or two’.
HTH

Reply | Quote

As I said in the original post, I changed the “default directory for saving new files” in Access, and that didn’t fix the problem. (That default directory was originally set to C:Program Files anyway, and all workstations have that directory, so it wouldn’t have caused the problem in the first place.)

And yes, Access works OK after acknowledging the error message. But that’s not going to fly (for very long) with my users.

Reply | Quote

Sorry for the late reply. I experienced the same sort of problem. I decompiled the database then recompiled it and it ran fine.

Reply | Quote

> I experienced the same sort of problem.
> I decompiled the database then recompiled it and it ran fine.

Uh, please forgive me, but how do you decompile a database?

Reply | Quote

Look at this post for this.

Pat

Reply | Quote

Sorry, decompiling and recompiling the database didn’t work. And creating a new database, while not impossible, would be a bit of a pain since there are several ODBC tables which (in my experience) don’t transfer over properly during a database import. When we tried this in the past, we’ve always had to re-link the tables manually, one by one.

Reply | Quote

Do you have the old path in a hard coded OpenRecordSet or OpenDatabase statement?

Reply | Quote

> Do you have the old path in a hard coded OpenRecordSet or OpenDatabase statement?

No, there are no modules at all in the database–just queries. (Well, I recently added a small module, but it doesn’t have anything like that–and the problem existed before then.) Even if there were that kind of code, to match the observed symptoms, it would have to be something that gets executed automatically when the db was opened–and I have nothing like that.

Reply | Quote

We had a similar problem in which on some workstations the user was prompted to enter a password for the machine on which the shortcut was created; your problem might have the same root cause which is that the UNC path is embedded in the .lnk shortcut file and instead of resolving to the local relative path as it appears when you look at shortcut properties it resolves to the UNC path. In our case we were using C:microsoft…msaccess.exe…. in front of the path to the mdb file. On some machines it read C: as the originating workstation’s network name thus causing the prompt for password. This led us to find the following Knowledge Base articles and related links. It has something to do with which version of shell32.dll the user has. I believe in one of the articles it mentions that you can open the .lnk file in Notepad and see the full embedded path.
http://support.microsoft.com/default.aspx?…b;en-us;Q150215 and http://support.microsoft.com/search/previe…b;en-us;Q158682

Reply | Quote

> your problem might have the same root cause which is that the UNC path is embedded
> in the .lnk shortcut file and instead of resolving to the local relative path as it appears
> when you look at shortcut properties it resolves to the UNC path.

Well, I did take some time to check this out, but as I suspected, it’s not the problem. Those articles are referring to a shortcut not finding the file (or finding the wrong one). Instead, my shortcut finds the right file–it’s just that Access gives a nonfatal error about not being able to find its (obsolete) startup path. Furthermore, as stated in the original post, I never remapped any drives, which was the root of the problem discussed in the articles.

Also I had long ago created a brand new shortcut from scratch to see if that would fix the problem, and it didn’t. That would have fixed any UNC situation that those articles are talking about.

I even tried running the shortcut.exe that the article talks about, and there was no change.

Your comments about the shell32.dll did catch my eye. First of all, I have a newer version of it (even newer than the version the article talks about that would fix the problem). But that got me to thinking, so I did some more experiments. I realized that the shortcut problem didn’t exist on my PC, which is Windows 95B. But the problem exists on Win 98 machines. I created brand new shortcuts on both machines, pointing to the same place of course. The Win 98 version is 4 bytes longer. They look almost, but not quite, identical when viewed in binary; and a binary compare confirms they differ in about 15 or 20 bytes (not any path information, but some binary stuff or other).

So I copied the Win 98 shortcut to the Win 95 machine, and vice versa. The Win 95 machine still never has a problem, and the Win 98 machine still always has a problem, no matter which shortcut is used. Oh, and I logged into the same username (mine) on both machines, to make sure the problem didn’t depend on network permissions.

So does that give anyone any clues?

Reply | Quote