Why?

[Fairlight]

I don't really wish to argue, George, but you still aren't making any
real sense.  

Yo, homey, in case you don' be listenin', George Simon done said:
> I don't have a problem because:
> 1.  I don't _have_ to use those 3 lines of code.  It is something I just
> added a couple of days ago to show someone how the xlate command works.

Apparently you "needed" them to show someone how the xlate command worked,
then.  Whenever you wrote it, I seriously doubt you did it for your health.
You obviously had some need for it at the time, no matter how trivial.
That you don't -NEED- it in a "permanent" sense is not the point.  You
needed it at one point, even as an off-the-cuff demo, and it blew up in
your face.  Therefore, you had a problem, which ostensibly should have been
handle through correct channels.

> 2.  _If_ I had to use those lines of code, I could call the table from
> elsewhere and not automatic processing.

If, if...  Shoulda-coulda-woulda.  These and other cliches can be yours for
the low, low price of $0.00.  

It doesn't matter what you -would- do.  What matters is what you -did-, 
how it reacted, and further--how YOU reacted to its reaction.  Speficially,
-you- brought it up, then vacillated when the responses weren't what you
wanted to hear, or weren't anything you felt like actually dealing with.

> I report everything I see that does not seem to work right with filePro.  I

"Does not work right" == "Problem"

Did I miss anything in that equation?  Anyone?  

> give as much information as I can for someone to reproduce the problem, but
> I'm not about to send 600 MB to fp support.

Nobody asked you to send 600MB.  If it's a data-massaged bug, in theory
your data might be relevant, but I could have sworn I read that you tried
it on other systems with different data and obtained the same results.
Perhaps I'm in error.  I've already deleted the messages, so I can't look
it up.

Irregardless, you were asked for more of the processing than the few lines
that you -think- you nailed it down to.  I say "think" because you only got
it down to removing those lines causing the issue to go away, but we have
zero way of knowing where else data manipulation may or may not have
affected the operation of those lines.  As Ken said, we have no glimpse of
the thousands (or hundreds, or dozens) of lines of code surrounding this.
We have a half-arsed "bug" report, containing insufficient code for anyone
to replicate what you experiencd, based on a version four revisions old, in
a situation where you feel it important enough to bring up, but apparently
not important enough to even bother to -testbed- 5.0.13, change the
environment variables for a second, and verify it.

IOW, you're not doing your homework, as far as I can tell.  You've tossed
something out there, bemoaned it, and been (from all appearances) entirely
reticent to do anything asked of you in terms of substantiation.

Instead, you back-pedal, saying you don't have a problem because it doesn't
have to be done that way.  News flash:  if it -should- work, and it's not,
that's a problem--if not for you, then potentially for someone else.  So if
you brought it up for the good of the community, you're reneging on the
spirit of putting it forth.  If you're doing it just to complain, you're
doing just fine.

I quote you:  "Like I said, no biggie for me because I can call that table
from elsewhere and there is no problem."

Well to me, that seems an incredibly self-centred viewpoint.  Just because
it isn't a problem for you doesn't mean the problem doesn't exist (assuming
it isn't of your creation in the first place).  If it does, others may have
to contend with it.  Presumably that's why you'd bring it here in the first
place--to warn others--since support issues simply go to fpsupport.

> When one of my customers reports a bug in my application, I don't make them
> send me their data or do the debugging for me.  I try to duplicate it using
> my own data and if I can't, I connect to their system and try to duplicate
> it there.

Fine.  Did you offer to let fpsupport connect to your system and witness
the behaviour?  VNC is free--won't cost you -or- them a cent.

And I find the above a flimsy argument.  In fact, it's indicative of poor
debugging practice.  How, exactly, can you even start to debug something
without looking at not only the code, but the data on which the code
operates?  That's a really great way to end up on a wild goose chase.
That you would attempt to send someone else on such a chase because you
can't be bothered to assist as requested -when YOU initiated this- is
unconscionable.

You have people telling you that the code snippet you graced us with
-should- run fine.  Now there appear to be three possibilities.  1) There
was an error elsewhere in your code that you didn't account for when it was
in automatic processing, 2) there was an issue with data massaging your
code into doing something unexpected, or 3) your version of fP has a bug
that has since been fixed.

Given that you apparently refuse to provide anyone with the contextual code
because "it's not a problem" (NOW...it was a few days ago), and you also
refuse to provide data for the same reason as well as logistical reasons
that don't stand up to even mild scrutiny (export the records that were
actually -used- and you'd probably have a small file, or a few small
files), AND you also refuse to test it under 5.0.13 even in bench-test mode
to see if you can pin it down to a version discrepancy--given all that, I'd
say you should either -DO SOMETHING-, or not bring it up in the first
place.

Basically, you want fP-Tech to debug a spectre of a bug, without any but
the most minimal information (said snippet already being confirmed as valid
code), and you want them to do it all in a vacuum.  If you -didn't- want
them (or anyone else) to do anything, you wouldn't have brought it up at
all.  Well, not necessarily true--you might just like to complain.  I
suppose that explanation is possible.

This is as captivting and entertaining as when you -swore- there were speed
differences between DOS and Native Win32, but refused to -ever- provide
one objective shred of evidence to that effect publicly, despite repeated
requests by Ken.  And yet, you kept insisting it was true for a long time.
"Sweetly reminiscent...something mother used to bake..."

Not knowing you from Adam, if I had to make a call, I'd say that you want
things fixed without having to lift a finger to help the process along.
The furthest you appear to be willing to go is to complain about it rather
vaguely, and then dodge every reasonable and logical attempt by people that
are -ACTUALLY BEING RESPONSIVE- to your complaint, when they press you for
the slightest bit of additional information and objective, substantiation
that would help them be -MORE- responsive.

fP-Tech has been slammed (even by me, in the past) for being unresponsive.
You have TWO people from fP-Tech here, telling you they -are- interested
in what you're saying, and asking for more information so they can be
responsive to you, and to their other customers if it's a genuine bug
that has never been addressed.  And you refuse to cough it up.  But by
gosh, they -are- being responsive and pro-active.  And you're simply
back-pedalling and thus effectively wasting their time, if not slapping
them in the face for their trouble.

I'd say that's irresponsible.  If it was important enough to bring up
at all, then follow through.  If it's not, then don't even bring it up.
It's really that simple.  If you "know" something won't work if you toss
it in auto processing in one of the programs, you're being irresponsible
to everyone else that may run up against this in the future.  That might
actually wash if you were an anonymous customer of some product, sitting
off by yourself, found it, and just wrote it off.  But you're a member
of a community here, found something, deemed it important enough to not
only bring up, but discuss for several days in said community, and then
just damned everyone else to potentially hitting whatever you -may- have
hit (assuming it's a bug in fP at all), which can't be proven or disproven
until....

          "SOMEONE" GETS OFF THEIR ARSE AND TRIES TO -DO- SOMETHING.

So far, Ken has been a paragon of patience.  I have -zero- vested interest
in it, and mine's already expired just watching you vacillate between two
stances that are diametrically opposed.  Either it is a problem, or it
isn't.  You should have done the right thing to begin with, or done the
other right thing consistantly by following through with the bug report
process.

And what good is "reporting" it doing, if you won't cooperate in tracking
down the fine nuts and bolts of why it's failing?  What are you reporting?
That you like to hear yourself type?  Okay, we get that message.  You're
not providing the objective, empirical, HARD data necessary to do a damned
thing about it.  You won't give it to fP-Tech, and you're giving it to
people here that aren't in a position to do anything about it.  So what
-is- the point, George?  Or, assuming your new stance will remain
consistant from here on out, what -was- the point?

If someone feels I'm out of line, so be it.  Personally, I'm really annoyed
by waffling that's so extreme it should be labelled "BELGIAN" in big,
honkin', 144pt letters, and come with a pouch of strawberries and a can of
Reddi-Whip.

Maybe I was clear -this- time.  You obviously couldn't take hint #1, when
I -tried- being more diplomatic about it.  Since the needle-nosed pliers
failed, we'll try the "Jaws of Life".  God knows I've never been one to do
things by half-measures.

Lastly...

Kudos to Ken and Bill Randall for trying very dilligently and pro-actively
on their part.  The responsiveness of fP-Tech, even in this unofficial
presence, is quite evident.  It's a pity it's wasted in some situations,
through no fault of fP-Tech's whatsoever.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html