"David W. Fenton" wrote in message

And very much appreciated, David.

My experience (of taking over unsplit databases) is limited to one in A2.0 (a
point-of-sale critical one for a retail outlet). There were no problems at all
(that is, there were plenty of problems, but none directly attributable to
being unsplit, or let's say I never proved such!)(it was split, for a reason
you would need to ask the deceased Batchelor of Engineering programmer, who
taught me a thing or two otherwise, by functions ie departments)

Since I don't write unsplit databases, my experience of that is naturally
limited. Slightly related, is that I HAVE run an A97 database, Front-End
SHARED on a server amongst 1/2 doz. NO PROBS. I don't recommend it, I just did
it on one site for the hell of it (and easier during initial "volatile"
development!)

Of course, you mentioned a big change after A97 (ie A2000 onwards). So far as
I've read, that's to do with the bad practice of modifying a design on-line ie
whilst live (barely possible, and thinks: where are the backups even if
possible?) But this is the first I can recall reading that such causes
"corruptions" (as distinct from just whilst trying to modify the design of a
live database!)

And whilst we're at it, let's mention (with the greatest respect and interest,
no sarcasm), Tom Wickerath backed up by posts from Peter Miller, that memo or
large object fields are apparently more prone to corruptions because the
actual data is contained on the "heap". That may be so. Some of my programs
are 90% memo fields, for reasons which are irrelevant here (well, because my
program is so general-purpose that it doesn't put any operator-limit within
reason), and, I claim, I suffer corruptions like anyone but not so much as,
for instance, Tom would claim experience of!

So. Are the untoward corruptions because they were unsplit, or split but
shared FE, or had too many memo fields, or were running A2000 or later, or on
a WAN, or whatever else you say it suffered from? You must be very old to have
experience of all of them!

(My most memorable anecdotal experiences of corruption is this: one or several
of my customers starts experiencing them perhaps daily, but no others do so
it's not the program or "layout" per se. It's...it's...never provable but
either a) they have a bad operator who aborts out of the program b) a subtly
corrupted FE or BE which nevertheless passes all tests c) a bad network or
errant PC or something. Anyway, I solved those sites through no fault of my
own, eventually they stabilised, so they either fired the errant personnel,
changed their computer or network, and I never did find out why they
stabilised because they were remote sites so I couldn't analyse it even if I
knew how. They already had all the std Access layout recommendations. Perhaps
some of the PC's weren't SP'd, but anyone claiming experience would at least
know that asking by telephone results in "honest lies". :-)

Now, I don't for a moment recommend unsplit, (Tony Toews came up with the only
interesting reason), and neither do I read does Ed. But at the same time, it
seems to be the least of my worries. Are you saying the sites you took over
were suffering from corruptions which you solved by splitting? Did anything
else change concommitant with those changes which might have relevance? (eg
did you improve the code as well or PC's or network or something?) It is sooo
easy to be misled, including myself of course. Such as blaming corruptions on
unsplit with no adequately controlled experiment. Anecdotal evidence I
ackowledge as important however, because I have no direct evidence either way
either. If you do, then you haven't presented it beyond a generality.

My purpose, is that this stuff worries me, as I'm sure it does all Access
programmers, and that is all I mean.
Chris :-)