corrupt front

  • Thread starter Thread starter chriske911
  • Start date Start date
C

chriske911

does anyone know how a mdb file is supposed to be build or have a link so I
can try to see what's wrong with the file

I've already read about the first bytes having to be empty or filled with an
encrypted password

the file got corrupted when the network failed, compact and repair doesn't
work, I just can't open the file at all

I see a lot of endobj, endstream, parent, resources and so on so I guess
there is a certain logic buildup

thnx
 
does anyone know how a mdb file is supposed to be build or have a link so I
can try to see what's wrong with the file

I've already read about the first bytes having to be empty or filled with an
encrypted password

the file got corrupted when the network failed, compact and repair doesn't
work, I just can't open the file at all

I see a lot of endobj, endstream, parent, resources and so on so I guess
there is a certain logic buildup

Inasmuch as the MDB file format has not been fully documented, it would be
difficult to pass that information on. There are recovery companies that
specialize in recovering your data from corruption files, but they won't give
away such information for free. See the following page at Tony Toews' web site
for a plethora of helpful information on this subject and, if you must resort to
the same, links to the web sites of several such recovery companies:

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

The most important thing that you must do when trying to recover an apparently
corrupted file is to work with a copy of the file, not the original, to avoid
worsening the degree of corruption.
 
chriske911 said:
the file got corrupted when the network failed, compact and repair doesn't
work, I just can't open the file at all

Presumably you mean the front end on the server got corrupted? If so
you really want to put the FE on each machine or place in a user
specific directory on the server. This will help avoid some wierd
error messages when users are changing the same forms record source,
filters and such as well as corruptions.

I specifically created the Auto FE Updater utility so that I could
make changes to the FE MDE as often as I wanted and be quite confident
that the next time someone went to run the app that it would pull in
the latest version. For more info on the errors or the utillity see
the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the
FE on each PC up to date.

In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating a directory named after the user on a server. Given
a choice put the FE on the Citrix server to reduce network traffic and
to avoid having to load objects over the network which can be somewhat
sluggish.

Tnoy
--
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
 
it was actually my own development front wich got corrupted, in an attempt
to make that backup it got corrupted, not very much a problem but I had just
written quite some code and now it's all lost s|;()

thnx
 
chriske911 said:
it was actually my own development front wich got corrupted, in an attempt
to make that backup it got corrupted, not very much a problem

Now that's unusual if you weren't sharing it. Or if someone hadn't
somehow been in it at the same time as you were.

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
 
bad NIC, I had to have a few copy commands going sour before I was
convinced, other NIC solved my problem

I was connected with the back end to fullproof my code, I don't see any
other convenient way to do this other then relinking every time I deliver a
compiled front but I skipped that one out of laziness, I'll think twice next
time

noone has any idea of a guide to depend on for recovery of data, I think
it's a pointer gone bad or something similarly easy like that ?

thnx
 
chriske911 said:
bad NIC, I had to have a few copy commands going sour before I was
convinced, other NIC solved my problem

Ah, glad you could track it down. But this corrupted the FE which was
on your own system? If so that's unusual.
I was connected with the back end to fullproof my code, I don't see any
other convenient way to do this other then relinking every time I deliver a
compiled front but I skipped that one out of laziness, I'll think twice next
time

From my Splitting your Microsoft Access MDB into a front end and back
end page at my website.

At one client I use a variation of the drive letter approach and don't
bother to relink the tables. I have two three line batch/cmd files. In
one I use the SUBST command to create a drive letter which is the same
as the server drive letter. In the other I use the NET USE command to
link to the drive letter on the server. In both cmd files I delete the
SUBST and the NET USE first.

I then copy the clients live BE data MDB to my system every day or two
to ensure I'm working with a reasonably current copy of their data. I
can then do any testing I want on my own system without affecting the
live BE. This includes accidentally deleting the entire contents of
one transaction table when I forgot to put a WHERE clause on a DELETE
query. <smile> I run the above cmd files to switch between using the
live BE and my copy of it. If I need to update the backend's tables,
fields and/or relationships I wait until the end of the day when
everyone is out of the system. Once added I copy it down again.

I also have an always open form in the corner which, for me only, is
pale yellow if the BE is on a local hard drive. However if the BE is
on a network drive this form becomes the reddest possible value. This
makes an excellent visual warning for me to be very careful what I do.
<smile>

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
 
I never considered to use subst for this but it sounds like an excellent
advice,

thnx a bunch
 
Back
Top