Borland Bug Report of Feature Request # 442879

I've been trying to get this e-mail through for 10 days, but the
crystal.inprise.com server has been down. So I'll post the message
here in the newsgroup and maybe somebody who should will see it.
I've wasted enough time on this already.

The bug is basically that you can't use the "BETWEEN" operator in
an SQL statement in a TQuery with a Live Result set unless the remote
database happens to tolerate the invalid SQL syntax that the BDE
generates when you use it. MS SQL Server works/SQL Links works;
DB2/400 ODBC doesn't, for example.

--------------

There are two problems I have with the original analysis of my problem
and your review of the problem.

First, the problem I reported was reproduced using the Borland Database
Explorer. You're responding by telling me how to fix my code. You need
to tell the Database Explorer developers how to fix their code.

The second, and more significant, problem with your analysis is that you
say the behavior I reported is "how it was designed to work". It may be
how it was DESIGNED to work, but it is in direct contradiction as to how
it is DOCUMENTED to work. Let me refer you to the Borland Delphi 5
Developer's Guide, page 21-16, 21-17. The sections, "Local SQL
requirements
for a live result set" and "Remote server SQL requirements for a live
result set". A competent response to my bug report would be to point
out in the documentation where the use of the "BETWEEN" operator is
not allowed in a Live Result set (which cannot be done), or to
acknowledge
the bug.

The fact of the matter is that there is a stupid bug here where an
extra set of parenthesis are being inserted in the SQL that shouldn't
be there, according to the ODBC SQL standard. It doesn't fail because of
how it was designed to work; it fails because somebody coded it wrong.
The only reason it wasn't caught in QA is that SOME SQL databases
will tolerate the syntactical error.

We had code that was working with Microsoft SQL Server 7.0. When we
tried the same code with IBM's DB2/400 database via ODBC it failed.
We traced the SQL and I was all ready to call IBM and report a bug in
their DB2 ODBC driver, but first I did my homework. I plowed through
the ODBC specification and found that The IBM DB/2 ODBC driver was
correct to reject the SQL statement. I spent a number of hours in
problem isolation. I was careful not to report the bug to the wrong
vendor. On other occasions I have spent the hours and the result
was to call IBM and not to bother Inprise.

Let me be frank with you here. It angers me greatly when I do my
job and somebody else is negligent in theirs. I don't believe the
original reviewer of my bug report did his job. If he had, he
would have checked your documentation against what I reported and seen
the problem. I don't believe you did your job either, because you
didn't look into the technical details of my original problem
report.

Kevin Davidson, President
QS Technologies, Inc.
Suite 1106 Bank of America Plaza
Greenville, SC 29601
(864) 232-2666 x 3505
http://www.qsinc.com

Quote
> -----Original Message-----
> From: Borland Dev. Support [mailto:clar...@crystal.inprise.com]
> Sent: Monday, August 07, 2000 12:42 PM
> To: Kevin Davidson
> Subject: Borland Bug Report or Feature Request #442879

> Dear Kevin Davidson,

> I have looked at incident number 436345 and I don't see any
> problem with the
> response given.  He's not saying that your report is wrong,
> he's simply
> saying that when RequestLive is true then that it ths
> behavior of the TQuery
> component.  That is simply the way it is designed, and to
> avoid it you should
> set RequestLive = False.   Perhaps if you could offer a more detailed
> explanation of what your grievance is we could come to some
> sort of resolution.

> Thank you,
> Varick
> Inprise/Borland

> To add case notes to this case, use the following link:
> http://pso.inprise.com/webcustomer/clearexx_cgi/x_Case_Bug.htm

?case.id_number=442879&case.cclist2=KevinDavidson

---- Begin description of problem or feature sent ----
I am requesting that someone other than the original responder review
incident number 436345. The response received is unacceptable.

Steps to reproduce the problem:
See original report.

---- End description of problem or feature sent ----