Mysterious Shutdowns
Eric
stubborn old clients. The project I'm working in has:
Tables: 62 (46 linked)
Queries: 152
Forms: 224
Reports: 113
Macros and Modules: 26
.mdb = ~10mb compacted
I don't think this is terribly large nor can I figure any other reasons. It
has the same behavior when on a PII, PIII, and P4. WinXP, Win2kServer,
Win2kPro, Win98SE.
Example follows:
It's time to distribute the file to clients so as usual I begin by cleaning
up the code:
Open a module | Debug | Compile and Save all Modules
The computer "thinks" briefly and then access just shuts down. No blue
screen of death, no IPF, etc... Just closes. Of course the .ldb is ghosted
(which I easily remedy).
I have "Repaired", I have converted to 2000 (and 2002) and back again.
Naturally both of those compile fine... I have tested on 3 different
machines using 4 different operating systems.
I have repaired my installation of Access 97, re-applied both service packs,
and did "fresh" installations.
I have even thouroghly and successfully beta tested the few additions to the
code I made since it has ceased working correctly...
As an additional note, there are other times it dies quietly.
Example:
I'm typing "Dim sSTR AS String"...
When I type the " " after "AS" it dies.
This of course is normally the point when the auto-list of variable types
appear...
*laughs evily*
Any takers on this one?
Thanks in advance,
Eric
Joe Fallon
1. Try /decompile on a backup copy.
Then compact/repair it.
2. Import all objects to a new .mdb file.
3. Try the undocumented SaveAsText and LoadFromText.
It may help if an object is corrupted or otherwise behaving weirdly.
At the debug/immediate window type:
Application.SaveAsText acForm,"MyForm","c:\form.txt"
You can load the file into a new MDB.
Application.LoadFromText acForm,"MyForm","c:\from.txt"
--
Joe Fallon
Access MVP
"Eric" <mcsw...@missouri.edu> wrote in message
news:ut2E4%23mFDH...@TK2MSFTNGP12.phx.gbl...
Eric
Just to be sure I spent some (significant) time re-trying those things you
offered below.
1. I tried to /decompile, then compact/repair, then compile and save all
modules
This went fine but as soon as I tried to open one of the suspect forms all
began dying again.
2. I could not import objects into a new .mdb (access 97). Everytime it
got to one of a few suspect objects, the import dies horribly.
3. SaveAsText and LoadFromText - No luck.
4. Another try of note: I created a new 2000 .mdb, and imported all the
Access 97 objects, toolbars, etc... This went fine unlike the import into a
new Access 97 DB.
So I 'fixed' my references to DAO 3.6 and Compiled. Again with success.
I tested the suspect forms and functionality in 2000. All went fine as
suspected (considering I routinely distribute this App as compiled 97 and
2000 versions).
Finally, I converted this 'new' 2000 db back to Access 97 (which in turn
/decompiles the code of course).
I opened this 'new' twice-converted file in Access 97, compacted/repaired,
then compiled and saved all modules. As in attempt #1 this seemed to work
just fine.
Once again however, upon opening certain (not necessarily the same) objects
97 began dying horribly all over again.
*sighs*
Any other ideas?
Thanks for your time...
Eric
PS - I do have Access 97 SR2b and JetComp.exe (SR-3) installed.
I have tried these processes on two different Access 97 computers, and two
more Access 2000 computers. All with fairly similar, unsuccessful
results...
"Joe Fallon" <jfal...@nospamtwcny.rr.com> wrote in message
news:%23E%23y82qF...@tk2msftngp13.phx.gbl...
Joe Fallon
Any one of those 3 solutions usually works.
Can't believe they all failed.
<desperation>
Have you tried all of this on a different PC?
Maybe it is the box.
--
Joe Fallon
Access MVP
"Eric" <mcsw...@missouri.edu> wrote in message
news:e2JMOElH...@tk2msftngp13.phx.gbl...
Daniel Findley
A97 DB too. Never did fix it properly. /decompile would fix it for a
while, then it'd go off and die on me again.
Exact same symptoms too - import to new DB crashes, dim foo as
crashes, opening the bad form crashes.
In the end I just threw away the offending section of the database and
rewrote the form from scratch. Not fun, but it fixed it...
I'd also be interested to hear if anyone has a workaround for this.
Cheers
Dan
"Eric" <mcsw...@missouri.edu> wrote in message news:<e2JMOElH...@tk2msftngp13.phx.gbl>...
Brian Gallagher
database layout which cannot be changed easily.
The way I got around it was to create a new form either before or after the
form that was playing up.... Hey presto the bad form worked again......
Then all I did was copy the bad form to a new name deleted the original form
and the temporary form before or after the oroginal and finally rename the
new copied for to it's original name.
This fixes the problem but as you are aware re-appears later on but in a
differnt place..... Seems a but half cock to me but means you don't lose
the work you have done on the forms already created!
Regards
Brian
PS This still happens in XP!
"Daniel Findley" <real...@yahoo.com.au> wrote in message
news:a2551686.03051...@posting.google.com...
Daniel Findley
Thanks for the workaround though. I must remember that for if it
happens again. Thanfully its only happened on one database so far
(touch wood).
Joe: Yup, happened consistently on every machine I could get my hands
on (about half a dozen). Each one had different software installed
(some had VB, some had Visio, etc). It had me absolutely stumped at
the time!
"Brian Gallagher" <bgall...@sbsdeveloper.co.uk> wrote in message news:<0mAya.612$8D2...@news-binary.blueyonder.co.uk>...
Eric
Win98 + Off97
Win2kPro + Off97
WinXPPro + Off97
Additionally, even after converting to 2k it still fails (eventually) on
Win98 + Off2k (or OffXP)
Win2kPro + Off2k (or OffXP)
WinXPPro + Off2k (or OffXP)
So what I'm hearing is that this DB is really screwed up now? And there is
no fixing it? So I have 1000 hours in this thing and have to start from
scratch to fix it for good?
hrm... bummer.
What do you think?
I thank you for the attention.
Best Regards,
Eric
"Joe Fallon" <jfal...@nospamtwcny.rr.com> wrote in message
news:ew$srMmHD...@TK2MSFTNGP10.phx.gbl...
Joe Fallon
Which is more important right now - time or money?
================================================
Money solution:
Peter Miller is the guru for fixing corrupt databases:
http://www.pksolutions.com/services.htm
"Our most popular rescue service is our Data Recovery Service.
Occasionally, databases can become corrupted. Usually the inbuilt Repair
capability will correct the problem, or its possible to create a new
database based upon the corrupted one. If you are unable to recover from a
database corruption problem, and either do not have, or don't think its
feasable to rely upon an older backup of the database, then our service is
just what you need. Data recovery services are provided for a fee ranging
from US$120 to US$1,200 (although the majority of jobs cost less than
US$600). Our success rate for complete data recovery exceeds 96%. If you
would like us to take a look at a damaged Access database for you, then
please complete the form below. "
--
Joe Fallon
Access MVP
"Eric" <mcsw...@missouri.edu> wrote in message
news:OWVOraKI...@TK2MSFTNGP11.phx.gbl...
Brian Gallagher
regular basis....
The solutions all seem to get around it but none seem to cure it for good...
Sorry I can't be more help!
"Eric" <mcsw...@missouri.edu> wrote in message
news:OWVOraKI...@TK2MSFTNGP11.phx.gbl...
Marshall Barton
>So what I'm hearing is that this DB is really screwed up now? And there is
>no fixing it? So I have 1000 hours in this thing and have to start from
>scratch to fix it for good?
Before considering tossing the whole thing, try a hybrid
approach. Do what you can to clean things up as best you
can, then create a new, blank database and Import each item
one at a time. When you run into a problem form or report,
use copy/paste to copy blocks of controls and the code
behind the object. Similarly for modules. For queries,
copy/paste the query's SQL.
Double check all the records in each table, it's remotely
possible that there is some data that is bad enough to cause
corruption to spread to spread to other areas - especially
memo or other blob type fields. It might help to recreate
the tables in the new db and use Insert Into queries to
bring the data across.
--
Marsh
MVP [MS Access]
Eric
results.
The DB in question has very few of it's own tables (temp tables mostly). It
does have a few for version control and schema changes (changes to client
data files). None of these tables contain unweildy blob or ole fields.
I generally run accross 2 or 3 forms and a module that fails to import.
Those I've created from scratch using the copy and paste methods. After
which the db behaves for a while.. then dies again.
When doing a subsequent import/copy/paste to fix the latest corruption the
module and/or forms that cause trouble aren't the same ones.... *sighs*
Again, the db (interface really) is large and complex. might it just be too
much for MS Access?
Diligently,
Eric
"Marshall Barton" <marsh...@mindspring.com> wrote in message
news:0u9scv0cu2drgsd4r...@4ax.com...
Eric
can do for me.
Eric
PS - If they can help me with the problem I'll be sure to post a follow-up
here as well.
"Joe Fallon" <jfal...@nospamtwcny.rr.com> wrote in message
news:%236tcjRM...@TK2MSFTNGP11.phx.gbl...
Marshall Barton
>Thanks for the response. Unfortunately I've tried this method with poor
>results.
>
>The DB in question has very few of it's own tables (temp tables mostly). It
>does have a few for version control and schema changes (changes to client
>data files). None of these tables contain unweildy blob or ole fields.
>
>I generally run accross 2 or 3 forms and a module that fails to import.
>Those I've created from scratch using the copy and paste methods. After
>which the db behaves for a while.. then dies again.
>
>When doing a subsequent import/copy/paste to fix the latest corruption the
>module and/or forms that cause trouble aren't the same ones.... *sighs*
>
>Again, the db (interface really) is large and complex. might it just be too
>much for MS Access?
I seriously doubt that it's too much for Access, but there
may be something else going on here.
If it works OK "for a while", then it sounds like you've
removed the corruption, but it keeps coming back. I suggest
that you try to fix the cause of the corruption.
If all the users are sharing a single copy of the front end
db from a server, the likelyhood of corruption is greatly
increased, especially if there is a flakey network card or
cable somewhere on the LAN.
Since it's the front end that's being corrupted, maybe you
have some code that makes this more likely than an alternate
approach would. Creating and/or updating objects (forms,
reports, tables, etc) at runtime is a potential cause of
front end corruption.
OTOH, it might be flakey users that power off their machine
in the middle of some kind of save operation.
Or, it could be flakey power
Or . . .
--
Marsh
MVP [MS Access]
Eric wrote:
>> >So what I'm hearing is that this DB is really screwed up now? And there
>is
>> >no fixing it? So I have 1000 hours in this thing and have to start from
>> >scratch to fix it for good?
>>
>"Marshall Barton" wrote
Eric
experience have never been distributed to the end user. I identified the
problem early enough that they 'got by' without any updates for the time
being.
These supposed corruptions are occuring on my development machine(s)
-Split database app of course
-front end and back end residing on local machine.
I HAVE had data corruptions in the past for the reasons you've listed below
though...
The good news is that the comprehensive solution to this may have been
found, I'll post that on the root of the threed though.
Best Wishes,
Eric
"Marshall Barton" <marsh...@mindspring.com> wrote in message
news:2ml9dvci4u8u49jes...@4ax.com...
Eric
Ok, given all the information in this thread I won't go over any deatils
about the problem. Just the fix.
The solution has to do with the Application.SaveAsText / .LoadFromText
methods respectively.
In the past, whenever these kind of corruptions occurred, I would make a new
DB and import all objects into it (using same version of MS Access or
newer). Any forms, reports, or modules that caused MS Access to puke on
import would be skipped and .SaveAsText/.LoadFromText would be used for
those few forms. This has fixed almost all vba corruptions until this one
reared it's ugly head.
What I've discovered is this: Some layout type corruptions (invalid layout
/ property settings) will sometimes import into Access with no problem. As
such, it can be assumed that it is these little nasties that propogate
corruptions in the new db. Hence, "it works for a while..."
So....
Peter Miller of PKSolutions (he should get all the credit for this)
recommended that I do a .SaveAsText / .LoadFromText for ALL of my forms,
reports, and modules. Macros, Queries, and Tables (linked or otherwise)
could be imported without fear as they are data-based objects.
I created 3 seperate routines to cycle through all Forms, Reports, and
modules, saving them as text (it's a good idea to put these text files into
seperate directories to avoid excess coding for the .LoadFromText end of
this).
I then created the new db and imported all tables, queries, and macros.
Created (in the new db) 3 seperate routines to iterate through the text
files in a given directory (Dir Method) and .LoadFromText into the new db.
One or more of these objects SHOULD fail using .LoadFromText so accommodate
for this in your routine. I happened to log (in a variable) the name of the
object, then resumed the code so that I could get the other objects without
having to figure out where I left off.
NOTE: I also compacted and compiled the db after each type of object (thus,
I had to do the modules first).
I found that there were 3 forms and 1 report that were NOT able to import
using .LoadFromText. Each had a layout property error:
Invalid Form - Top property
or
Invalid Label - Left property respectively.
These forms I recreated from scratch and all is well. Normally the
corruption reappears within a short time, but as of yet has not. I will let
everyone know if it does crop up again (in the near future), but even at
this point this seems to be the best solution that I've found.
Thanks to Joe Fallon for pointing me to PKSolutions!
Thanks to Peter Miller of PKSolutions not only for providing me with the
best solution to date, but also for responding to my contact within MINUTES
via telephone!
Thanks to all and Best Regards,
Eric McSwain
"Eric" <mcsw...@missouri.edu> wrote in message
news:ut2E4%23mFDH...@TK2MSFTNGP12.phx.gbl...
Joe Fallon
Peter may be THE most knowledgeable person on the planet in regards to mdb
corruption.
I think other people could benefit from your code to loop through these
collections and hnadle the problems. It would be great if you could post it
for future reference.
Thanks.
P.S.
Now, go back and read my original response! <g>
" Try the undocumented SaveAsText and LoadFromText.
It may help if an object is corrupted or otherwise behaving weirdly."
--
Joe Fallon
Access MVP
"Eric" <mcsw...@missouri.edu> wrote in message
news:e1HYA6eJ...@tk2msftngp13.phx.gbl...