Andrew Jensen wrote:
> ... technical insight about ...
> ... SQL Query stored in OO Base GUI and ...
> ... SQL View stored in DB engine ...
Frank Schönheit wrote:
> ... JDBC technical support for SQL specifications ...
Andrew and Frank, thank you for the technical details.
Can someone clarify a few ambiguous issues
raised in the discussion so far?
Thanks.
Ray
-----
My following comments are built mainly from a
users' perspective, not from technical developers',
although I am involved in software development.
Databse users are in the SQL domain, talk in SQL,
and consense by SQL specification. They do not care
a bit whether SQL functionality is achieved by OO Base,
MS Access, MS C#, Java, Python, C++, JDBC, ODBC, etc.
The RIGHT product (GUI, etc.) is determined by
users experience, not by the easiest pathway of
implementation of chosen technologies.
* data parameters (host variables) in SQL standards
Does any version of SQL standards restrict
the usage of data parameters in SQL statements?
I have not found SQL specification that explicitly
prohibits data parameters in Create View statements.
Advice on data parameters in SQL standard is appreciated.
* HSQL DB support of data parameters in Create View
Drew, do you recall the versions of HSQL DB engine
and GUI or CUI used in your tests?
My tests involved the following.
engine: HSQL DB 1.8.0.5 stand alone engine
type: stand alone database file
CUI 1: java -cp d:/hsqldb/lib/hsqldb.jar org.hsqldb.util.DatabaseManagerSwing
CUI 2: java -cp d:/hsqldb/lib/hsqldb.jar org.hsqldb.util.DatabaseManager
SQL: see the Create View statement with data parameter below
test: working, no Java exception thrown
verify: "commit; shutdown script;" to close file
*.script file still retains
the Create View statement
along with the data parameter
Create View "vv view" As
Select *
>From "tt table"
Where "column 01" Like :xx_user_input;
* OO Base GUI
I am confused about the purpose of OO Base GUI.
Apparently HSQL DB engine 1.8.0.5 has already
implemented both string concatenation || operator
and data parameters (host variables) as specified
in SQL standard. (hand shaking between GUI and DB
engine is still needed on data parameters)
Does OO Base GUI attempt to supplant SQL capabilities
that belong to DB engines and
that are already implemented by DB engines?
Does OO Base GUI attempt to compensate for the
SQL incompleteness of some SQL DB engines?
Is it not precisely part of the reasons why
users choose one DB engine over the others?
* users' experience, convenience and benefit on
Stored Query in OO Base GUI vs.
SQL View stored in DB engine
Maybe I should add another word "confusion" to above.
To layman users, there is no practical distinction in the
functionality between Queries stored in OO Base GUI and
SQL View stored in DB engine. They will not even care!
Perhaps it is why MS Access GUI design chose not to offer
to users two modules of essentially same query functionality.
There is no competitive advantage over MS Access by offering
two different and confusing pathways for queries.
Moreover, the current View in the table section is assigned
the same code of table revision. This is a very odd condition.
Despite the semantics of virtual tables for SQL View,
View revision needs the Query GUI code, not table GUI code.
Has any OO Base or QA community member ever reported success
or ease about revising the View definition using OO Base GUI?
I suggest the following changes in OO Base GUI:
-- abolish the GUI distinction between SQL View and Stored Query,
-- merge SQL View and Stored Query functionality and code,
-- offer only one pathway to define and revise View and Query
(clarity to layman users).
The code merge will automatically offer for both
Stored Query and SQL View
-- SQL operator || capability
-- SQL data parameter (host variable) capability
as each is already provided in separate OO Base GUI modules.
Please prioritize on user benefit for any software decision.
User preferrence should trump technical opinions,
if any conflict, except for data integrity and security.
Strive not to substitute what technical developers considered
best for users' preferrence, no matter how strongly developers
have opined. The consequence can be severe market loss.
A recent example is the announcement on 2006-09-15 by
Ford Motor Company to layoff 1/3 salaried employees
in its North America (USA) division.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
