Frequent Access 2003 corruption that cannot be repaired

  • Thread starter Thread starter Guest
  • Start date Start date
No, this one should have no effect on VBA code. There may be others...
 
What do you think I don't understand? I wrote I would prefer EXEs instead of
MDBs. What kind of missunderstanding is it?
 
The problem remaine even with COMPILE ON DEMAND set to OFF. :-(

Vlado
 
Does that mean that I must create all tables, queries, forms, reports &
modules again? :O
Or, will de-compile be enough?
Or, import will do what I need now?

I can't imagine that I have to to re-create the whole MDB project
step-by-step. If it's true I will surely switch to Delphi! :-)

Vlado
 
Is it true? I will have to write a letter to Microsoft to clarify the
database corruption issue. I simply can't spend time on MDB re-creation.

I'd appreciate some rules what can be done and what cannot be done while
creating a project and debbugging it. If changes in break mode can destroy
my project then there's something wrong in Access's concept!

Vlado

P.S. TYVM for giving us this information.
 
Vladimir;

I _MILITANTLY_ support you and your postings.

please keep up the good work. Access has been BUGGY AS HELL FOR YEARS
and MS is too busy 'selling us a new version' INSTEAD OF ****ING
FIXING BUGS

sign me up for your army; I would like to barge into MS and show them
a laundry list of bugs.

It blows my mind how they can sit there and SELL us a new version with
new bugs; instead of fixing the old buggy ass version.

I really appreciate having someone else with a BACKBONE around here.

Keep up the good work!

-Aaron Kempf
ex-MSFTie




What do you think I don't understand? I wrote I would prefer EXEs insteadof
MDBs. What kind of missunderstanding is it?

Of course I remember.
Click to expand...
That you ask this question shows that you truly *don't* understand
Access, nor why there would be no advantage at all to having an EXE.
Click to expand...
Click to expand...
 
Does that mean that I must create all tables, queries, forms,
reports & modules again? :O
Click to expand...

Tables and queries are Jet objects, not Access objects, and not
code-bearing, so not relevant to issues of VBA corruption. So, no,
you don't have to recreate those.
Or, will de-compile be enough?
Click to expand...

No, it won't be enough.
Or, import will do what I need now?
Click to expand...

Many people recommend this, but I don't find it sufficient, unless
imported via Application.LoadFromText.
I can't imagine that I have to to re-create the whole MDB project
step-by-step. If it's true I will surely switch to Delphi! :-)
Click to expand...

If you have good practices that avoid corruption in the first place,
no, you never have to do this (or only very, very seldom -- I
haven't done it since 2003). But if you *aren't* using good
practices, then the only way to completely rid yourself of the
corruption is to recreate the project without retaining any of the
corruption.

The only real way to do this is SaveAsText/LoadFromText. Importing
decompiled objects doesn't always get rid of corruption.
 
Does that mean that I must create all tables, queries, forms,
reports & modules again? :O
Or, will de-compile be enough?
Or, import will do what I need now?

I can't imagine that I have to to re-create the whole MDB project
step-by-step. If it's true I will surely switch to Delphi! :-)
Click to expand...

BTW, you shouldn't have tables and forms mixed in a single MDB, so
your first question makes no sense at all.

If a tables-only MDB is corrupted, that's a completely different
form of corruption than what I thought we were talking about.

And a front-end MDB would likely have only code corruption, since
the amount of data in tables is trivial (in comparison to your back
end).
 
I will have to write a letter to Microsoft to clarify the
database corruption issue. I simply can't spend time on MDB
re-creation.
Click to expand...

I don't spend any time on that, either, because my apps don't
corrupt.

But since you've already *got* corruption, you have to get rid of
it, and the only reliable way to do that is a one-time recreation of
the corrupted project.
I'd appreciate some rules what can be done and what cannot be done
while creating a project and debbugging it. If changes in break
mode can destroy my project then there's something wrong in
Access's concept!
Click to expand...

No, it's something wrong in the way you're using it.
 
David;

your split frontend backend crap is doing NOTHING but wasting this
guys time.

Yes; you are correct- you shouldn't have tables and forms in the same
file BECAUSE EVERYONE SHOULD USE ADP FOR EVERYTHING.

ADP IS BIGGER, BETTER, FASTER, EASIER, MORE RELIABLE

MDB you need a month to learn all these friggin workarounds

MDB is ridiculous; it is not a tool for beginners; and it never has
been.

MDB takes MORE MAINTENANCE and RUNS SLOWER than adp

stick a cork in it; jet-lovin-fag
 
NOTHING IS WRONG; ACCESS IS BROKEN.

OUT OF THE BOX; IF ACCESS CAUSES CORRUPTION IT IS AN ACCESS PROBLEM
AND NOT A BEST PRACTICES PROBLEM
 
David;

if you were a professional Access developer; you would be using ADP!

MDB is dead; and it has been for 10 years


stick a cork in it; if you know of anyone using MDB; fire them and
then spit on them




Vladimír Cvajniga said:
Yesterday I was directed to
Click to expand...

[thread on the dangers of COMPILE ON DEMAND]
http://groups.google.co.uk/group/comp.databases.ms-access/browse_th
read/thread/3414643c680315b0/639b2de99404b26b?lnk=st&q=COMPILE+ON+D
EMAND+is+ON&rnum=1&hl=en#639b2de99404b26b.
Click to expand...
It's quite important to know that Access can do such funny things.
Click to expand...

If you're a professional Access developer, these are the kinds of
things that you should already know, seems to me.
Click to expand...
 
Where could I get the information from? Access help? They don't mention ANY
possibility of database corruption. So how can I get the information? Do I
have go through help and pass all its lessons one by one to Google and
search if an appropriate Access's function is bug-free? Not a good idea...
:-/

Vlado

David W. Fenton said:
Yesterday I was directed to
Click to expand...

[thread on the dangers of COMPILE ON DEMAND]
http://groups.google.co.uk/group/comp.databases.ms-access/browse_th
read/thread/3414643c680315b0/639b2de99404b26b?lnk=st&q=COMPILE+ON+D
EMAND+is+ON&rnum=1&hl=en#639b2de99404b26b.

It's quite important to know that Access can do such funny things.
Click to expand...

If you're a professional Access developer, these are the kinds of
things that you should already know, seems to me.
Click to expand...
 
No, it's something wrong in Access! It should NOT let me do things that may
corrupt the project!!! Or, at least, I need correct information of what I'm
allowed to do and when. But there are no warning in Access's help to tell me
that I may not change code in break (debug?) and that my project may be
destroyed after such actions... :-/

Vlado
 
But why my VB6 projects never get corrupted? I'm doing same things there,
ie. changing code in break/debug...

Vlado
 
Back
Top