Larry Linson said:
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".
I haven't seen what you wrote, and I'm not going Googling for it.
Setup is setup, I do it for my clients, as I said before it would typically
take me 15-30 minutes. I did another one just last week. I'm not going to
throw away the many benefits of using SQL Server just to save that 15-30
minutes. Anyway, if I delivered an mdb back-end it's probably about the
same amount of time I would take training them to compact the thing.
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.
Fair enough, that was a touch of hyperbole, of course nothing is completely
failure-proof, but I can say that no SQL Server I have set up in the last 10
years has ever let me down.
As for your attempted insult regarding "trivial" databases, I guess it
depends on your definition of "trivial", but I don't propose to get into a
pissing contest with you over it. Anyway, for me the question is not "is
SQL Server needed?" but rather "why not use SQL Server?"
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 may be non-trivial to figure out what to do in the first place, and like
most things (including Access) one learns and refines things with
experience. Not knowing one's way around SQL Server, and lacking the
time/inclination/ability to learn, is a perfectly valid reason for not using
it, but that doesn't validate your original (incorrect) statement that SQL
Server requires more administration. You would seem to be complaining that
because someone hasn't learned to use a technology then there is something
wrong with the 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".
Undoubtedly. As I said, I'm not make a sweeping recommendation that
everyone (or indeed anyone other than me) should use SQL Server.
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.
Well I've been in the computer business a long time too (a hell of a lot
longer than the boy Kempf, though possibly not as long as you) and my
opinion is that most "administrators" (network, DB or whatever) add little
value and struggle to justify their salaries.
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.
You can stabilise the LAN as much as you like but you are still stuffed as
soon as someone wants to go wireless or run it client-server from home.
Doubtless you would say "why incur the overhead for something that might
never be required?" to which I reply, again: "What overhead?" Certainly
I've been in situations where the customer has suddenly decided to do
something that wasn't in the original brief and yet, because I chose to go
with SQL Server from day one, I've been able to say "no problem". Doubtless
I could have made more money by delivering an mdb in the first instance and
then charging them for an upsizing project, but I'm not like that.
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.
Maybe the customer would have been perfectly happy to go client-server if
someone had explained that it's no big deal. 'Twould certainly have been a
hell of a lot less effort (and cost) than the implementation you describe (I
assume you are describing some kind of logging implemented in Access
events).
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
Who knows what goes on in the minds of the strategic thinkers at Microsoft?
