bcap said:
No you haven't, at least not here.
That is possibly correct, though without researching (which would be a waste
of time), I really thought that it was in this newsgroup that I had done so
in response to aaron. I know I recently did so in a private forum -- you
might well have rejected what I wrote, or "dismissed it with a wave of your
hand as being so trivial as not to matter" as you seem to be doing here by
classifying "adminstrative work" as "setup".
That's just absurd Larry. SQL Server even in simple recovery mode is
superior to an mdb back-end by virtue of the fact that it simply never goes
wrong and requires *no* maintenance (or, more accurately, it will
automatically maintain itself if you set it up so to do).
I'm sorry, but I it quite reasonable to doubt that there is a software
product which "simply never goes wrong". And, you may be so brilliant at
what you do that _you_ can set up an SQL Server installation to minimize
maintenance, but I've seen any server DB set up the way you describe, with
"no maintenance ever required." Perhaps that's because I've never had
occasion to work with a database sufficiently simple (dare I say "trivial")
that it used a server DB when one was not needed.
Now, perhaps, we are getting down to "brass tacks" when you say "if you set
it up so to do". That's a key issue (about which I will have more to say,
below).
. . . but really all you need to do is to write the T-SQL and launch it
with the Windows task scheduler instead. Only needs doing once, then it's
transferrable to every server you install. . . .
It also takes a bit more work to set up with the full recovery model, but
it's not that difficult and it can be automated. It's also hardly a reason
to claim that it would be better to use an mdb - after all, it's a kind of
recovery that isn't even possible with an mdb. .. . .
Even in simple recovery mode you can easily set it up to backup at intervals
*during* the working day - you can't do that with an mdb without risking the
backups being corrupt.
. . .
. . . Set it up once, set it up right, and it's then capable
of running for *years* untouched by human hand.
. . .
I can't speak to the competence of the people who set up those servers, I
can only speak of my own experience, which is that (i) not a single one of
my customers employs anyone who is even minimally trained in any aspect of
SQL Server and (ii) their systems run for years without any database
administration being required *at all*. My customers are comfortable with
that...
Ah, but your customers employed _you_. Perhaps we differ between "setup
right" and "administration". You've described some items of "setup" which I
might describe as "administration", and certainly non-trivial
administration, at that.
It's a non-decision for me, but I'm not here to give an Aaron-esque
recommendation that everyone use SQL Server, I'm merely pointing out that
you made an incorrect statement. . . .
Adequate? Sure. Requiring less administration? See above... .. . .
As I've already said, when set up right for minimal maintenance a SQL Server
back-end will usually require *no* administration effort, so there's nothing
to downplay! Sure you need to learn about it in the first instance (become
"accustomed" if you will), but that's true of *every* tool and
technology.
If not most, certainly "many" of the people who implement Access databases
do not remotely have the kind of experience and server talent to set up what
you describe. Certainly few of them will know, and many will not want to
pursue a database career by learning, "T-SQL", for example, and other
"mysteries of the MS SQL Server world". Most of them, in my experience, are
doing so as an adjunct to the primary purpose of their jobs, and, only some
become so enamored as to pursue it as a "calling".
I've been in the computer business a long time, and have been able to
identify a few devious fakers, and I did not get the impression that my
clients' DBAs were either deviously deceiving their employer or incompetent.
I suspect that they just "aren't in your class". (And from aaron's
often-content-free responses, I suspect he is not nearly in your class,
either.
It also takes a bit more work to set up with the full recovery model, but
it's not that difficult and it can be automated. It's also hardly a reason
to claim that it would be better to use an mdb - after all, it's a kind of
recovery that isn't even possible with an mdb.
I mentioned that because it is one of the valid reasons to use a server
DB... and, yes, of course, I, too recommend server DBs for reliability and
recovery. On the issue of reliability, I first recommend that they
stabilize their network. On one project, reliability was abominable; in a
few weeks, not due to my perceptions (I was there for specialized tasks
including some security additions), the company replaced the entire
department of network people ("network nuts" in the parlance of the
programmers in that shop), and the improvement in reliability was soon in
the "amazing" category.
I have, however, because I had explained, the customer did not want to go
with a server, and did want some backup and recovery, implemented a backup
arrangement that recorded transactions, including generational backup, and
would play back the transactions into the system to bring it up to date from
the last "good" backup. Would they have been better off with a server?
Possibly. Would they have been as well off with no backup/recovery?
Possibly, but they slept better with it. As far as I know, in the next few
years, they never had an "incident" that caused them to have to use it.
Oh, too, I have this nagging feeling that, if it had been reasonable to
build in automated "setup" as you describe, that the default database of
Access would be one of the free editions of SQL Server, yet, Microsoft opted
to create a next generation descended from Jet, not MSDE, not SQL Server...
the ACE database engine, and ACCDB/ACCDE databases of Access 2007. It would
surely have been less costly for Microsoft to maintain one common "little
SQL Server" than one of those plus "ACE, a new generation of Jet".
Larry Linson
Microsoft Office Access MVP
