Selection date question
Lerebours, Jose
Jose.Lerebours at EagleGL.com
Mon Feb 21 10:44:14 PST 2005
Gees John, even when I am not offended, you still believe I was.
You tell me to accept and even though I did, you come back doing
the exact opposite, you lynch me for posting my opinion which in
no way was intended to dispute your posting but rather an attempt
to explain my thoughts as I wrote original suggestion.
I accepted and simply expanded on my views. I did admit that your
approach was easier and more elegant and I meant it. Too bad you
believed otherwise. I did say, as I strongly believe, that easier
is not better - There is nothing wrong with that and I am sure you
can agree with it (may be not in this case).
The truth is, that if you put both side by side, my suggestion beats
yours in the long run and I listed some of the reasons why. As you
know, we all face different environments and different business
needs; I try to second guess beyond the post and apply the posted
problem to one of my "real life" scenarios. If you take into
account some of the pointers I mentioned, you should agree that
adding a stamp to records has a lot less breaking points and it is
open to greater expansion than creating the qualifiers.
Heck, isn't qualifier limited to seven characters? If so, what do you
do when two or more users are same up to the 7th character?
It is not about yours is better than mine or mine was better than
yours. At the end, Don will do what best suits his needs. I do not
ever answer a question intending to provide a definitive answer but
open the doors to the possibilities. I posted one legitimate way to
get the job done; one which does not leave a window for potential problems
down the road.
Did I deserve your last post? May be. Some will say "Heck Yeah!" and others
will say "Hell no!" - then again, we are entitled.
As per the political comment, I was just paraphrasing the word you
used "invasive". As you know, it is a politically charged word and it
was not meant to imply that you were bringing politics to the table. I
actually was smiling (as I am now) when I made the reference, too bad
you took it so hard.
Please do not try to put words in my mouth as I have never attempted to
fight with you nor any body on this list over what gets posted and the
quality/accuracy of it. I know my ranking in the filePro community and those
that have worked with me can easily agree. Yes, I rank no where because
it does not matter.
I am not offended. I am not in defense mode. I am not intending to
pick a fight with you nor any body else on this list. However, I stand by
my views!!!
Regards;
Jose Lerebours
> -----Original Message-----
> From: John Esak [mailto:john at valar.com]
> Sent: Monday, February 21, 2005 10:41 AM
> To: Lerebours, Jose
> Cc: filePro mailing list
> Subject: RE: Selection date question
>
>
> > >
> > > John
> > >
> >
> > It is elegant and easier and I take no offense. However, I do
> > believe that easier is not better. I am used to thinking that I
> > will have several hundred users wanting to do the same thing
> > and half the story is what is really known (there is always more
> > to the story) and I rather work a bit harder but do it once.
> >
> > Invasive? Since when a "developer" should concern himself with
> > the feelings of a file when additional fields are needed?
> > You make it sound very political and even suggest that one should
> > stay away from adding fields to a file. This is a temporary
> > processing/holding file we are talking about, not one that will
> > for ever expand on HD usage.
>
> Ridiculous, I made no reference to "political", you just
> did... for what
> reason? Who knows. It does sound very much like you _were_
> offended that
> there was a better "easier" way than yours... even though you
> protest that
> you were not. Instead, you start "flaming". So typical, so
> old, so boring
> and so out-of-step. We are all trying to communicate in the
> exactly the way
> you are not doing by this message... but so be it... here the
> response you
> deserve. Firstly, if someone says the way to add 2+2 together
> is to take the
> square root of 4 and multiply it by itself... and another
> says "I'm sorry,
> that is okay, but I believe I have a better and easier way
> that is more
> elegant... just add 2+2 together... well, it is not the basis
> for a response
> like yours... insulting, rather stupid and non-helpful in its
> "wrongness".
> Pick your battles, Jose, don't try and defend something
> you've done when it
> is not the best and easiest way... don't throw the bullsh#t around...
> especially not here where people know better.
>
> The following items you all list are very "defensive" and
> nothing else... It
> is too bad you didn't even look at the code... which makes
> the indexes, and
> takes care of the other stuff you are talking about...
> Sometimes Jose, it
> would be pretty beneficial to you, I think, if you would just
> say (honestly,
> and without all the rhetoric and defensiveness) "Hey, that's
> a good idea,
> maybe even better than my own!" It would improve your
> overall abilities if
> you take ideas from another once in awhile instead of always
> perceiving that
> your own are the only ones that have merit. As for your
> senseless patter
> about adding fields to a file, and me suggesting that isn't a
> good idea ...
> well, I add fields to files all the time, just as you or
> anyone else.... but
> I only do it when they will be helpful and useful... adding
> this one field
> this one time might do fine, but then what about all the
> other fields and
> all the other times? Are you actually saying that adding
> this one field
> will cover all your reporting needs! Heck, that's one hell of
> a field, mind
> sending me the length and edit type please... I'll see to it
> that it gets
> included in every filePro file from now on... maybe Ken could
> add it as a
> standard. We can call it the Jose field! :-) Your idea is
> only as good as
> you want to believe it is.
>
> It is annoying that you infer the same old things... your
> system is bigger
> and more complicated, more users... 200 did you say?? Gee,
> that's gigantic!
> Well, my tiny little system only has about 75 to 100 user
> pounding on it
> 24/7, and the number of qualifiers I make in a few files is
> teeny-tiny next
> to the 200Gb of server the applications run on... the methodology I
> described works perfectly, and has for oh, about 20 years.
>
> Again, I merely stated your way was not so easy and elegant, which you
> agreed with, feigned though it was. The following items all have less
> meaning and relevance than making a few, or even 200 qualifiers.
>
> I do not believe Don, or anyone, has to worry about any of
> the following...
> they are all quite unimportant considering how the process I
> use actually
> works... none of them make any sense, assuming one user sitting at one
> keyboard with one purpose in mind, all other "variations" on
> that theme that
> you dreamt up can easily be handled by the slightest and most
> trivial of
> additions and/or alterations. We all put up suggestions here
> that are meant
> to serve as ideas and guidelines... if you need the full
> dissertation or
> implementation of any of these ideas, I'm sure you could pay
> someone to help
> you understand them and put them in place in whatever "real
> world" situation
> you have. This was not my intention in helping Don, or
> anyone, with some
> ideas. The majority of your suggestions below are really
> quite irrelevant
> and "stage", almost to the point of stupidity as in number 7
> for example.
> User ID's needing to be unique as DNA??? Pretty good... on my
> Unix systems,
> user id's are unique... if you don't have such systems,
> please let me know
> their name so I can send some helpful guidance to the kernel
> engineers who
> wrote whatever it is you are using. I've heard of shoveling
> up the "stuff"
> to make a point, but I think you just hit the best one of the
> decade with
> that one. :-) You should submit it somewhere. :-)
>
>
> I think I'll stop here... this response of yours is way
> beneath you. Truly,
> I'm sorry I offended you by doing something a little easier
> and better than
> your offering. I'll try not to bring up such ideas in the future... or
> better yet. How about next time, don't start out your
> response to one of my
> postings by insultingly saying I'm too busy to post something
> good... The
> initial snide attitude, followed up with a fair to middling
> counter offer,
> is what gets you in the position of having to write the
> meaningless stuff
> below... How about just ignoring my posts if you don't like
> them... sending
> up all this drivel and nonsense is offensive. And next time,
> should you want
> to comment on the things I post, please have the courtesy to
> read the code
> at least. You will look less ignorant about what's going on
> that way. (In
> case you care by the way, our multi-user systems disallow
> logins by the same
> user twice... you might consider writing such precautions.
> Two lines of
> configuring such a desirable condition might alleviate the
> need for you to
> write the invasive, extra, code you suggest is SO much
> better, in your SO
> insulting way. And may I suggest that you also take the time
> to learn how
> ensure one report finishes before another is allowed to
> begin... again, two
> lines of configuring in your scripts... You are right.
> Sometimes, as you
> say, knowing a little bit about what you're doing might help.
> You claim to
> run such a LARGE enterprise, it's surprising you haven't
> learned some of the
> basics of multi-user operations. Maybe someone who works for
> you might help
> you out in this regard?
>
>
> >
> > Don, John suggestion is easier and more elegant and most
> importantly,
> > it is not invasive. Do not forget to:
>
> > 1. Copy any indexes to qualifier if used for printing report.
> > 2. Make sure you change any lookup out of your reporting programs to
> > match the original qualifiers if applicable.
> > 3. Change your data processing reports to write to newly
> created qualifier
> > 4. Make sure user does not attempt to print same report
> twice or more at
> > the same time just because he wants to see multiple date
> ranges or for
> > different customers, vendors, products, etc ...
> > 5. Make sure users do not log in more than once and have
> others attempt to
> > print the same report at once ...
> > 6. Make sure you do not use a "departmental user ID
> (sales)" where said
> > report may be printed
> > 7. In short, the user ID must be as unique as DNA and the
> report should
> > behave as a 'single user mode - one copy at a time' per user.
> >
> > Like I said, easier is not better!
> >
> > You often find yourself in situations that are simply out
> of your control.
> > As a developer, the one thing you can control is how you write your
> > applications, modules, programs ... I would suggest, do it
> so that you do
> > not need to come back to is simply because you wanted to
> get in and out
> > and as fast and as easy as possible the first time.
> >
> > Regards;
> >
> >
> > Jose Lerebours
>
> Simply put... if you haven't "gotten" it yet... In the
> future, if you can't
> respond to a message of mine without the uninformed and
> unwarranted mockery
> and sarcasm... as displayed so clearly above. Please just
> don't respond at
> all. You so quickly bring back the time when all you ever
> brought to this
> forum were arguments and flames. That is not what this place
> is about. I
> had thought everyone had gotten past that infantile mode.
> I'll promise not
> to say anything I've written could possibly be more elegant
> than what you
> write. Though it was not meant as any kind of an insult, but
> only as an
> adjective... you turned it into this. Your closing lines
> which insinuate
> that I write only "fast and easy" solutions is belied by the
> fact that they
> have worked rather flawlessly for the past 20 years... and
> brought a company
> from 1 employee to 175, and $0/yr to $25,000,000/yr. Yeah,
> badly thought
> out... fast, easy and not nearly as good as what you've done... but,
> perhaps, there are those who may find them pretty good
> platforms from which
> to build their applications. You may blissfully ignore
> them... please do.
> But, just in case you are really under the impression that I
> write only
> "fast and easy" code... be advised that if I were to pos the
> "whole" of any
> one of my code-sets, I'm quite sure you would be very hard pressed to
> comprehend it on any level from the syntax on up to its full
> integration
> with all other systems. It would elude you. I've seen your
> code, and you've
> just shown us your level of expertise as regards to
> configuring operating
> systems... all in all, I think you'd better keep the insults
> to yourself.
>
>
> Regards?
>
> (sheesh, what a hypocritical signature you have...)
>
>
More information about the Filepro-list
mailing list