🚀 go-pugleaf

On Fri, 05 Mar 1999 21:06:54 GMT, skoterski@NOSPAMinprise.com (Steve
Koterski) wrote:

>
>No. Local SQL is a facility of the BDE, not of any one front-end
>application: Visual dBASE, Delphi, C++Builder, or what-have-you. The
>behavior of local SQL should be consistent under *all* using application
>front-ends.
>
>A BDE-using application passes an SQL statement to the BDE in the form of a
>string, as a parametere to one of the BDE API functions for executing
>queries. These API functions include DbiQExec and DbiQExecDirect. So it is
>not Visual dBASE that is executing the SQL query, but the BDE. A date
>literal of "03.05.1999" should be the same whether passed to the executing
>API function by Visual dBASE or by Delphi.
>
>A difference like the one behind this thread could happen, though, if the
>application front-end was doing some hanky-panky with data values between
>the user interface and the BDE. That is, it is conceivable (to me, anyways)
>that Visual dBASE is doing something function with these date literals like
>reformatting them using Windows configuration settings before passing the
>SQL string to the API function.
>
>If such a thing were occurring, the behavior would not be part of local
>SQL. It would be peculiar to Visual dBASE. As such, it would need to be
>covered in the Visual dBASE documentation and not in that for local SQL.
>This is because the behavior would only manifest itself when SQL is used
>from Visual dBASE and not from other BDE-using programs like Delphi and
>C++Builder. To document it where non-dBASE users are going to see it and
>not see the behavior would just sow confusion.

Steve,

Thank you for explainig all this so clearly, although it still leaves
me a bit confused. In your previous message you said:

>This could be a dilemma in the local SQL online help, where I specify that
>only the US format is acceptable. I am not comfortable including something
>in this document without being able to empirically test it.

I had the impression that you talked about the Vdb online help, not a
BDE oneline help common for seveal applications and I therefore
mentioned the need for VdB when testing. 

The following is a quote from the Vdb OLH (local SQL overview):

"The Borland Database Engine (BDE) enables access to database tables
through the industry-standard SQL language. Different table formats,
for example InterBase� and Oracle, use different dialects of SQL.
Local SQL (sometimes called �client-based SQL�) is a subset of ANSI-92
SQL for accessing DB (Paradox) and DBF (dBASE) tables and fields
(called �columns� in SQL).
[snip] 
In the examples, an SQL statement may be displayed on multiple lines
for readability. But SQL is not line-oriented. When an SQL statement
is specified in a string, as it is in a Query object�s sql property,
the entire SQL statement is specified in a single line. However, if
you include a multi-line SQL statement in a program file, you must add
semicolons to the end of each line (except the last) to act as line
continuation characters; otherwise, the statement will not compile
correctly.
SQL is not case-sensitive. The convention for SQL keywords is all
uppercase, which is used in this series of Help topics. SQL statements
in the rest of the Language Reference may use either uppercase or
lowercase.

To me this appears to be a description of the specific adaption of
local SQL to VdB, because of the references to use of semicolons and
to the Language Reference. (I don't know if all applications breaks up
lines with semicolons).

The confusion arises I believe from the fact that the OLH and
information given elsewhere uses the term LocalSQL to describe both in
which form the _BDE_ should receive (date)informationLocal and how sql
statements should be written in a program. The first mentioned part is
a must but the second part is left to the designers of VdB7 to decide.
Although it is practical that sql statements in VdB looks like
corresponding sql statements in other applications there is no
requirement that they must be identical. 

The standard does not demand that VbD or its users _must_ write for
example dates in US format. It is sufficient for standardization
purposes that a date input by the user is digested in such a way that
when VdB spits it out to the BDE it has the required form to allow the
BDE to hand it to a local table. The BDE does not need to know what
the date looked like when the user wrote it. 

I do not doubt that the application front-end is doing some
hanky-panky with data values between the user interface and the BDE.
The problem is really that there is not enough hanky-panky going on,
i.e. the adaption of local SQL to VdB could have been much better.

A VdB developer will naturally expect that date formats, date staments
etc. (use of curly braces) which work elsewhere in a program would
also work in a sql statement, why not? It would also be natural to
expect that a sql statement could be written as a normal
string/command in place of the very artificial approach we have now
where grown-up people spend hours attempting to move square brackets
around or adds apostrophies in random places in attempts to make a
statement work. 

It would be interesting to know if it was considered during
development of Vdb7 to make the language easy to use by the developer
by letting the _computer_ do all the work in transforming an English-
like sentence with commonly used date formats to something the BDE
would understand.

Ivar B. Jessen