Access 2000 /Jet/ BLOB/mdb file structure

[David W. Fenton]

That problem was also present in A97.

I don't know that I ever encountered in A97. I only encountered the
version caused by VBE6.DLL, which wasn't relevant in A97, since the
VBE was introduced into Access only with A2K. And, of course, you
couldn't corrupt the VBA project as a whole in A97 because the
monolithic save model was not introduced until A2K.

A decompile might fix it.

The one time I encountered this, there was no recovery at all. That
the KB article above does not recommend a decompile suggests to me
that there was no known recovery possi8ble.

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.

All due respect, but I think you're wrong. This error did not occur
before A2K, and when it does, it's completely unrecoverable -- the
MDB it happens in is completely unable to be recovered in any form.
I tried. And MS doesn't provide any recovery instructions (only
using backups), so that seems pretty definitive to me.

 

[James A. Fortune]

The one time I encountered this, there was no recovery at all. That
the KB article above does not recommend a decompile suggests to me
that there was no known recovery possi8ble.




All due respect, but I think you're wrong. This error did not occur
before A2K, and when it does, it's completely unrecoverable -- the
MDB it happens in is completely unable to be recovered in any form.
I tried. And MS doesn't provide any recovery instructions (only
using backups), so that seems pretty definitive to me.

Let me explain. It might not have been the VBE6.DLL bug, but the
symptoms were the same. Once the form was imported into the database it
hosed the form, possibly the database, without remedy just like the
VBE6.DLL bug does. I don't remember all the details. I found a KB
article that explained it back when it happened but I can't find it
again. But I remember for certain that there was a bug in A97 that was
caused by importing a form from another A97 database under certain
conditions. I remember that from then on I was more careful with that
database where forms were concerned.

James A. Fortune
(e-mail address removed)

 

[David W. Fenton]

Let me explain. It might not have been the VBE6.DLL bug, but the
symptoms were the same. Once the form was imported into the
database it hosed the form, possibly the database, without remedy
just like the VBE6.DLL bug does.

It can't *possibly* have caused the same problem as the VBE6.DLL
bug, because in A97 there is no monolithic VBA project to hose, as
there is in A2K and later.

Sure, forms could become corrupted, one at a time.

Sure, forms could be corrupted by corrupted standalone modules when
the form used functions/subs in the corrupted modules.

But this is simply not at all the same problem, and it didn't
generate the same "network" error message.

I don't remember all the details. I found a KB
article that explained it back when it happened but I can't find
it again. But I remember for certain that there was a bug in A97
that was caused by importing a form from another A97 database
under certain conditions. I remember that from then on I was more
careful with that database where forms were concerned.

I don't believe it can possibly have been the same bug, and the fix
you supplied for it simply doesn't apply when you encounter the
VBE6.DLL bug.

 

[James A. Fortune]

It can't *possibly* have caused the same problem as the VBE6.DLL
bug, because in A97 there is no monolithic VBA project to hose, as
there is in A2K and later.

Sure, forms could become corrupted, one at a time.

Sure, forms could be corrupted by corrupted standalone modules when
the form used functions/subs in the corrupted modules.

But this is simply not at all the same problem, and it didn't
generate the same "network" error message.




I don't believe it can possibly have been the same bug, and the fix
you supplied for it simply doesn't apply when you encounter the
VBE6.DLL bug.

David,

I looked again and still can't find the KB article to which I was
referring. The error message may have been the same. It seems useless
to speculate on whether the errors are related or not, or even what the
message was without it. I don't remember if a decompile fixed the
problem, but maybe a decompile was used after form code was pasted.
Your argument that it can't be the same bug seems valid, but I couldn't
help but notice the resemblance to what I experienced in A97.

James A. Fortune
(e-mail address removed)

 

[David W. Fenton]

I looked again and still can't find the KB article to which I was
referring. The error message may have been the same. It seems
useless to speculate on whether the errors are related or not, or
even what the message was without it. I don't remember if a
decompile fixed the problem, but maybe a decompile was used after
form code was pasted. Your argument that it can't be the same bug
seems valid, but I couldn't help but notice the resemblance to
what I experienced in A97.

Fair enough. I have never had much in the way of corruption in A97
because I decompile so frequently, so I'd likely never have
encountered the error in the first place. But the VBE6.DLL error is
one that best practices won't prevent you from encountering, and
I've had it happen to me, on a machine with a new installation of
A2K that somehow I hadn't patched to SR1.

 

[Richard Bonomo]

Dear David, James, and whoever else chimes in:

First, to clarify: the database in question has data, forms, queries, etc.,
all
wrapped up in one. It doesn't look like this will be split any time soon, if
ever. The corruption affects ONLY the execution of the VB. The data apppear
to be intact, and sql queries work OK.

Thank you for your suggestions. I passed David's suggestions on how to
proceed in the absence of upgrades to the database manager. I think a
tracking
system is most likely to be implemented.

I suggested that we employ something like RCS to have people check copies
of the database in and out, but there is severe doubt that would work in our
particular environment.

Some good we got the go-ahead from central IT to do the upgrade
on our systems. MAYBE this might prevent a recurrence. We have not yet
found a system that has the troublesome version of vbe6.dll.

Well, unless someone has something new to add, I will consider this thread
closed. Thank you for chiming in and providing insight and advice!

If an MS employees who have intimate knowledge of the Access BLOB structure,
etc., etc., happen to read these posts, I'd love to hear what you/they have
to say,
either via this discussion group, or off-line.

Rich
work: (e-mail address removed)_drop_caps until -- when?
home: (e-mail address removed)_drop_caps_here_too
work phone: (608) 267-8647

 

[David W. Fenton]

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

First, to clarify: the database in question has data, forms,
queries, etc., all
wrapped up in one. It doesn't look like this will be split any
time soon, if ever.

Then that makes it very, very difficult to solve the problem easily
without patching the Access installations.

The corruption affects ONLY the execution of the VB. The data
apppear
to be intact, and sql queries work OK.

Yes, of course they are, because that's JET data, not part of the
VBA project. If your app were split (as it should be, as every
Access app should be), then you wouldn't have to do anything to
recover from the corruption except replace the corrupted front end.

Thank you for your suggestions. I passed David's suggestions on
how to proceed in the absence of upgrades to the database manager.
I think a tracking
system is most likely to be implemented.

But that only helps in diagnosing who is causing the problem -- you
still have to *solve* the problem.

I suggested that we employ something like RCS to have people check
copies of the database in and out, but there is severe doubt that
would work in our particular environment.

No, no, no, no. You're making things IMPOSSIBLY complicated. The app
*must* be split. This is not optional, it's the only way any
multi-user Access application should ever be deployed.

Some good we got the go-ahead from central IT to do the
upgrade on our systems. MAYBE this might prevent a recurrence.
We have not yet found a system that has the troublesome version of
vbe6.dll.

Then you may have corruption problems after the upgrade because
you're running a shared unsplit MDB. That is BAD, BAD, BAD, BAD.

Well, unless someone has something new to add, I will consider
this thread closed. Thank you for chiming in and providing
insight and advice!

I don't understand why you, who admit to not being an Access expert,
seem determined to completely ignore the advice of those of us who
have experience with Access.

If an MS employees who have intimate knowledge of the Access BLOB
structure, etc., etc., happen to read these posts, I'd love to
hear what you/they have to say,
either via this discussion group, or off-line.

Did you actually read what I wrote on the subject or are you just a
complete idiot?

 

[Richard Bonomo]

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


Then that makes it very, very difficult to solve the problem easily
without patching the Access installations.


Yes, of course they are, because that's JET data, not part of the
VBA project. If your app were split (as it should be, as every
Access app should be), then you wouldn't have to do anything to
recover from the corruption except replace the corrupted front end.


But that only helps in diagnosing who is causing the problem -- you
still have to *solve* the problem.


No, no, no, no. You're making things IMPOSSIBLY complicated. The app
*must* be split. This is not optional, it's the only way any
multi-user Access application should ever be deployed.


Then you may have corruption problems after the upgrade because
you're running a shared unsplit MDB. That is BAD, BAD, BAD, BAD.


I don't understand why you, who admit to not being an Access expert,
seem determined to completely ignore the advice of those of us who
have experience with Access.


Did you actually read what I wrote on the subject or are you just a
complete idiot?

Dear David,

If it were up to me alone, I would probably take ALL your suggestions, at
least
in so far as they can be applied here.

I was asked to look into finding alternate ways of solving a particular
problem.
You've indicated that the approach I was taking is doomed to failure, and you
have made alternate suggestions. I've passed these (including splitting the
database -- which makes complete sense to me) up to the folks who
run things, which is all I can do. I am not the manager of the database in
question. If I were, I probably would not be using Access, or any other
closed-
format system.

I suggested RCS (or equivalent) as a way to allow people to operate on their
own copy of the database (a suggestion you made) while still allowing people
to modify the master, track changes, and determine when and how corruption
occurs. (I doubt this will happen.)

So, don't despair or get too disgusted. Sooner or later your advice will be
taken by those who decide these things (and who know much more about Access
than
I do, but probably a whole less than you do).

Rich B.

 

[David W. Fenton]

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

So, don't despair or get too disgusted. Sooner or later your
advice will be taken by those who decide these things (and who
know much more about Access than
I do, but probably a whole less than you do).

Send them this thread.

 

[Tony Toews [MVP]]

I've passed these (including splitting the
database -- which makes complete sense to me) up to the folks who
run things, which is all I can do. I am not the manager of the database in
question.

Splitting is the first and most important step to solving the
corruption problems. This should be a no brainer on the part of the
folks administering the application. But, as you point out, you're
not the owner of the app.

If I were, I probably would not be using Access, or any other
closed-format system.

I'm not aware of any open format systems that have 1% of the
functionality of Access. Sure there's MySQL but that's about it.

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/

 

[David W. Fenton]

I'm not aware of any open format systems that have 1% of the
functionality of Access. Sure there's MySQL but that's about it.

And that doesn't come close to being a development system. PHP +
MySQL is usable, but much, much more work than Access + any database
engine.

 

[Tony Toews [MVP]]

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??

Doubtful. The folks who make those kinds of decisions are way above
the pay grade of those who read the newsgroups.

There is some kind of system where academia, large corp customers,
governments and some MVPs
http://www.eweek.com/article2/0,1759,1624877,00.as have NDA access to
the Windows Source code. Or visit
http://www.microsoft.com/resources/sharedsource/default.mspx

There might be a similar program for Office source code. I have no
idea.

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/

 

[David W. Fenton]

Doubtful. The folks who make those kinds of decisions are way
above the pay grade of those who read the newsgroups.

There is some kind of system where academia, large corp customers,
governments and some MVPs
http://www.eweek.com/article2/0,1759,1624877,00.as have NDA access
to the Windows Source code. Or visit
http://www.microsoft.com/resources/sharedsource/default.mspx

There might be a similar program for Office source code. I have
no idea.

But the error encountered is not in any code that Microsoft creates.
It's in the code you create for your app, and, thus, there's no
predicting what the structure will be.

Trying to figure out the internal structure of the Access project
BLOB is a waste of time when the fix for this problem is so
incredibly simple -- split the app and replace the front end with a
fresh copy if it corrupts. And fix whatever the problem is that's
causing the corruption in the first place and you won't have to do
even that.

 

[Richard Bonomo]

Dear David and Tony,

I did indeed recommend to my boss that he read this thread.

In the meantime, I am working on restoring the database manually.
The problem seems to affect only the reports, and nothing
else.

Regarding open vs. close format: It may well be that there are no open-format
systems with sufficient functionality. I've never had the occasion to
actually look
for something like that.

Merry Christmas, and have a good new year!

Rich

 

[David W. Fenton]

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

Regarding open vs. close format: It may well be that there are no
open-format systems with sufficient functionality. I've never had
the occasion to actually look
for something like that.

After the A2K debacle, many of us in this newsgroup worked hard at
coming up with a replacement for Access. After much investigative
work, we all gave up. Nothing has changed in that time, so far as
I'm aware.