Thank you, Ariel. I'll try to spend some more time with Base, although I
don't like it the way it is (complex and almost undocumented).

Ariel Constenla-Haile wrote:
> Hi Andreas,
> 
> in native SQL
> 
> SELECT myfield FROM mytable
> 
> will be read by the server as
> 
> SELECT MYFIELD FROM MYTABLE
> 
> 
> If you created your table in the GUI table designer, and wrote  myfield
> and mytable, this will be passed to the server not in capitals letters,
> so your native SQL will fail.
> 
Interesting. Just tested embedded hsql based on
SELECT "ID" FROM "Table1"

SQL parsed vs. native
SELECT ID FROM "Table1" OK OK
SELECT id FROM "Table1" err_column OK
SELECT "id" FROM "Table1" err_column err_column

SELECT "ID" FROM Table1 OK err_table
SELECT "ID" FROM table1 err_table err_table
SELECT "ID" FROM "table1" err_table err_table

Parsed sql is strictly case sensitive. Native hsql is case sensitive
with quoted fields (naked id is OK), tables have to be quoted and case
sensitive.

> ...
> Now you can choose in the listbox:
> 
> 1. ODBC: in "Name of the ODBC data source in your system" you just type
> the DSN or browse looking for it (hidden to the user, the URL will be
> something like sdbc:odbc:mysql_test)
> 
> 2. JDBC: in the Datasource URL you type something like
> jdbc:mysql://localhost:3306/test
> 
> 3. MySQL: now you have to set up a connection
>          3.1 connect using ODBC => URL: "sdbc:mysql:odbc:mysql_test"
>          3.2 connect using JDBC => URL:
> "sdbc:mysql:jdbc:localhost:3306/test"
> 
> 
> So, what is the difference
>        between 1 and 3.1,
> and
>        between 2 and 3.2 ?
> 
> In *all* cases
> 
> * you need something provided by MySQL (the ODBC driver or the JDBC driver)
> * from OOo's side, it will "comunicate" through 3 different drivers for
> the three different cases 1, 2 y 3 (3 being a dedicated driver for MySQL).
> 
> http://api.openoffice.org/docs/DevelopersGuide/Database/Database.xhtml#1_1_1_1_Platform_Independence
> explains why SDBC accesses data through SDBC drivers.
> 
> SDBC drivers are UNO components:
> 
> * com.sun.star.comp.sdbc.ODBCDriver is the implementation of the
> *generic* ODBC driver
> 
> * com.sun.star.comp.sdbc.JDBCDriver for the generic JDBC
> 
> * org.openoffice.comp.drivers.MySQL.Driver is the implementation of the
> *MySQL* *dediacted* driver for JDBC/ODBC
> 
> Looking only at the file names on:
> 
> connectivity/source/drivers/odbc
> connectivity/source/drivers/jdbc
> connectivity/source/drivers/mysql
> 
> and reading only a few, I could get that
> org.openoffice.comp.drivers.MySQL.Driver works like a "delegator"
> (connectivity/source/drivers/mysql/YDriver.cxx - ODriverDelegator), that
> is, it accepts both ODBC and JDBC connection to MySQL:
> 
> ODriverDelegator::acceptsURL returns sal_True if the protocol URL is
> "sdbc:mysql:odbc:" or "sdbc:mysql:jdbc:"
> 
> once it accepts the connection URL it "delegates" the connection to the
> specific driver
> 
> ODriverDelegator::connect first loads the specific driver
> (ODriverDelegator::loadDriver) and then connects to the datasource,
> returning an XConnection.
> 
> At least that's what I understood as "delegator" reading this few lines
> of code (Frank will correct me, sure ;-) ).
> 
> But what is that this dedicated driver adds? what is the advantage of
> choosing 3.1 instead of 1, and 3.2 instead of 2?
> 
> Well, I haven't read that much, so you will have to wait for Frank to
> answer this.
> 
> In YDriver.cxx I've seen that it adds some connection properties, and
> for the name of the files in connectivity/source/drivers/mysql/, it adds
> some MySQL's specificities not covered by the general ODBC/JDBC drivers:
> columns, catalogs, users, views.
> 
> My conlusion is that when connecting to MySQL, whether using JDBC or
> ODBC, one must choose the dedicated driver (3.1 or 3.2) because it adds
> some MySQL's specificities not covered if we simply choose 1 or 2.
> 
> ...

Aha, mmmh, scratching-my-head, interesting connect-strings ... saved a
copy of this thread in a special place for later use when I have a
database server running. Yes, I wondered (but never investigated) why
there is a choice between odbc, jdbc and MySQL although you can connect
MySQL via j|odbc. I would have thought that case #3 does not require
j|odbc, analogue to this one:
http://dba.openoffice.org/drivers/postgresql/index.html
> The postgresql SDBC Driver allows to use the  postgresql database from 
> OpenOffice.org without any wrapper layer such as odbc or jdbc.


Thank you for sharing your experience and insight.

Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to