Frequent Access 2003 corruption that cannot be repaired

[Vladimír Cvajniga]

Is it a bug? Does Microsoft know about it?

Turn it OFF and you'll have less corruption.

 

[Vladimír Cvajniga]

No, this one should have no effect on VBA code. There may be others...

 

[Vladimír Cvajniga]

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

 

[Vladimír Cvajniga]

Turned OFF.
TYVM.

Vlado

Turn it OFF and you'll have less corruption.

 

[Vladimír Cvajniga]

The problem remaine even with COMPILE ON DEMAND set to OFF. :-(

Vlado

 

[David W. Fenton]

The problem remaine even with COMPILE ON DEMAND set to OFF.

Well, of course it does if you don't completely recreate the MDB
from scratch.

 

[Vladimír Cvajniga]

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

 

[Vladimír Cvajniga]

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.

 

[Vladimír Cvajniga]

Yesterday I was directed to
http://groups.google.co.uk/group/co...ON+DEMAND+is+ON&rnum=1&hl=en#639b2de99404b26b.

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

Vlado

 

[dbahooker]

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 FUCKING
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.

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.

 

[David W. Fenton]

Does that mean that I must create all tables, queries, forms,
reports & modules again? :O

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?

No, it won't be enough.

Or, import will do what I need now?

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!

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.

 

[David W. Fenton]

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!

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).

 

[David W. Fenton]

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

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

 

[David W. Fenton]

Yesterday I was directed to

[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.

If you're a professional Access developer, these are the kinds of
things that you should already know, seems to me.

 

[dbahooker]

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

 

[dbahooker]

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

 

[dbahooker]

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

Yesterday I was directed to

[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.

If you're a professional Access developer, these are the kinds of
things that you should already know, seems to me.

 

[Vladimír Cvajniga]

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

Yesterday I was directed to

[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.

If you're a professional Access developer, these are the kinds of
things that you should already know, seems to me.

 

[Vladimír Cvajniga]

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

 

[Vladimír Cvajniga]

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

Vlado