Selection date question

John Esak john at valar.com
Mon Feb 21 07:41:00 PST 2005


> >
> > 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