I was searching for an answer to a very similar question of my own, and this
seemed to me to be the most relevant thread in which to ask it.
During the course of writing my question, I actually came up with a
completely separate work-around which I can suggest but which still leaves me
with other questions.
Let me start with a bit of exposition —
I, too, have an ".mdb" file I _had_ been unable to open via Access:
* My database is file is currently stored on a local hard-drive.
* My database contains a variety of table-links of various styles which
references machines which are invisible to this machine (i.e., machines at my
office's intranet — I'm at home working on my code base over the weekend).
* I had "un-blocked" this database, and that alone had not permitted me to
open the file.
* I am using Microsoft Access 2002.
Now, here are two additional I tried which were _also_ immediately refused
by Access:
* I attempted to open the database file in safe-mode (held down the
shift-key while opening the database) to suppress any AutoExec macro or
startup-option specified Form (it had both).
* I created a "clean" (File>New>Blank) database and attempted the command
"File>Get External Data>Import" in order to _indirectly_ access the database.
(I had hoped to move unaffected objects — specifically, several VBA modules
— into the blank database.)
Now, something that _did_ work. I tried this as I was composing the
original version of this message simply for the sake of thoroughness. I
created the following VBA procedure within another database:
Public Sub RemoveAllLinksInExternalDatabase(s_FilePath As String)
Dim db As DAO.Database, tdf As DAO.TableDef
Set db = DBEngine.OpenDatabase(s_FilePath)
For Each tdf In db.TableDefs
If tdf.Connect <> "" Then db.TableDefs.Delete tdf.Name
Next tdf
End Sub
I then, in the immedate-mode pane, fed that procedure the path to hte
offending file, which rendered it _usable_.
I have two suggestions:
(1) Forward the above code to the fine folks who administer and edit the
MSKB. I searched there first in an attempt to find a solution and every
article's list of work-arounds suggested one form or another of punching
holes in my security settings — the most radical of which involved taking
down a component of IE's revised security model. This, by comparison, only
affects the file that is in quesiton without affecting the entire OS. (And
if I cared about those file links, I could'a made a backup of the file before
I deleted 'em. All I was after was my code modules!)
(2) Access seems to be hyper-corrective in responding to this "potential
vulnerability". I'll take it as a forgone conclusion that it could, at some
point, constitute a threat of some kind. I'm assuming from both Access's
responses and the timing of those responses that while it is validating the
integrity of the file prior to opening it (for direct AND indirect use) it
reads the connection-strings of any linked tables that are described. Then,
as it inspects the connection string it does a security-check on the machine
the connection specifies. Most unfortunately, rather than simply refusing to
follow the connection (as it ought, given our assumption about the potential
vulerability), the file-validation procedure takes the returned exception and
misconstrues it as an exception applicable to the file as a whole rather than
links within the file.
Since there are _multiple_ points later on during which Access has a chance
to refuse to follow the external connection _after_ the file has been opened,
I say this response is _hyper-corrective_ on its part, and incorrect
behavior. Incorrect in that: (a) first of all, it refuses legitimate access
to a local file and (b) to add further aggravation, it generates an error
message which is factually incorrect when it states the file is outside the
local machine.
My second suggestion would be to resolve this inconsistency.
Anyhow, my two-bits. I know I'm being a bit picky since I _did_ manage to
get into my file. Just prioritize my suggestion(s) amongst the pile of 'em
from everyone as you best think it fits.
--Tal Loos / a.k.a. "random9q"
