Access 2000 /Jet/ BLOB/mdb file structure

[Richard Bonomo]

Could someone direct me to a reference which gives a byte-level description
of mdb files written by MS Access 2000, including whatever native internal
variables or pointers there are and their typical locations? Thank you.

Richard Bonomo
(e-mail address removed)_drop_caps

 

[Tony Toews [MVP]]

Could someone direct me to a reference which gives a byte-level description
of mdb files written by MS Access 2000, including whatever native internal
variables or pointers there are and their typical locations? Thank you.

Microsoft has not made this publicly available information.

MDB Tools is a set of open source libraries and utilities to
facilitate exporting data from MS Access databases (mdb files) without
using the Microsoft DLLs. Thus non Windows OSs can read the data. Or,
to put it another way, they are reverse engineering the layout of the
MDB file.

mdbtools.sourceforge.net Download the file and open the HACKING file.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Richard Bonomo]

Tony:
Thank you for the information. I was wondering why none of the MS documents
I had found simply outlined the layout of the files. I will follow up your
sourceforge lead.

My objective is quite modest: a database with which I work gets munged every
blue moon. It resembles the problem outlined in
http://support.microsoft.com/kb/304548. Recovery from this is quite
laborious, even though the data are untouched. As the problem affects ONLY
the execution of VB modules in the Access database, I suspect that an
internal variable which is supposed to point to another location in the file
has gotten munged. Indeed, what limited debugging can be done on the access
executable with VC++Express indicates that the program fails when it attempts
to access an RPC server (hence an error message which warns of a possible
network problem).

My hope is that I can track down the affected bytes, and simply and directly
fix them if this problem continues to recur in the future.

Thank you again for the information. If anyone else reading this has
additional information, please jump in.

Richard Bonomo
(e-mail address removed)_drop_caps

 

[David W. Fenton]

MDB Tools is a set of open source libraries and utilities to
facilitate exporting data from MS Access databases (mdb files)
without using the Microsoft DLLs. Thus non Windows OSs can read
the data. Or, to put it another way, they are reverse engineering
the layout of the MDB file.

Er, they aren't reading Access data, but Jet data.

 

[David W. Fenton]

=?Utf-8?B?UmljaGFyZCBCb25vbW8=?=

My objective is quite modest: a database with which I work gets
munged every blue moon. It resembles the problem outlined in
http://support.microsoft.com/kb/304548. Recovery from this is
quite laborious, even though the data are untouched.

Um, have you applied the fix outlined in that article? If not, do
you regularly compact your database? Do you regularly decompile? Do
you have multiple users opening it simultaneously? If the latter is
true, then that's the place to start, by stopping that bad practice.

 

[Tony Toews [MVP]]

My objective is quite modest: a database with which I work gets munged every
blue moon. It resembles the problem outlined in
http://support.microsoft.com/kb/304548.

David has a point. To my knowledge installing the A2000 SPs fixed
this problem.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Richard Bonomo]

Dear Tony, Dave, and others who may chime in:

I am not convinced that this is the same problem, primarily because the
computers do not appear to have the problematic version of vbe6.dll. I
began applying the service packs anyway in the hopes that this will prevent
future recurrence. We are also communicating with our Enterprise-level IT
folks to see if they will apply or will let us apply the pertinent service
packs to all Windows workstations in our group.

Regarding multiple users opening a file: doesn't a lock file prevent that?

We have used the recovery procedure which the article outlines (and probably
will
this time as well), but as this is quite laborious (there are several VB
scripts), and
as we really do not KNOW what is causing this, we would like to find a
quicker path to recovery in case this keeps happening. Hence my attempt to
determine which bytes are afffected and simply fix those. (The recovery
procedure is a bit like repainting the entire car anytime there is a scratch.)

Again, if anyone can point me toward this information, I would appreciate it.

Richard Bonomo
(e-mail address removed)_drop_caps

 

[Richard Bonomo]

Dear Dave,

I take it the JET database is only one component of the Access2000 mdb file,
no?

Rich

 

[David W. Fenton]

=?Utf-8?B?UmljaGFyZCBCb25vbW8=?=

I take it the JET database is only one component of the Access2000
mdb file, no?

An MDB is a Jet data store. The properties of the Access objects are
stored in Jet data tables. But Jet itself knows nothing of the
meaning of what is stored in its tables -- a record with a form
definition in it is no more meaningful to Jet than a record with a
person's name and address. It's all data to Jet. It's only when the
MDB is opened by Access that the form definitions take on meaning as
Access objects.

The open-source project to build tools to read MDBs without Jet
installed is only accessing the Jet data. It will not run an Access
application.

The distinction between Access and Jet is crucial, and Microsoft
seems to bend over backwards to obfuscate this distinction. But they
shouldn't, and neither should users of Access and/or Jet.

 

[Richard Bonomo]

Dear Dave,

OK, so the mdb file IS a Jet data store, and one is not a subset of the other.
I comprehend the distinction between reading MDBs and running the embedded
applications. That is fine, as I only need to figure out what set of bytes
is having
Access jump to the wrong location when someone clicks a form button.

I did look at the sourceforge page that Tony directed me to. The program
itself
is not immediately useful as I do not currently have access to a POSIX system
at work. However, the "HACKING" file is simply a text file which has useful
information (probably not enough for my purpose, but it is quite useful).

Richard Bonomo
(e-mail address removed)_no_caps_(608)2678647

 

[David W. Fenton]

=?Utf-8?B?UmljaGFyZCBCb25vbW8=?=

Dear Dave,

[why do you call me "Dave" when I've never signed my name as
anything other than "David"?]

OK, so the mdb file IS a Jet data store, and one is not a subset
of the other. I comprehend the distinction between reading MDBs
and running the embedded applications. That is fine, as I only
need to figure out what set of bytes is having
Access jump to the wrong location when someone clicks a form
button.

Well, I don't know what you mean there. I think you're crazy to want
to do this at the binary level in the raw file, instead of using
proper interfaces to the data format.

I did look at the sourceforge page that Tony directed me to. The
program itself
is not immediately useful as I do not currently have access to a
POSIX system at work. However, the "HACKING" file is simply a
text file which has useful information (probably not enough for my
purpose, but it is quite useful).

Windows NT from its original versions including a POSIX
compatibility layer.

There's not much point in using the SourceForge project if you're
running Windows, as if you're running Windows you already have
native Microsoft interfaces to Jet data.

Frankly, I haven't a clue what you're trying to do. You sound to me
like you're making the whole thing way too complicated.

 

[Richard Bonomo]

=?Utf-8?B?UmljaGFyZCBCb25vbW8=?=

Dear Dave,

[why do you call me "Dave" when I've never signed my name as
anything other than "David"?]

Dear David,

Just a habit. Almost all the Davids I know go by "Dave" in conversation,
even if they sign their names "David." David it shall be.

Well, I don't know what you mean there. I think you're crazy to want
to do this at the binary level in the raw file, instead of using
proper interfaces to the data format.

I'll try to explain: Someone here produced an Access database which has forms
which contain buttons. The "button" when selected activate VB code which then
do things such as run SQL queries. (All this being quite common, I realize.)

Some mysterious happenstance occasionally mungs a couple (?) of bytes in the
mdb file such that a communications error is produced whenever someone
attempts to use these form buttons which have VB behind them. This has
happened before. The database is intact, and the SQL queries work just fine
if executed directly.

We do not know why this is happening. Although it bears a resemblance to
the problem in the referenced database article, we are not sure that it is.
Until we can track down the cause of this problem (the software and/or
particular workstation(s) responsible, and fix it, this could happen
repetitively.

The recovery procedure outlined in the article is lengthy. A great deal of
time could be wasted by having people have to do this every so often, at
random times, for an unknown stretch of time.

Given that the only thing affected by this is the execution of the VB behind
the buttons, and given the nature of the error. it seems PROBABLE to me that
the file error is a matter of certain bytes -- that either connect the VB
script to the button, or, more likely, that tell the VB script where other
database components are -- being altered to point to the wrong location or to
designate the wrong type of connection between the VB and the database.

IF that is true, then I should be able to write a simple bit of software (or
use a binary editor) to put the pointer bytes back to their correct value.
(I've done things like that before on a number of occasions.) Once
identified, then the process of fixing the database could take only minutes
or seconds instead of the better part of an hour. If it takes us a while to
track down and fix the cause of the original problem, we could be faced
with this database error several times, and having a procedure to make the
correction directly could save much time and frustration.

SO, that is why I am on the hunt to see if I can locate the pertinent bytes,
if
things work as I suspect.

I am hoping that some kind soul who knows how to identify them (they must be
documented somewhere -- even if only within the MS developer offices -- if
they exist) will fill me in.

Of course, I have no way of knowing, apriori, if the picture I have in my
head of how this works (i.e. that there is some pointer or internal variable
which tells VB where to find the other database components) is, in fact,
correct.

Thank you for your continuing attention. I appreciate your attempt to help
very much.

Rich

 

[David W. Fenton]

=?Utf-8?B?UmljaGFyZCBCb25vbW8=?=

=?Utf-8?B?UmljaGFyZCBCb25vbW8=?=

Dear Dave,

[why do you call me "Dave" when I've never signed my name as
anything other than "David"?]

Just a habit. Almost all the Davids I know go by "Dave" in
conversation, even if they sign their names "David." David it
shall be.

Thanks.

But I'd adivse you to pay attention to how people refer to
themselves. If I signed myself "Dave," then of course it would be
fine for you to call me that. I've complained about this several
times (I'm terribly ungracious and impolite , and others with
names that are commonly abbreviated have chimed in with "yes, I hate
that, too!" Most people are too polite to mention it, so people
blithely go along assuming over-familiarity in people's names.

I'm *very* impolite (as anyone who's read the Access newsgroups
would know), so I say something. Most people don't realize it's
perceived by some as a slight, and are horrified that they've
perhaps been unintentionally offending others in what they thought
of as an act of friendliness. That's why I mention it, because I
assume no one would want to do that on purpose, so they don't
realize it's a potential offense.

I'll try to explain: Someone here produced an Access database
which has forms which contain buttons. The "button" when selected
activate VB code which then do things such as run SQL queries.
(All this being quite common, I realize.)

Some mysterious happenstance occasionally mungs a couple (?) of
bytes in the mdb file such that a communications error is produced
whenever someone attempts to use these form buttons which have VB
behind them.

What kind of error message do you get reporting this?

Have you gone through this thoroughly:

http://www.granite.ab.ca/access/corruptmdbs.htm

You sound like you're having garden-variety corruption issues, and
the answer to that is not reading the binary file format, but simply
fixing whatever it is that's leading to the corruption in the first
place.

This has
happened before. The database is intact, and the SQL queries work
just fine if executed directly.

We do not know why this is happening. Although it bears a
resemblance to the problem in the referenced database article, we
are not sure that it is. Until we can track down the cause of
this problem (the software and/or particular workstation(s)
responsible, and fix it, this could happen repetitively.

You must track it down and fix it. There's really no other way to
address it.

The recovery procedure outlined in the article is lengthy. A
great deal of time could be wasted by having people have to do
this every so often, at random times, for an unknown stretch of
time.

Find what's causing the problem and remove that cause.

Given that the only thing affected by this is the execution of the
VB behind the buttons, and given the nature of the error. it seems
PROBABLE to me that the file error is a matter of certain bytes --
that either connect the VB script to the button, or, more likely,
that tell the VB script where other database components are --
being altered to point to the wrong location or to designate the
wrong type of connection between the VB and the database.

Corruption is corruption. Just for instance, are multiple people
opening the same MDB to run the code that is corrupting? If so,
that's the likely source of the problem. Give each user a copy of
the MDB and you'll likely see no more corruption.

IF that is true, then I should be able to write a simple bit of
software (or use a binary editor) to put the pointer bytes back to
their correct value.

No, you won't be able to do any such thing. It would be easier to
keep a reference copy of the MDB and just copy over top of the
corrupted one, if you choose to ignore the actual *cause* of the
corruption.

(I've done things like that before on a number of occasions.)

It's completely senseless in the present instance.

Once
identified, then the process of fixing the database could take
only minutes or seconds instead of the better part of an hour.

Why not simply remove the problem, instead of spending time on
writing a fix for it?

If it takes us a while to
track down and fix the cause of the original problem, we could
be faced with this database error several times, and having a
procedure to make the correction directly could save much time and
frustration.

You're assuming many things:

1. the state of the MDB is always identical

2. the place the corruption occurs is always exactly the same.

These are ridiculous assumptions, in my opinion.

SO, that is why I am on the hunt to see if I can locate the
pertinent bytes, if
things work as I suspect.

I don't think things work as you suspect.

I am hoping that some kind soul who knows how to identify them
(they must be documented somewhere -- even if only within the MS
developer offices -- if they exist) will fill me in.

They won't. MS employees can't release the information and people
outside of MS often have NDAs that prohibit public revelation of
what they know.

Of course, I have no way of knowing, apriori, if the picture I
have in my head of how this works (i.e. that there is some pointer
or internal variable which tells VB where to find the other
database components) is, in fact, correct.

Work through Tony's corruption FAQ. If you follow the
recommendations there, you're likely to remove the problem and not
need to write a workaround for it.

 

[Richard Bonomo]

Dear David (and anyone else who cares to chime in),

What kind of error message do you get reporting this?

"Error accessing file. Network connection may have been lost."
(This is with a file on the local HD.)

There is a KB article which speaks of this, and it is referenced on the web
site
you give below as well. However, I do not think we have the version of
vbe6.dll
that the article references, nor does it seem that anyone (so far) has done
the
things associated with causing this particular error. The symptoms are the
same, but the cause may be different.

Have you gone through this thoroughly:

http://www.granite.ab.ca/access/corruptmdbs.htm

Doing so now.

You sound like you're having garden-variety corruption issues, and
the answer to that is not reading the binary file format, but simply
fixing whatever it is that's leading to the corruption in the first
place.



You must track it down and fix it. There's really no other way to
address it.


Find what's causing the problem and remove that cause.

Well, I started that process before pursuing this. The sad fact is that
removing the cause is not entirely in our control. I, for example, indicated
that we should make sure that all of our workstations has Office SP-3
installed,
among other things. We've notified our central IT folks of this and we are
waiting
on them. It is not clear when they will get around to this or when they
will give their blessing to our doing it ourselves.

It is easy to say "find and fix the cause," (and it is what must be done of
course),
but that does not magically put me/us in a position to do so, at least not in
a timely fashion.

It's completely senseless in the present instance.


Why not simply remove the problem, instead of spending time on
writing a fix for it?

see above.

You're assuming many things:

1. the state of the MDB is always identical

2. the place the corruption occurs is always exactly the same.

These are ridiculous assumptions, in my opinion.

I am assuming that the bytes in question -- if they exist -- are somehow
findable. They must be, as people obviously write software which uses them
or the equivalent.

I AM assuming, for the moment, that the corruption is the same for this
particular
problem. It may be true, it may be false. It should be testable.

I don't think things work as you suspect.

That may well be. I am sure that my ignorance of the internal structure of
MS Access / Jet 4 databases leads to a certain naivete. Things may well
work in a way which has no resemblance to what I suspect. I am aware
of that possibility (or probability).

They won't. MS employees can't release the information and people
outside of MS often have NDAs that prohibit public revelation of
what they know.

Perhaps not. I do not know the extend of confidentiality with the proprietary
formats. I know that no-one can provide me a complete description without
my signing an NDA (which I'd be willing to do). (I have also had other
vendors
provide me with proprietary information on request to solve problems at other
times.) However, it is not obvious to me that MS or even a 3rd party could
not
reveal to me that "the path-defining variable you seek is typically located on
Access page of type X, buried somewhere in a record type of Y, preceded by
bytes xx xx xx." The only way to know for sure is to ask.

Work through Tony's corruption FAQ. If you follow the
recommendations there, you're likely to remove the problem and not
need to write a workaround for it.

Eventually. As I noted, though, this is not under my/our control.

Rich

 

[James A. Fortune]

Tony:
Thank you for the information. I was wondering why none of the MS documents
I had found simply outlined the layout of the files. I will follow up your
sourceforge lead.

My objective is quite modest: a database with which I work gets munged every
blue moon. It resembles the problem outlined in
http://support.microsoft.com/kb/304548. Recovery from this is quite
laborious, even though the data are untouched. As the problem affects ONLY
the execution of VB modules in the Access database, I suspect that an
internal variable which is supposed to point to another location in the file
has gotten munged. Indeed, what limited debugging can be done on the access
executable with VC++Express indicates that the program fails when it attempts
to access an RPC server (hence an error message which warns of a possible
network problem).

My hope is that I can track down the affected bytes, and simply and directly
fix them if this problem continues to recur in the future.

Thank you again for the information. If anyone else reading this has
additional information, please jump in.

Richard Bonomo
(e-mail address removed)_drop_caps

Can you use two copies of the database and have one attempt to access
the RPC server without changing any data? Then repeat the process
(including copying the database) until the once in a blue moon error
recurs so you can compare the bytes to detect possible suspects? If you
find such a spot you can back up the pointer value (or whatever) and use
those byte values to attempt to restore the database.

James A. Fortune
(e-mail address removed)

Main Entry: blue moon
Function: noun
Date: 1821
1 : a very long period of time —usually used in the phrase once in a
blue moon<such people happen along only once in a blue moon— Saturday
Review>
2 : a second full moon in a calendar month
-- http://www.m-w.com/dictionary/blue moon

 

[Richard Bonomo]

Dear James,

I have given thought to doing something like that to locate the bytes in
question.
David Fenton (see below) is of the strong opinion that the approach I am
taking
is doomed to failure for a variety of reasons. I do not know what he does
or does
not know about the detailed structure of these things. He is not an MS
employee,
but he does do consulting on Access matters professionally, and apparently
has exquisite taste in music .

I am at a bit of an impasse. It seems that if I really want to examine the
approach, I need to find someone in MS who would be willing to arrange for me
to sign a non-disclosure agreement so I can examine the detailed
specifications and then conclude it is hopeless on my own. )

Any MS-executives out there reading this post??

Rich

 

[David W. Fenton]

=?Utf-8?B?UmljaGFyZCBCb25vbW8=?=

"Error accessing file. Network connection may have been lost."
(This is with a file on the local HD.)

Then that's very clearly the vbe6.dll corruption issue and can be
fixed by following the instructions in this KB article:

http://support.microsoft.com/kb/304548

You, in fact, supplied that URL in an earlier post, and that's the
cause of this problem. It was fixed in the first Office 2000 service
pack. If you can't apply SP3

There is a KB article which speaks of this, and it is referenced
on the web site
you give below as well. However, I do not think we have the
version of vbe6.dll
that the article references, nor does it seem that anyone (so
far) has done the
things associated with causing this particular error. The
symptoms are the same, but the cause may be different.

What versions of Access do you have?

I've never seen this error in any case but where things were as
described in that article.

And this kind of corruption will absolutely *not* be fixable by
poking into the MDB file structure, as this corruption concerns the
Access project, which is an internal structure stored in a BLOB
field of a system table. It's structure is going to be completely
different depending on your Access project.

By chance does is the database set to COMPACT ON CLOSE? If so, TURN
THAT OFF. It's a useless setting that is very dangerous (since it's
not cancellable).

Quick recovery from the problem until you solve it would be as
simple as keeping a reference copy of the MDB and copying it over
top of the corrupted one. You could also do Application.SaveAsText
(as described in the KB article) and re-import into a new MDB to
replace the corrupted one.

[]

Well, I started that process before pursuing this. The sad fact
is that removing the cause is not entirely in our control. I, for
example, indicated that we should make sure that all of our
workstations has Office SP-3 installed,
among other things. We've notified our central IT folks of this
and we are waiting
on them. It is not clear when they will get around to this or
when they will give their blessing to our doing it ourselves.

Have the app check on open if it's the correct version of Access and
close if it's not.

It is easy to say "find and fix the cause," (and it is what must
be done of course),
but that does not magically put me/us in a position to do so, at
least not in a timely fashion.

You're not going to solve this problem by the method you're
pursuing. It's only going to be solved by fixing the problem. If
your IT department can't get properly patched versions of software
on your desktops, then you need to talk to your direct supervisor to
go up the chain of command to get somebody to force IT to start
doing their jobs.

[]

I am assuming that the bytes in question -- if they exist -- are
somehow findable. They must be, as people obviously write
software which uses them or the equivalent.

The error message you're getting is Access telling you that it can't
read them any more. That means that the pointers are so corrupted
that it's not fixable. So, you're absolutely *not* going to be able
to fix this manually.

I AM assuming, for the moment, that the corruption is the same for
this particular
problem. It may be true, it may be false. It should be testable.

I have concluded that you're absolutely wasting your time.

It's too bad Peter Miller doesn't read these newsgroups any more, as
he is the primary expert on the Jet file format outside of
Microsoft. He'd probably be able to explain definitively why your
approach will never work.

That may well be. I am sure that my ignorance of the internal
structure of MS Access / Jet 4 databases leads to a certain
naivete. Things may well work in a way which has no resemblance
to what I suspect. I am aware of that possibility (or
probability).

What you need is not the structure of Jet, but the structure of
Access structures. And those are stored in a BLOB field in a system
table, whose structure is completely unknown to Jet.

Perhaps not. I do not know the extend of confidentiality with the
proprietary formats. I know that no-one can provide me a complete
description without my signing an NDA (which I'd be willing to
do). (I have also had other vendors
provide me with proprietary information on request to solve
problems at other times.) However, it is not obvious to me that
MS or even a 3rd party could not
reveal to me that "the path-defining variable you seek is
typically located on Access page of type X, buried somewhere in a
record type of Y, preceded by bytes xx xx xx." The only way to
know for sure is to ask.

The answer is going to be that there *isn't* any such set of bytes,
as if there were, the databases corrupted in this fashion would be
easily recoverable. The KB article explains that the VBA projects
are lost as soon as you encounter this error, so that means there
isn't any set of bytes that is resettable to recover the VBA
project.

Eventually. As I noted, though, this is not under my/our control.

Until your company's management can whip the IT department into
shape, this is what I'd do:

1. implement tracking of user logons and logouts into the MDB, and
their version of Access and Jet. This way, you can tell who is
corrupting the database, and visit their workstation yourself to
upgrade them to a safe version of Access.

2. in your app, check the Access version and if it's not SR1 or
later, tell the user their Access installation needs to be patched
and kick them out of the database.

3. give a copy of the MDB to each user, and never have more than one
user in the MDB at a time.

4. if the user's copy gets corrupted, just copy a fresh one over top
of the corrupted MDB.

You could really control this by changing the structure to open a
"launcher" MDB that would do all the checking for you and only then
launch the actual app. This would be something like:

A. check the version of Access. If not SR1 or greater, inform the
user and exit.

B. if the A. test is passed, check to see if there's an unlogged-out
entry for the app for the current user. This would tend to indicate
a corruption. If there is, download a new copy of the front end. If
not, go to C.

C. launch the app.

This would give you complete control. If you make the launcher an
MDE, it should be pretty safe. In fact, an MDE may protect you from
the original problem, as I think it involves the code project, not
the compiled code.

 

[David W. Fenton]

=?Utf-8?B?UmljaGFyZCBCb25vbW8=?=

David Fenton (see below) is of the strong opinion that the
approach I am taking
is doomed to failure for a variety of reasons. I do not know what
he does or does
not know about the detailed structure of these things.

I don't know the detailed structure, but I don't *need* to know it.

The error message you're getting quite clearly implicates the
VBE6.DLL corruption problem, and is avoided quite simply by using
Access 2000 SR1 or later -- that is a *very* simple fix, much
simpler than if it's caused by flaky network infrastructure or
software interactions on the server.

Secondly, the error involves the Access project. That is a structure
stored in a BLOB field in a system table. While the system table and
the BLOB field are Jet structures, the contents of that BLOB field
are basically unknown to Jet -- it's just data to Jet. To fix it
you'd have to know the internal structure of the Access project in
the BLOB field.

Third, Microsoft *knows* the structure of that BLOB. But they cannot
provide a fix for this corruption once it happens. That means it's
not a simple matter of flipping a couple of bytes, because if it
were, MS would be able to provide a fix for it.

Fourth, it's likely that the structure of that BLOB is too variable
for there to be any byte-flipping fix (assuming MS is just too lazy
to figure it out), since it's storing information about your MDB's
particular VBA project.

I don't need to know the internal structures to reason this out --
all I need to know is the nature of the corruption, which very
clearly points to the VBE6.DLL corruption, which is not and never
was recoverable. That lack of recoverability strongly implies that
there is no quick fix, and there are good logical reasons why that
is the case (primarily because the corruption occurs in structures
that are likely unique to each VBA project).

I also don't see why it's even an issue. It's a non-data-bearing
MDB, right? It should be, as the app should be split into front end
and back end. Thus, the corrupt front end is completely fungible,
and if it's lost, you just copy a fresh one over top of the
corrupted one.

One other suggestion:

It may be that the VBE6.DLL corruption cannot happen to an MDE,
which doesn't have the code (only the compiled p-code). So, making
an MDE might be an easy solution that won't force you to fix the
underlying problem.

 

[James A. Fortune]

Dear James,

I have given thought to doing something like that to locate the bytes in
question.
David Fenton (see below) is of the strong opinion that the approach I am
taking
is doomed to failure for a variety of reasons. I do not know what he does
or does
not know about the detailed structure of these things. He is not an MS
employee,
but he does do consulting on Access matters professionally, and apparently
has exquisite taste in music .

I am at a bit of an impasse. It seems that if I really want to examine the
approach, I need to find someone in MS who would be willing to arrange for me
to sign a non-disclosure agreement so I can examine the detailed
specifications and then conclude it is hopeless on my own. )

Any MS-executives out there reading this post??

Rich

David stated that he does not know the internal structure. He is
sometimes wrong and his considerable forensic skills cause him to win
debates that would be better for everyone, IMO, if he lost. I would not
dismiss the idea without trying it based on his speculation alone. If
he has a reason for his belief based on the reverse engineered file
structure at sourceforge then that's another matter worth consideration.
I recognize that speculation can be valuable at times. His assertion
seems to be that the only ways this has been dealt with in the past are
the easiest ways. I can't say that I disagree with that sentiment, but
such ways can cause stagnation and an unintended suppression of
knowledge. If you said, "I tried that and there were multiple places
where the binary differed." or "The place in the binary changed from one
occurrence to the next." then that would corroborate David's theory. It
is the consensus of the posters here that if a later Service Pack solves
a problem, then that is the best advice to give. But that is not always
possible. Also, his advice to find and solve what is causing the
corruption is the best advice (an ounce of prevention). You
specifically asked for a way to track down the affected bytes and that
the corruption seems to follow the same pattern each time. That's what
I tried to give you in a way that doesn't require you to know much about
the internal structure of the file. Frankly, I found your idea much
more refreshing than "If there's an inconsistency, nuke the whole front
end and start over until the next error since we can't use the right
Service Pack."

James A. Fortune
(e-mail address removed)

 

[James A. Fortune]

Then that's very clearly the vbe6.dll corruption issue and can be
fixed by following the instructions in this KB article:

http://support.microsoft.com/kb/304548

You, in fact, supplied that URL in an earlier post, and that's the
cause of this problem. It was fixed in the first Office 2000 service
pack. If you can't apply SP3

That problem was also present in A97. A decompile might fix it. If
not, the OP should try SaveAsText as you recommended or import the form
without any code first. If the pasted code doesn't reattach to the
events, try creating the event code subroutines and pasting in each
subroutine. Any functions should be fine. I've had situations come up
where a single user needed to use an older version of the database, but
needed an update of a particular form to fix a problem. Sometimes
simply importing the form from the new database caused the same kind of
corruption.

James A. Fortune
(e-mail address removed)