Re: Script for your enjoyment
From: Al Dunbar [MS-MVP] (alan-no-drub-spam_at_hotmail.com)
Date: 08/05/04
- Next message: Al Dunbar [MS-MVP]: "Re: Script for your enjoyment"
- Previous message: Richard Bell: "Internet Explorer and Memory"
- In reply to: CobolExpert: "Re: Script for your enjoyment"
- Next in thread: Al Dunbar [MS-MVP]: "Re: Script for your enjoyment"
- Reply: Al Dunbar [MS-MVP]: "Re: Script for your enjoyment"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 4 Aug 2004 19:27:19 -0600
"CobolExpert" <CobolExpert@discussions.microsoft.com> wrote in message
news:73563C34-899E-4255-8E0B-A265F17106C7@microsoft.com...
<snip>
> > For this reason, your code should be prepared to handle copy errors.
And, if
> > it does that, what is the additional value of pre-testing, when it is
not
> > provably accurate 100% of the time? You won't save any time, as copying
> > without a pretest is going to be faster if the file is available. If not
> > available, the delay would be about the same.
>
> I totally disagree with your opinion. The additional value is knowing who
is using the file instead of just getting an error and going and having to
go check it yourself.
Another environment specific aspect (sorry). I do not maintain any databases
that need backing up or updating and which must not be open for this to
happen. And any files I happen to copy to people's personal folders or
workstation profiles are not critical. If they fail because the file is
open, they will succeed the next time.
Given that you are interested in finding out who has the database open, what
do you do with that information? Do you go to their workstation and log them
off? Phone or e-mail them to ask them to close the file?
I do not disagree with your opinion, as the value of the opinion depends on
the environment it is made in. My opinion is apparently not applicable in
your environment, but it works in my own.
> Saving time or not is a priority but it shouldn't over take the
priority of doing this correctly.
Given that I was not intending that it be done incorrectly, I agree with you
completely on the above point.
> You shouldn't have to hope that fifteen people aren't using the file
and you shouldn't have to go open up Computer Management to take a look.
The script should do that for you.
In your environment you need this, in mine I don't. Should I ever be in the
position of having to track down more than one or two file users through MMC
I will certainly look for a scripted solution.
>
> This is a long the same lines as another post I saw in here (or somewhere
else) awhile back. Someone asked something to the effect of "why the hell
isn't anyone checking if a domain group exists before they add it". The
answer was something like "Because if it exists, you'll get an error".
While that may acceptable to some people, that is not acceptable to me.
I understand why it is unacceptable to you in the specific case of your
databases - mainly because you need to know more than just "can I copy this
file now"? In the case of the domain group, however, the effect on the
domain of attempting to create a group that already exists is nill, so this
is not necessarily a problem.
The thing to realize is that an "error" is not a "mistake". An "error" in
scripting could be compared with the concept of "false" in the "true/false"
boolean logic area. And logically speaking, it is much easier (and more
rigorously complete) to determine the possibility of doing something by
trying and then testing for success (but only when the failure itself would
not be catastrophic) than by trying to analyze all of the individual factors
that could possibly contribute to failure.
> It's the equivalent of assuming and hoping a car has airbags but not
finding out until you hit a tree going 60. If you checked the damn thing
before hand, you would know it didn't and you wouldn't be dead. (Thats a bad
analogy but I'm sure you get the point)
It is a bad enough analogy that, while I get what you are driving at (pun
intended ;-), I disagree. The effect of incorrectly assuming the existence
of airbags could be lethal. As I mention above, the effect of attempting to
create a group that already exists is nowhere near as serious. In fact, it
has no effect on the domain at all.
>
> Saving time is great (in my environment it is but a half second), but not
at the expense of proper scripting which is what I believe this is. Now if
the time to check the folders/files was 30 seconds, 10 seconds, or even 5
seconds... you may have a point. And that may be the case with some old
servers. On the other hand, I think I will still argue that just getting an
error and reporting it is not enough. You need to try to make sure that
error doesn't appear in the first place. Either by having your script check
file usage or by manually doing it yourself.
The time I was thinking about saving also included the time to code the
detailed error detection part. Again, I concede your points in the context
of your database file copying. But whether or not the occurrence of a
particular "error" condition is a mistake depends on how one defines things.
/Al
- Next message: Al Dunbar [MS-MVP]: "Re: Script for your enjoyment"
- Previous message: Richard Bell: "Internet Explorer and Memory"
- In reply to: CobolExpert: "Re: Script for your enjoyment"
- Next in thread: Al Dunbar [MS-MVP]: "Re: Script for your enjoyment"
- Reply: Al Dunbar [MS-MVP]: "Re: Script for your enjoyment"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
