By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,854 Members | 1,871 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,854 IT Pros & Developers. It's quick & easy.

Corruption - how to MAKE it happen?

P: n/a
I am in a friendly debate with some co-workers... and my boss.

We use Access 2003 for the frontend (on workstations) as well as for
the backend (on a Dell PowerEdge running Windows 2000 server, SP4).
We have approx. 20 users *logged in* at any one time (over 300
userid's exist), but we have never run metrics to see how many on
average are accessing the database concurrently.

About once every few weeks, the database mysteriously becomes
corrupted.

One thing that seems pretty reliable is if my co-worker or I are in
design mode of a table and manually edit a record while someone else
is editing the same record via the frontend.

In addition, I thought that if I abnormally exited the program (CTRL-
ALT-DEL and kill the process while the program is loading, etc.), that
there would be a very good chance of corrupting the DB. Especially
(only?) if you killed it while it was accessing a record, before it
closed a recordset, etc.

Can anyone shed any light here? I have found several references
throughout this newsgroup, and even a Corruption FAQ:

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

but I would really like to know if abnormal termination would/should
do it. Random testing so far has been unable to reproduce the desired
corruption. I even tried running the code, setting a breakpoint in
the middle of a record operation, then CTRL-ALT-DELing the process.
No corruption.

Help?

Thanks.

Mar 22 '07 #1
Share this Question
Share on Google+
42 Replies


P: n/a
Having more than a single user logged in to a montolithic Access database or
a front-end significantly increases the chances of corruption, but does not
guarantee it -- based on your description, however, that does not seem to be
your case.

Because it is a file-server, when used with a Jet back-end, all the
processing is done on the user's machine, thus "abnormal termination" at
particular points in processing may leave internal pointers improperly set
because an operation was not completed. As Microsoft does not publish
details of the internals, and when, where, and why pointers are set/reset,
it's difficult to be more specific. That is, "ungraceful" or "abnormal"
termination is often involved, but it does not **always** cause corruption.

Because of the way Access-Jet operates, see above, it is far more sensitive
to dropped network connections, even if they are intermittent and brief,
than most other software.

And, well, if I had a list of situations that were guaranteed to cause
corruption, I'm not sure I'd think it appropriate to publish those in a
public newsgroup. I'd probably share them with Microsoft, in hopes that a
fix or workaround could be found, so they would soon not apply.

Larry Linson
Microsoft Access MVP

"Doug" <sp*******@gmail.comwrote in message
news:11**********************@y80g2000hsf.googlegr oups.com...
>I am in a friendly debate with some co-workers... and my boss.

We use Access 2003 for the frontend (on workstations) as well as for
the backend (on a Dell PowerEdge running Windows 2000 server, SP4).
We have approx. 20 users *logged in* at any one time (over 300
userid's exist), but we have never run metrics to see how many on
average are accessing the database concurrently.

About once every few weeks, the database mysteriously becomes
corrupted.

One thing that seems pretty reliable is if my co-worker or I are in
design mode of a table and manually edit a record while someone else
is editing the same record via the frontend.

In addition, I thought that if I abnormally exited the program (CTRL-
ALT-DEL and kill the process while the program is loading, etc.), that
there would be a very good chance of corrupting the DB. Especially
(only?) if you killed it while it was accessing a record, before it
closed a recordset, etc.

Can anyone shed any light here? I have found several references
throughout this newsgroup, and even a Corruption FAQ:

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

but I would really like to know if abnormal termination would/should
do it. Random testing so far has been unable to reproduce the desired
corruption. I even tried running the code, setting a breakpoint in
the middle of a record operation, then CTRL-ALT-DELing the process.
No corruption.

Help?

Thanks.

Mar 22 '07 #2

P: n/a
"Doug" <sp*******@gmail.comwrote:
>One thing that seems pretty reliable is if my co-worker or I are in
design mode of a table and manually edit a record while someone else
is editing the same record via the frontend.
I'm not quite clear on how you can be in the design mode of a table and edit a
record. Do you mean datasheet mode?
>In addition, I thought that if I abnormally exited the program (CTRL-
ALT-DEL and kill the process while the program is loading, etc.), that
there would be a very good chance of corrupting the DB. Especially
(only?) if you killed it while it was accessing a record, before it
closed a recordset, etc.
A client has had at least five power failures with no UPSs on the client systems with
about 15 to 20 users while I was on site. There was no corruption of the database.
I was rather surprised.
>but I would really like to know if abnormal termination would/should
do it. Random testing so far has been unable to reproduce the desired
corruption. I even tried running the code, setting a breakpoint in
the middle of a record operation, then CTRL-ALT-DELing the process.
No corruption.
What might work is running a SQL query updating a few thousand records and powering
off the system abruptly.

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
Mar 22 '07 #3

P: n/a
Per Doug:
>About once every few weeks, the database mysteriously becomes
corrupted.
This is one reason why I do my best to avoid using a JET back end for a
mission-critical application.

I've done it... because the user's insisted on it... but in one case I've had
big time regrets about playing along. In that case, the cause of the
corruptions seemed to be something about the file server the back end was on. We
moved the .MDB file to another server and the problem went away.

What made it so bad was that the organization was very large, with extremely
stringent change control procedures in place and getting somebody who had
permission to move the file took literally months - during which the users lives
became very difficult due to the recurring corruptions.

User wound up paying 3 mil for IT to rewrite the app (and, at IT's insistence,
add web access) - only to have to scrap the rewrite and go to another outside
vendor to do it all over again.

If they'd just bought into an SQL Server back end in the first place, I have no
doubt they would still be running that application.
--
PeteCresswell
Mar 22 '07 #4

P: n/a
Is it true then that there is absolutely no way to control the
corruption issues that are relevant to an MDB babckend? That is to
say, that we are unable to detect and correct for these issues via
code, except perhaps by quite literally have a front end re-create the
backend and import the last / most recent set of data backups?

I was also looking into the possible elimination of corruption
conditions, but have found this an extremely difficult task to pin
anything down except certain environmental factors (with the help of
many postings here in this newsgroup). I am curious if anyone has had
any success with "correcting" corruptions from a front end without
having to do the whole make-a-new approach. Any takers?

The Frog

Mar 23 '07 #5

P: n/a
>From: "Tony Toews [MVP]" <tto...@telusplanet.net>
>
I'm not quite clear on how you can be in the design mode of a table and edit a
record. Do you mean datasheet mode?
Yes, I misspoke. I should have said datasheet mode.

On Mar 23, 8:36 am, "The Frog" <andrew.hogend...@eu.effem.comwrote:
Is it true then that there is absolutely no way to control the
corruption issues that are relevant to an MDB babckend? ...I am curious if anyone has had
any success with "correcting" corruptions from a front end without
having to do the whole make-a-new approach. Any takers?
Hey Frog:

I found several references (some from MS) stating that:

"(3) Executing the 'Compact and Repair' options inside an Access
database
regularly is recommended as a procedure to prevent corruption. This
should
certainly be executed every week for a database that is being used
daily. "

ACC2000: How to Troubleshoot/Repair a Damaged Jet 4.0 Database
(Q209137)
http://support.microsoft.com/default...;EN-US;q209137

That isn't exactly "using code", but it's the only thing I've found
that even begins to address this.

Other excerpts from that KB article:

"In most cases, database corruption is *not* the result of poor
programming
techniques or sloppy design." (emphasis added)

(4) Avoid mixing operating systems in a multi-user environment. For
example, Windows 98 with Windows 2000.

(6) When designing the database tables it is prudent to be sensible
about
the number of fields per table. As a general indicator, most tables
should
contain no more than 25 fields.

(7) Consider disabling opportunistic locking on the file server it is
Windows NT or Windows 2000 based.


Mar 23 '07 #6

P: n/a
"Doug" <sp*******@gmail.comwrote in
news:11**********************@y80g2000hsf.googlegr oups.com:
In addition, I thought that if I abnormally exited the program
(CTRL- ALT-DEL and kill the process while the program is loading,
etc.), that there would be a very good chance of corrupting the
DB. Especially (only?) if you killed it while it was accessing a
record, before it closed a recordset, etc.
If it's in edit mode it's much more likely. Have two users (or two
instances of Access on the same machine) edit a memo field
simultaneously, and kill one or both instances of Access and you've
got a pretty good chance of corrupting the records (though not
necessarily the database). You don't even have to kill Access to
make it happen with the memo fields.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 23 '07 #7

P: n/a
"Tony Toews [MVP]" <tt****@telusplanet.netwrote in
news:s8********************************@4ax.com:
What might work is running a SQL query updating a few thousand
records and powering off the system abruptly.
Or running a massive append and killing the process in the middle of
the append.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 23 '07 #8

P: n/a
"Doug" <sp*******@gmail.comwrote in
news:11**********************@n59g2000hsh.googlegr oups.com:
I found several references (some from MS) stating that:
In my experience, since A2K was released, the biggest cause of
corruption is bad versions of Jet and Access. I've had only one
hardware problem (which didn't result in corruption) with Access
since about 2000, and that was with an A97 application.

But with A2K and higher, clients have had more corruption, maybe 1
client a year. One of my clients using A2K had problems when one
workstation got reverted to the release version of A2K -- that's
almost guaranteed to cause problems.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 23 '07 #9

P: n/a
pks
On Mar 23, 7:36 am, "The Frog" <andrew.hogend...@eu.effem.comwrote:

.. . .
>
I was also looking into the possible elimination of corruption
conditions, but have found this an extremely difficult task to pin
anything down except certain environmental factors (with the help of
many postings here in this newsgroup). I am curious if anyone has had
any success with "correcting" corruptions from a front end without
having to do the whole make-a-new approach. Any takers?
Frog,

I had a client with about 40-50 users (maybe 35 concurrent) that had
an ongoing problem with corruption. After trying everything that I
could come up with (and a big THANK YOU to this NG), I was left with
intermittent network issues. We then set them up with a Terminal
Server with the BE on the TS and a copy of the FE in each user
profile's desktop, with all users accessing the DB via TS even though
they were in the same office. With the DB network traffic eliminated,
the corruption issue stopped. Even with 2 users accessing the DB
across the network instead of via TS (one occasional and one heavy
user), we had no more corruption.

It worked great until about 6 months ago when the corruption problem
returned, although not as severe. Come to find out that they added a
second TS for users on another floor, and that TS was connecting to
the DB over the network. We haven't gotten anywhere yet with moving
those users to the original server, but with running a compact/repair
2-3 times per week, the corruption is minimal although it still
happens.

FWIW.

Mar 23 '07 #10

P: n/a
Per David W. Fenton:
>What might work is running a SQL query updating a few thousand
records and powering off the system abruptly.

Or running a massive append and killing the process in the middle of
the append.
How about opening up the .MDB in a text editor like SPF and overtyping and/or
deleting a few characters?
--
PeteCresswell
Mar 23 '07 #11

P: n/a
Per The Frog:
but have found this an extremely difficult task to pin
anything down except certain environmental factors
The only one that I was able to find/fix was a bad NIC in one of the user's
machines.
My fallback position in a "mystery" situation is a .BAT file that runs every
night and keeps many, many (like a hundred...) copies of the back end.

The main rationale is that a DB can come up corrupted on day 1 and users can
open it on days 2, 3, 4, 5 and so-forth; find it's corrupted; mutter a few harsh
words; and jut get on with other work without telling anybody about it.

On each one of those days, another bad copy goes into the LAN backup scheme and
eventually the last good copy falls off the end of the process.

There are also scenarios where a .MDB becomes partially corrupted. It still
works, but it gets goofey under some circumstances and/or various tables aren't
right anymore but still function - and the DB gives no programmatic indication
of it's state when opened. In that scenario, a DB can go even longer without
being identified as corrupt.

--
PeteCresswell
Mar 23 '07 #12

P: n/a
"(PeteCresswell)" <x@y.Invalidwrote in
news:rb********************************@4ax.com:
Per David W. Fenton:
>>What might work is running a SQL query updating a few thousand
records and powering off the system abruptly.

Or running a massive append and killing the process in the middle
of the append.

How about opening up the .MDB in a text editor like SPF and
overtyping and/or deleting a few characters?
Or opening it in Word.

But that's not realistic corruption -- it's going to be random
corruption. The other methods produce corruption that is made in the
process of Access attempting to maintain internal data structures.
And much of that will be recoverable. One byte out of place at the
top of an MDB file could perhaps wreck everything.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 23 '07 #13

P: n/a
"(PeteCresswell)" <x@y.Invalidwrote in
news:ge********************************@4ax.com:
My fallback position in a "mystery" situation is a .BAT file that
runs every night and keeps many, many (like a hundred...) copies
of the back end.
The one client of mine that's had corruption in the last year (and
who also has a very large data file with 3 tables each having 100s
of thousands of records) runs the FMS Agent overnight. It archives
into a zip file, and keeps as many back copies as you choose, and
then compacts the MDB. It was very helpful to me in troubleshooting
one of my *owh* errors earlier this week, as I was able to go back
and look at data before I'd made the fatal change and after, and
thus track down the cause (a big finger pointing back at myself!).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 23 '07 #14

P: n/a
Another part of the problem is that the application is used 24x7x365,
so to compact/repair, I need to kick users out of the system.

It's just that I *really* have this feeling that the corruption is
caused by people starting up the program (which takes a LONG time),
then deciding "You know what? I don't have time for this..." and they
give it the "3-Fingered Salute".

Mar 26 '07 #15

P: n/a
Doug, to test that theory, and possibly track down the culprit
hardware/user(s), consider logging users into and out of the database.

Those that log in but don't log out are suspect.

(The other factor might be to identify why it takes so long to start up, and
fix that problem.)

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Doug" <sp*******@gmail.comwrote in message
news:11**********************@l75g2000hse.googlegr oups.com...
Another part of the problem is that the application is used 24x7x365,
so to compact/repair, I need to kick users out of the system.

It's just that I *really* have this feeling that the corruption is
caused by people starting up the program (which takes a LONG time),
then deciding "You know what? I don't have time for this..." and they
give it the "3-Fingered Salute".
Mar 26 '07 #16

P: n/a
Per Doug:
>Another part of the problem is that the application is used 24x7x365,
so to compact/repair, I need to kick users out of the system.

It's just that I *really* have this feeling that the corruption is
caused by people starting up the program (which takes a LONG time),
then deciding "You know what? I don't have time for this..." and they
give it the "3-Fingered Salute".
Sounds like a textbook case for moving the back end over to SQL Server.

Anybody else agree?
Any idea why it takes so long to start up? Might be some other issues there...
--
PeteCresswell
Mar 26 '07 #17

P: n/a
In light of what has been discussed in this topic I would have to
agree with the move to SQL server. A 24/7/365 needs a bit more
reliability than a JET back end can supply it seems. It simply may not
be worth the effort of running down the culprits when you can get a
free version of SQL Server Express and eliminate the problem as well
as a number of other benefits that SQL Server comes with.

I too am interested in the corruption issues, but it seems that
despite the best efforts of some of the most experienced people here
that it isnt actually possible to eliminate the problems, or even
necessarily detect and correct them! Lets face it, MDB files are a
good desktop database to work with, but for mission critical you
really need to move to something that gives you the stability you
need.

I would have to agree with Pete. Though I am not as experienced as
some here, and they may be able to come up with alternatives to
solving your problem, I would tend to think that 24/7/365 means shift
it to something that can operate 24/7/365 and be done with the
headaches.

The Frog

Mar 26 '07 #18

P: n/a
"(PeteCresswell)" <x@y.Invalidwrote in
news:86********************************@4ax.com:
Per Doug:
>>Another part of the problem is that the application is used
24x7x365, so to compact/repair, I need to kick users out of the
system.

It's just that I *really* have this feeling that the corruption is
caused by people starting up the program (which takes a LONG
time), then deciding "You know what? I don't have time for
this..." and they give it the "3-Fingered Salute".

Sounds like a textbook case for moving the back end over to SQL
Server.

Anybody else agree?
Well, the startup issues aren't, but the 24/7 requirement certainly
is.
Any idea why it takes so long to start up? Might be some other
issues there...
Obviously if you've designed your app so that it takes so long to
load that users give up, it's *your* fault if they are corrupting
the database by killing the process. The easiest way to fix it is
judicious use of DoEvents so that something happens onscreen
periodically to tell them that the app is loading. I recently added
an unnecessary splash screen with 'Please wait while program loads"
before the switchboard comes up (when previously the the blank
Access window was all that was visible), and the users said "Oh!
You've done something to speed up the load time!" Nothing actually
changed behind the scenes -- all that changed was what users were
seeing, and it made them feel like the app was loading more quickly.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 26 '07 #19

P: n/a
Per The Frog:
but it seems that
despite the best efforts of some of the most experienced people here
that it isnt actually possible to eliminate the problems, or even
necessarily detect and correct them!
I had a similar experience when my worst-case corruption scenario was going on:
beeeeeeg mutual fund, extremely sophisticated LAN people, the latest tools....
and nobody could pinpoint the problem.
--
PeteCresswell
Mar 26 '07 #20

P: n/a
"Doug" <sp*******@gmail.comwrote
Another part of the problem is that the
application is used 24x7x365, so to
compact/repair, I need to kick users
out of the system.
I think you would be hard-pressed to find a recommendation from the product
team or any MVP that Access is suitable for a 24x7x365 (certainly falls in
the category of "mission critical") application -- file-server databases
weren't designed for that, weren't intended for it, and aren't good in that
role.

Most of us are strong believers in "appropriate technology" and neither
Access nor Jet are "appropriate technology" for that kind of application.

Larry Linson
Microsoft Access MVP
Mar 26 '07 #21

P: n/a
Per Larry Linson:
neither
Access nor Jet are "appropriate technology" for that kind of application.
Would that caveat extend to MS Access as a front end to an SQL Server DB - or is
it just for the back end?
--
PeteCresswell
Mar 27 '07 #22

P: n/a
"(PeteCresswell)" <x@y.Invalidwrote
>neither Access nor Jet are "appropriate technology"
for that kind of application.

Would that caveat extend to MS Access as a front end
to an SQL Server DB - or is it just for the back end?
Access should be just fine as a _client_ to SQL Server or other server DB,
provided the Access client is carefully designed so that it can just be
replaced in case of bloat or corruption. Executing certain Queries can
cause bloat, as well as what we think of as "normal" causes of bloat --
deleting Records or objects from the Access DB.

If the Access client will ever need to be compacted or repaired, it would
not be suitable -- and some people do try to keep user-specific data in the
Access client. Compacting and repairing means that it will be "off-line" for
some period, and that is not consistent with 24/7/365 operation. If there is
user-specific data, then another database with linked tables, on the local
machine or LAN, should be used rather than storing the user-specific data in
the front-end/client.

24/7/365 is a demanding requirement; in a previous incarnation as a
mainframer, such systems were often duplicated and switched to the backup
machine/system when maintenance (software or hardware) was required on the
production machine. Similar things are done with clusters of servers and
banks of drives, these days.

Larry Linson
Microsoft Access MVP
Mar 27 '07 #23

P: n/a
"Larry Linson" <bo*****@localhost.notwrote in
news:a%XNh.2870$yo3.1181@trnddc04:
Most of us are strong believers in "appropriate technology" and
neither Access nor Jet are "appropriate technology" for that kind
of application.
Access is a perfectly appropriate technology for building a front
end for that kind of application. Why would you suggest otherwise?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 27 '07 #24

P: n/a
"Larry Linson" <bo*****@localhost.notwrote in
news:Qj_Nh.6444$vI1.709@trnddc02:
If the Access client will ever need to be compacted or repaired,
it would not be suitable -- and some people do try to keep
user-specific data in the Access client. Compacting and repairing
means that it will be "off-line" for some period, and that is not
consistent with 24/7/365 operation. If there is user-specific
data, then another database with linked tables, on the local
machine or LAN, should be used rather than storing the
user-specific data in the front-end/client.
I strongly doubt that the 24/7 requirement applies to the client.

And any front end that is storing data that is not static is
wrongly-designed.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Mar 27 '07 #25

P: n/a
I have used MS Access as a client with various database servers as the
backend, such as SQL Server and Oracle. The designs have been
successful with both linked tables and just using ADO for all the
heavy lifting. I have to say that I prefer SQL Server to Oracle though
- but thats a personal taste thing.

The only thing that I suppose I found to be a rule with this type of
thing, as it is with all dveleopment, is to make sure that the code is
robust and reliable, and that the forms are user friendly. The goal in
my case is always to facilitate workflow processes and to make the
users lives easier. A lot of the time is designing, as I have found,
goes into understanding the workflow and the expectations of the
users. Long load times? - then change the way the application appears
to load. Long query wait times? - perhaps some sort of pre-aggregated
tables to speed things up. And so on.... There are lots of different
problems and lots of different solutions. One of the reasons I love
this newsgroup :-)

Cheers

The Frog

Mar 27 '07 #26

P: n/a
We are re-writing the application with a dotNET front end and a SQL
Server back end.

I am just trying to test my hypothesis about the MDB corruption.

Thanks for all the input.

Apr 3 '07 #27

P: n/a
"Doug" <sp*******@gmail.comwrote:
>We are re-writing the application with a dotNET front end and a SQL
Server back end.
Good luck. Hope you have a nice sized budget. Any estimate on how much longer the
same app will take in .NET?

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
Apr 4 '07 #28

P: n/a
Per Doug:
>We are re-writing the application with a dotNET front end and a SQL
Server back end.
Do you have good numbers on how much it cost to write the original app?

If so, it would be nice tb able to compare the new version's cost once it's
done.
--
PeteCresswell
Apr 4 '07 #29

P: n/a
MDB is not reliable enough for a single-user application

lose the training wheels; you MDB kids are con artists
-Susie
On Mar 26, 6:26 pm, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
"Larry Linson" <boun...@localhost.notwrote innews:a%XNh.2870$yo3.1181@trnddc04:
Most of us are strong believers in "appropriate technology" and
neither Access nor Jet are "appropriate technology" for that kind
of application.

Access is a perfectly appropriate technology for building a front
end for that kind of application. Why would you suggest otherwise?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Apr 5 '07 #30

P: n/a
rewriting a moderately complex MDB applicatino to SQL Server should
take a week. TOPS.

it is worth it for every every every situation
you should be using ADP instead of VB.net _CRAP_ though

ADP is a lot more cost efficient


On Apr 3, 5:55 pm, "(PeteCresswell)" <x...@y.Invalidwrote:
Per Doug:
We are re-writing the application with a dotNET front end and a SQL
Server back end.

Do you have good numbers on how much it cost to write the original app?

If so, it would be nice tb able to compare the new version's cost once it's
done.
--
PeteCresswell

Apr 5 '07 #31

P: n/a
MDB corruption is random

MDB can't be run over WAN, VPN, Wireless, Etc
ADP works great everywhere

Note that Tony Toews is a MDB _WUSS_ and should not be trusted for
anything.

It's like going to ask a 1st grader for financial advice
ADP uber alles!

Apr 3, 4:36 am, "Doug" <spamwo...@gmail.comwrote:
We are re-writing the application with a dotNET front end and a SQL
Server back end.

I am just trying to test my hypothesis about the MDB corruption.

Thanks for all the input.

Apr 5 '07 #32

P: n/a
MDB is not useful for anything other than bloat
just use Access Data Projects; you can use a simple SCHEDULED
'Database Maintenance Wizard' in order to prevent problems; and it
won't prevent 24x7x364 usage


On Mar 26, 5:23 pm, "(PeteCresswell)" <x...@y.Invalidwrote:
Per Larry Linson:
neither
Access nor Jet are "appropriate technology" for that kind of application.

Would that caveat extend to MS Access as a front end to an SQL Server DB - or is
it just for the back end?
--
PeteCresswell

Apr 5 '07 #33

P: n/a
re:
before it closed a recordset
DAVID
are you really still dealing with the DAO memory leak _CRAP_?

ADO you don't need to close jack shit; things go out of scope and it
works like it shoudl.

MDB and DAO have a ton of unnnecessary overhead-- for developers and
end users


On Mar 23, 6:18 am, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
"Doug" <spamwo...@gmail.comwrote innews:11**********************@y80g2000hsf.google groups.com:
In addition, I thought that if I abnormally exited the program
(CTRL- ALT-DEL and kill the process while the program is loading,
etc.), that there would be a very good chance of corrupting the
DB. Especially (only?) if you killed it while it was accessing a
record, before it closed a recordset, etc.

If it's in edit mode it's much more likely. Have two users (or two
instances of Access on the same machine) edit a memo field
simultaneously, and kill one or both instances of Access and you've
got a pretty good chance of corrupting the records (though not
necessarily the database). You don't even have to kill Access to
make it happen with the memo fields.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Apr 5 '07 #34

P: n/a
wow David

I would be really really impressed-- but from my recollection of
Access 97? it crashed / corrupted ALL THE FRIGGIN TIME
so what you're saying is 97, 2000 and anything newer than 2000 is
subject to constant corruption?

why don't you use Access Data Projects, kid?

On Mar 23, 6:22 am, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
"Doug" <spamwo...@gmail.comwrote innews:11**********************@n59g2000hsh.google groups.com:
I found several references (some from MS) stating that:

In my experience, since A2K was released, the biggest cause of
corruption is bad versions of Jet and Access. I've had only one
hardware problem (which didn't result in corruption) with Access
since about 2000, and that was with an A97 application.

But with A2K and higher, clients have had more corruption, maybe 1
client a year. One of my clients using A2K had problems when one
workstation got reverted to the release version of A2K -- that's
almost guaranteed to cause problems.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Apr 5 '07 #35

P: n/a
"Susie DBA [MSFT]" <su******@hotmail.comwrote in
news:11**********************@q75g2000hsh.googlegr oups.com:
why don't you use Access Data Projects, kid?
1. Because they create a gaping security flaw?
2. Because they use multiple connections and the nature and number of these
connections is undocumented and cannot be predicted or managed?
3. Because the use of SQL-Server application roles with ADPs is
undocumented, arcane and approaches the paranomral?
4. Because it seems that MS has abandoned ADPs?
5. All of the above?

--
lyle fairfield

Ceterum censeo Redmond esse delendam
Apr 5 '07 #36

P: n/a
Per Susie DBA [MSFT]:
>rewriting a moderately complex MDB applicatino to SQL Server should
take a week. TOPS.

it is worth it for every every every situation
you should be using ADP instead of VB.net _CRAP_ though
Sounds like you're talking about the back end as opposed to the front end.

To me, a "moderately-complex" application runs somewhere between 400 and 600 man
hours.
--
PeteCresswell
Apr 6 '07 #37

P: n/a
Doug, this looks like a fairly reliable way to corrupt an Access database:
http://support.microsoft.com/?kbid=935370

Requires a couple of Windows Vista or Longhorn Server machines.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Doug" <sp*******@gmail.comwrote in message
news:11**********************@y80g2000hsf.googlegr oups.com...
>I am in a friendly debate with some co-workers... and my boss.
[snip]
Apr 13 '07 #38

P: n/a
"Allen Browne" <Al*********@SeeSig.Invalidwrote in
news:46***********************@per-qv1-newsreader-01.iinet.net.au:
Doug, this looks like a fairly reliable way to corrupt an Access
database:
http://support.microsoft.com/?kbid=935370

Requires a couple of Windows Vista or Longhorn Server machines.
The key issue there seems to be SMB 2.0. Isn't there some way in
Vista to turn that off? I vaguely recall some report of a problem
with that in Access before. Anyone?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 13 '07 #39

P: n/a
"David W. Fenton" <XX*******@dfenton.com.invalidwrote:
>Doug, this looks like a fairly reliable way to corrupt an Access
database:
http://support.microsoft.com/?kbid=935370

Requires a couple of Windows Vista or Longhorn Server machines.

The key issue there seems to be SMB 2.0. Isn't there some way in
Vista to turn that off? I vaguely recall some report of a problem
with that in Access before. Anyone?
Yes, SMB 1.0 was a problem in the past although it only affected performance.
See the Disable Server Message Block (SMB) Signing section at
http://www.granite.ab.ca/access/performancefaq.htm

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
Apr 13 '07 #40

P: n/a
"Tony Toews [MVP]" <tt****@telusplanet.netwrote in
news:h7********************************@4ax.com:
"David W. Fenton" <XX*******@dfenton.com.invalidwrote:
>>Doug, this looks like a fairly reliable way to corrupt an Access
database:
http://support.microsoft.com/?kbid=935370

Requires a couple of Windows Vista or Longhorn Server machines.

The key issue there seems to be SMB 2.0. Isn't there some way in
Vista to turn that off? I vaguely recall some report of a problem
with that in Access before. Anyone?

Yes, SMB 1.0 was a problem in the past although it only affected
performance. See the Disable Server Message Block (SMB) Signing
section at http://www.granite.ab.ca/access/performancefaq.htm
Er, SMB is the name for the entire Windows networking subsystem.
When you're using NETBIOS, it's SMB networking. The "Signing" issue
is a feature of SMB, not the whole thing.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 14 '07 #41

P: n/a
"David W. Fenton" <XX*******@dfenton.com.invalidwrote:
>>>The key issue there seems to be SMB 2.0. Isn't there some way in
Vista to turn that off? I vaguely recall some report of a problem
with that in Access before. Anyone?

Yes, SMB 1.0 was a problem in the past although it only affected
performance. See the Disable Server Message Block (SMB) Signing
section at http://www.granite.ab.ca/access/performancefaq.htm

Er, SMB is the name for the entire Windows networking subsystem.
When you're using NETBIOS, it's SMB networking. The "Signing" issue
is a feature of SMB, not the whole thing.
Ah, I got confused. Thanks for the clarification.

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
Apr 15 '07 #42

P: n/a
"Tony Toews [MVP]" <tt****@telusplanet.netwrote in
news:8p********************************@4ax.com:
"David W. Fenton" <XX*******@dfenton.com.invalidwrote:
>>>>The key issue there seems to be SMB 2.0. Isn't there some way in
Vista to turn that off? I vaguely recall some report of a
problem with that in Access before. Anyone?

Yes, SMB 1.0 was a problem in the past although it only affected
performance. See the Disable Server Message Block (SMB) Signing
section at http://www.granite.ab.ca/access/performancefaq.htm

Er, SMB is the name for the entire Windows networking subsystem.
When you're using NETBIOS, it's SMB networking. The "Signing"
issue is a feature of SMB, not the whole thing.

Ah, I got confused. Thanks for the clarification.
It is, of course, why SAMBA is called SaMBa.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 15 '07 #43

This discussion thread is closed

Replies have been disabled for this discussion.