access data base closed fine now access does not respond

[Guest]

I closed my access db file and when I try to open the file it does not open
but causes access not to respond and hang up, I would appreciate any help
with this it contains our entire ranch data base

 

[Guest]

I hope you have a recent back-up copy of your database. Make a copy of this
database now, and save it just in case you need to seek the services of a
data recovery professional. Don't do anything with this copy.

Try rebooting your PC, then see if you can open the copy that you just made.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

I closed my access db file and when I try to open the file it does not open
but causes access not to respond and hang up, I would appreciate any help
with this it contains our entire ranch data base

 

[Guest]

Tom,
After 2 days of trying to open the database, today it opened, it may not
ever open again but it was backed up and there was already a copy of it on my
jump drive
however yesterday it would not open the copy from the jumpdrive either, do
you have any idea what I did to cause this problem and can it be corrected,
the db contains cattle numbers, dates and cattle locations, it isn't
complicated any assistance would be greatly appreciated.
Northstar Ranch/Texas

 

[tina]

you may have a corruption problem, even on the backup db. try this: open a
new, blank database. immediately turn OFF the Name AutoCorrect option (if
you don't know how, see http://home.att.net/~california.db/instructions.html
for illustrated instructions). then import the objects from the database in
groups - first tables, then queries, etc. run a compact/repair. if the
database opens/runs normally, back it up.

also, to preserve the *data* - even if the database croaks - you might want
to periodically export each table in the database as a text file.

hth

 

[Guest]

Here is some information that is well worth reading:
Preventing Corruption (Allen Browne)
http://allenbrowne.com/ser-25.html

Corrupt Microsoft Access MDBs FAQ
http://www.granite.ab.ca/access/corruptmdbs.htm

To add some to Tina's input, here is my standard verbage for doing the same
thing that she recommended:

Create a brand new database and immediately disable the NameAutocorrupt
feature (see: http://allenbrowne.com/bug-03.html for reasons why you want to
do this). Then import all objects from the suspect database into the new
database, one group at a time, into your new database. In other words, import
all tables (but not linked tables), then import all queries, then all forms,
etc. While Access will allow you to import all objects in one operation, the
experts at FMS, Inc. (a Microsoft Partner), have stated that it is best to
import objects one group at a time (Reference:
http://www.fmsinc.com/ubb/Forum12/HTML/000285.html).

Recreate any linked tables from scratch. Access can cache a lot of
information about linked tables, which may no longer be valid, so it's always
best to recreate the linked tables from scratch. When importing local tables,
make sure to check the option to import relationships, menus and toolbars,
and import/export specs. If any of the local tables in the source DB are
hidden, you'll need to first unhide them. You will need to set the checked
references to match the source database, along with any startup options set
under Tools > Startup. Going through this process often times solves
corruption problems, because you get a new set of the hidden system tables
(the tables whose names start with "MSYS"). These system tables are updated
appropriately as you import objects.

This may sound like a lot of work, but it really isn't. Creating a new
container DB, disabling NameAutocorrect, importing all objects one group at a
time, re-establishing any linked tables, setting startup options, and setting
references to match the source DB is usually a fairly quick procedure. When
you are in the Visual Basic Editor, in order to check that the references
match the source DB, you should do a Debug > Compile ProjectName as well.


Good Luck,

Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

Tom,
After 2 days of trying to open the database, today it opened, it may not
ever open again but it was backed up and there was already a copy of it on my
jump drive
however yesterday it would not open the copy from the jumpdrive either, do
you have any idea what I did to cause this problem and can it be corrected,
the db contains cattle numbers, dates and cattle locations, it isn't
complicated any assistance would be greatly appreciated.
Northstar Ranch/Texas

 

[Tony Toews]

Then import all objects from the suspect database into the new
database, one group at a time, into your new database. In other words, import
all tables (but not linked tables), then import all queries, then all forms,
etc. While Access will allow you to import all objects in one operation, the
experts at FMS, Inc. (a Microsoft Partner), have stated that it is best to
import objects one group at a time (Reference:
http://www.fmsinc.com/ubb/Forum12/HTML/000285.html).

That's the first I've heard of that advice of importing each set of
objects in different operations. And I can't think of any reason why
that would be useful.

So I'm going to disagree with Troy's comments.

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

 

[Guest]

I have just forwarded this thread to (e-mail address removed), with the request
that they send it to Troy. Perhaps Troy (or fellow Access MVP Steve Clark,
also an FMS employee) can enlighten us on why this statement was made.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

That's the first I've heard of that advice of importing each set of
objects in different operations. And I can't think of any reason why
that would be useful.

So I'm going to disagree with Troy's comments.

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

 

[TC]

My bet is, they suggest doing it that way so that it is easier to find
a corrupt object. Eg. if the tables import, but the forms don't, the
user should start again, importing just the forms, one by one. If you
imported everything in one go, it might be harder for an inexperienced
user to work out which object was bad.

HTH,
TC [MVP Access]

 

[Guest]

I found a supporting reference published by Microsoft. Hopefully the folks at
FMS can fill us in on the details of why this is important.

http://support.microsoft.com/?id=283849#XSLTH3135121123120121120120

See step 4:
If the previous steps fail to recover your damaged database, try creating a
new database and importing the objects, one-by-one, from the old database to
the new one. Then re-create the relationships. This technique resolves
problems with damaged system tables in the database.

Also, a friend of mine who is very knowledgeable in Access, wrote the
following in a private reply by e-mail. So, take it for what it's worth:

<Begin Quote>
Long before I had ever heard of FMS, I was fixing corrupt databases. Lots
of corrupted databases. I found that if there’s more than one type of object
corrupted, such as a table and a couple of forms, then importing all objects
from the bad database file in one fell swoop will increase the likelihood
that the new file will also be corrupted. If I broke the import down into
three or four steps, I increased the chance of success to nearly 100%. First
the tables were imported, then the queries, then the code-based objects, and
then the macros (if any).

When I heard that FMS recommended each group be imported independently, I
figured it was confirmation of much of what I had already discovered, but I
also started importing the forms, reports, and modules separately, as FMS
advised.

</End Quote>



Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

I have just forwarded this thread to (e-mail address removed), with the request
that they send it to Troy. Perhaps Troy (or fellow Access MVP Steve Clark,
also an FMS employee) can enlighten us on why this statement was made.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

That's the first I've heard of that advice of importing each set of
objects in different operations. And I can't think of any reason why
that would be useful.

So I'm going to disagree with Troy's comments.

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 Toews]

I found a supporting reference published by Microsoft. Hopefully the folks at
FMS can fill us in on the details of why this is important.

http://support.microsoft.com/?id=283849#XSLTH3135121123120121120120

See step 4:
If the previous steps fail to recover your damaged database, try creating a
new database and importing the objects, one-by-one, from the old database to
the new one. Then re-create the relationships. This technique resolves
problems with damaged system tables in the database.

But that is object by object. The guy from FMS stated type of object.
And I can't think of any reason why either method would make a
difference.

The only reason I can think of for the MS object by object is to make
it quite clear to the person doing the importing exactly which table
is causing the troubles. Which you could easily do after the
importing crashed Access and you looked into the new MDB.

Also, a friend of mine who is very knowledgeable in Access, wrote the
following in a private reply by e-mail. So, take it for what it's worth:

<Begin Quote>
Long before I had ever heard of FMS, I was fixing corrupt databases. Lots
of corrupted databases. I found that if there’s more than one type of object
corrupted, such as a table and a couple of forms, then importing all objects
from the bad database file in one fell swoop will increase the likelihood
that the new file will also be corrupted. If I broke the import down into
three or four steps, I increased the chance of success to nearly 100%. First
the tables were imported, then the queries, then the code-based objects, and
then the macros (if any).

Well the macros shouldn't matter what sequence they are imported in as
they are not dependent an any other objects.

However I'm still not convinced. <smile> I'd sure like to know why
that is the case.

Now I have to admit that I've never dealt with an MDB that had both
corrupted tables and other objects because I've always worked with
split FE/BE once the system has been delivered to the client.
Possibly that's a factor.

Did your friend try both methods a number of times?

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 Toews]

My bet is, they suggest doing it that way so that it is easier to find
a corrupt object. Eg. if the tables import, but the forms don't, the
user should start again, importing just the forms, one by one. If you
imported everything in one go, it might be harder for an inexperienced
user to work out which object was bad.

Yeah, that's what I was thinking too.

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

 

['69 Camaro]

Did your friend try both methods a number of times?

Yes. Hundreds of times. I was on an unstable OS (Windows 95) on an
unstable network with more than a thousand users on 43 Access/Web/other
software applications that I supported, and not one of their managers
allowed me to split their shared Access databases. (The database experts I
worked with told them we didn't need to.) We had a _lot_ of corrupted
databases when I was an Access developer.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
See http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

 

[Tony Toews]

Yes. Hundreds of times.

Ah, you're the friend. Competent too. Not that I didn't believe Tom

I was on an unstable OS (Windows 95) on an
unstable network with more than a thousand users on 43 Access/Web/other
software applications that I supported, and not one of their managers
allowed me to split their shared Access databases. (The database experts I
worked with told them we didn't need to.) We had a _lot_ of corrupted
databases when I was an Access developer.

<sigh> Useless idiots those. Surely after the first few corruptions
they'd get the hint.

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

 

[Guest]

Hi Tony,

I received a reply from FMS today. This is shown below.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
*********************************************

From: Technical Support
To: Tom Wickerath
Sent: Tuesday, January 10, 2006 2:19 PM
Subject: RE: Microsoft Community Notification - RE: access data base closed
fine now access does not respond


Hello Tom,

Thank you for your correspondence and for taking the time to consider our
software solutions for your development needs. While Troy Munford is no
longer an employee here at FMS, my name is John Litchfield and I have taken
is place. I appreciate you taking the time to provide us with this
information follow-up. Please note that while there is not a simple
"absolute" procedure that is guaranteed to resolve all cases of corruption,
we have had specific cases where importing all objects at a time resolved
corruption where importing all objects did not. That said, we are always
interested in knowing if a later version of Microsoft Access, Service Pack,
or even a factor that we have not considered creates a twist. I will be sure
to review the links you have provided and on behalf of FMS, I would like to
thank you for sharing this information with us.

Thank you for taking the time to contact us Tom and please let me know if I
may be of further assistance to you.
John.

John Litchfield
Development Support Specialist
FMS Inc.

--------------------------------------------------------------------------------
From: Tom Wickerath
Sent: Sunday, January 08, 2006 8:26 PM
To: Technical Support
Subject: Fw: Microsoft Community Notification - RE: access data base closed
fine now access does not respond


Hello,

Can you please pass this on to Troy Munford. Access MVP Tony Toews
apparently disagrees with advice that Troy previously gave in this link:
http://www.fmsinc.com/ubb/Forum12/HTML/000285.html regarding importing
objects one group at a time versus importing all objects in one operation.

http://www.microsoft.com/office/com...cess&mid=58dd7cc8-ac1d-4238-9076-91b8fb74a0f8


Thank You

 

[Tony Toews]

I received a reply from FMS today. This is shown below.

Not overly specific but ...

we have had specific cases where importing all objects at a time resolved
corruption where importing all objects did not.

Now that's not clear wording at all. But I'll assume they mention
"importing all objects one at a time".

Tedious though.

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