Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Michael, Ocke's on vacation for a while, so let me jump in here. Which classes you are talking about? The best way is to get rid of the dependency of JDBC. I need a specialized ResultSetMetaData class for the driver, but to integrate this class I also need to inherit the Driver, Connection, PreparedStatement and ResulSet classes to make sure that my class is used instead of the original one. May I ask which part of the JDBC driver's classes your driver actually really uses? That is, you said your classes derived from the JDBC classes - which part of the latter is the functionality you want use? I'm still a little bit confused - what is the architecture of your driver? You said As said before the driver is derived from your MySQL driver, but there are also some classes in the driver inherited from the OO JDBC driver, which for the implementation of autoincrement columns. Does derived in the first sentence has the meaning as in derived class in C++, or does it mean your driver is inspired by the MySQL driver? If the former, I don't see how it could also derive from the JDBC driver's classes, if the latter, then I'm still confused as to whether your driver also *wraps* another driver (which one?), since this is the main purpose of the MySQL driver. Could you elaborate about your driver architecture, please? This might help us finding other solutions that moving around large chunks of code ... Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Michael, me again ;) Probably there is bug regarding the save process in Base when changing a default value or a description text. It appears with MySQL and Ingres, but not with HSQLDB. I reviewed the driver method OTable::alterColumnByName, but I didn't find the root cause for this. To reproduce try the following: 1. Create a table with a few columns, e.g. four. The name and the type of the columns is arbitrary. 2. Close the table 3. Open the table design view 4. Try to change the description text and the default value of one or more columns and save it 5. Reopen the table design view and check if the changes were saved 6. Repeat steps 4. to 6. multiple times. The changes are not always saved. Definitely a bug - care to visit IssueZilla? One thing to mention is that the description text and the default value, as you see them in the UI, might not be what you expect them to be. That is, those values are completely client-side at the moment, even if the underlying database would support them, to. So, whatever you enter here, is not sent to the database, it's just used in Base's own UI. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Ocke, Which classes you are talking about? The best way is to get rid of the dependency of JDBC. I need a specialized ResultSetMetaData class for the driver, but to integrate this class I also need to inherit the Driver, Connection, PreparedStatement and ResulSet classes to make sure that my class is used instead of the original one. This is all to enable AutoValues. Base must get the information which column is an AutoValue. Ingres doesn't know AutoValues but it knows Sequnces which may be used for AutoValues. To detect that a certain column is an AutoValue column the database is queried for the default value of the column, which must be generated by a sequence in case of an AutoValue column. This query is realized in the inherited class. You can't link against JDBC that simple. I would prefer that you isolate the classes you need and move them into dbtools (that's the commontools folder) In that way both can share it and we don't have duplicate (bad) code ;-) I will try to move the classes. Strange that it works on Windows, but not Linux. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Ocke, me again ;) Probably there is bug regarding the save process in Base when changing a default value or a description text. It appears with MySQL and Ingres, but not with HSQLDB. I reviewed the driver method OTable::alterColumnByName, but I didn't find the root cause for this. To reproduce try the following: 1. Create a table with a few columns, e.g. four. The name and the type of the columns is arbitrary. 2. Close the table 3. Open the table design view 4. Try to change the description text and the default value of one or more columns and save it 5. Reopen the table design view and check if the changes were saved 6. Repeat steps 4. to 6. multiple times. The changes are not always saved. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Micha, Michael Strobel wrote: Hi Ocke, - how about just call dropObject at the views Calling dropObject at the views results in a SQL exception since the view is already dropped in the database. I just tried to catch the exception and ignore it to see what happens, but calling that didn't solve the actual problem. Another try to get the right object could be to query *this for XDrop and then call dropObject I don't know if it works but give it a try. :-) - or forbid that a table which is referenced in a vew can not be deleted :-) This is possible, but unfortunately my project lead isn't happy with this solution as it doesn't reflect the standard behavior of the database. Working on that ;) I have still one more question ;) I began the development using Windows and now tried to compile the driver for Linux, which gave me some linker problems. As said before the driver is derived from your MySQL driver, but there are also some classes in the driver inherited from the OO JDBC driver, which for the implementation of autoincrement columns. (I know it's nasty, but I don't see a chance to change it.) Which classes you are talking about? The best way is to get rid of the dependency of JDBC. To get the symbols for the linker under Windows I just added the jdbc.lib to the SHL1STDLIBS in the makefile, which works fine for linking, but under Linux putting -ljdbc2 doesn't work. The linker generates a lot of undefined symbol errors for the symbols from the libjdbc2.so. I have also tried to add it to SHL1LIBS instead, but this gives results in multiple definitions of component_getFactory and component_getImplementationEnvironement. Any ideas? You can't link against JDBC that simple. I would prefer that you isolate the classes you need and move them into dbtools (that's the commontools folder). In that way both can share it and we don't have duplicate (bad) code ;-) Best regards, Ocke Best reagards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ocke Janssen Tel: +49 40 23646 661, x1 Dipl. Inf(FH) Fax: +49 40 23646 550 Sun Microsystems Inc. Nagelsweg 55 mailto:[EMAIL PROTECTED] D-20097 Hamburg http://www.sun.com/staroffice Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Moin Micha,
Michael Strobel wrote:
Hi Ocke,
I have created issues for the stuff, which we discussed last time I
posted here. It seems like it will still take a while until they are
treated. There are still a few more problems with the driver and hope
you have an idea how to solve this one:
A view that references a table is dropped silently by our DBMS, when the
referenced table is dropped, yet Base still displayes the view, until
View-Refresh Tables in the Bases menubar is clicked.
Calling refreshTables() and refreshViews() from the IngCatalog class
doesn't solve this, as it only refreshes the structures in the driver,
but Base has no clue that they have changed.
I guess I should do something like the following for every silently
dropped view in the implementation of XDrop for the IngTables class to
tell Base about the change, but it doesn't seem to work either.
IngViews* pViews = static_castIngViews*
(static_castOIngresCatalog(m_rParent).getPrivateViews());
if (pViews pViews-hasByName(_ViewName_))
{
pViews-dropByNameImpl(_ViewName_);
ContainerEvent aEvent(static_castXContainer*(this),
makeAny(_ViewName_), Any(), Any());
OInterfaceIteratorHelper aListenerLoop(m_aContainerListeners);
while (aListenerLoop.hasMoreElements())
{
static_castXContainerListener*
(aListenerLoop.next())-elementRemoved(aEvent);
}
}
I think now it's time for debugger :-)
Some brainstorming:
- set breakpoints in dbaccess/source/core/api/viewcontainer.cxx
::elementremoved and tablecontainer.cxx
- can it be that the view name is still in the tablecontainer
- debug who receives the elementRemoved message
- how about just call dropObject at the views
- or forbid that a table which is referenced in a vew can not be deleted :-)
Best regards,
Ocke
Best Regards,
Micha
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ocke Janssen Tel: +49 40 23646 661, x1
Dipl. Inf(FH) Fax: +49 40 23646 550
Sun Microsystems Inc.
Nagelsweg 55 mailto:[EMAIL PROTECTED]
D-20097 Hamburg http://www.sun.com/staroffice
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Ocke,
I have created issues for the stuff, which we discussed last time I
posted here. It seems like it will still take a while until they are
treated. There are still a few more problems with the driver and hope
you have an idea how to solve this one:
A view that references a table is dropped silently by our DBMS, when the
referenced table is dropped, yet Base still displayes the view, until
View-Refresh Tables in the Bases menubar is clicked.
Calling refreshTables() and refreshViews() from the IngCatalog class
doesn't solve this, as it only refreshes the structures in the driver,
but Base has no clue that they have changed.
I guess I should do something like the following for every silently
dropped view in the implementation of XDrop for the IngTables class to
tell Base about the change, but it doesn't seem to work either.
IngViews* pViews = static_castIngViews*
(static_castOIngresCatalog(m_rParent).getPrivateViews());
if (pViews pViews-hasByName(_ViewName_))
{
pViews-dropByNameImpl(_ViewName_);
ContainerEvent aEvent(static_castXContainer*(this),
makeAny(_ViewName_), Any(), Any());
OInterfaceIteratorHelper aListenerLoop(m_aContainerListeners);
while (aListenerLoop.hasMoreElements())
{
static_castXContainerListener*
(aListenerLoop.next())-elementRemoved(aEvent);
}
}
Best Regards,
Micha
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Moin Micha, Michael Strobel wrote: Hi Ocke, You also have to check getColums, getPrimaryKey, getExportedKeys and all occurrences where a table or column name can be asked for. The best way is to look at the databasemetedata where a resultset is returned. Works. Only the table name that is displayed the tree view in the OO Base main window is still in upper case. Do you know where it is stored? Column 3 from getTables ResultSet from XDatabaseMetaData is used. What do you think about that OO base might delete a long varchar value under the circumstances which I described in my last mail? Sorry I missed that in my answer. I never created such long text before, could you please submit an issue for this. May be someone in between has still use USHORT_MAX as limitation. Thanks. Best regards, Ocke Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ocke Janssen Tel: +49 40 23646 661, x1 Dipl. Inf(FH) Fax: +49 40 23646 550 Sun Microsystems Inc. Nagelsweg 55 mailto:[EMAIL PROTECTED] D-20097 Hamburg http://www.sun.com/staroffice Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Ocke, You also have to check getColums, getPrimaryKey, getExportedKeys and all occurrences where a table or column name can be asked for. The best way is to look at the databasemetedata where a resultset is returned. Works. Only the table name that is displayed the tree view in the OO Base main window is still in upper case. Do you know where it is stored? What do you think about that OO base might delete a long varchar value under the circumstances which I described in my last mail? Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Ocke, After save the table we ask the db metadata with getTabes and the parameter filled for the table we saved. May be that doesn't return no information. When you do a refresh it is mostly like creating a new connection. Thanks, that helped, at least a bit. The problem results from the Ingres behavior with identifier case sensitivity. While Ingres treats quoted identifiers per default as case insensitive, ANSI/ISO Entry SQL-92 specifies quoted identifiers as case sensitive. Open Office uses quoted identifiers and always expects them to be ANSI/ISO Entry SQL-92 compliant. Open Office builds a create table statement with quoted identifiers in mixed case, so the table name is mixed case in Open Office and in lower case in Ingres. Afterwards Open Office tries to fetch a description of the table for updating it's list of available tables using DatabaseMetaData.getTables() and passes the tableNamePattern in mixed case. DatabaseMetaData.getTables() builds a query against the catalogs that hence includes the table name in mixed case in a like comparison. As the table name is stored in the catalogs as lower case the like comparison fails and an empty result is returned, so the newly created table doesn't appear in Open Office list of available tables. I tried to perform a toAsciiLowerCase() on the table name string before getTables() is called. This results in an update of the tree view in the OO Base main window, but the table name appears in the tree view as mixed case, opening the table shows no editable columns and reopening the table design shows no columns at all. An extra call of Catalog.refreshTables() after creating the table also didn't do a correct refresh. Could I do anything else in the driver to repair this? Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Micha, Michael Strobel wrote: Hi Ocke, After save the table we ask the db metadata with getTabes and the parameter filled for the table we saved. May be that doesn't return no information. When you do a refresh it is mostly like creating a new connection. Thanks, that helped, at least a bit. The problem results from the Ingres behavior with identifier case sensitivity. While Ingres treats quoted identifiers per default as case insensitive, ANSI/ISO Entry SQL-92 specifies quoted identifiers as case sensitive. Open Office uses quoted identifiers and always expects them to be ANSI/ISO Entry SQL-92 compliant. Open Office builds a create table statement with quoted identifiers in mixed case, so the table name is mixed case in Open Office and in lower case in Ingres. Afterwards Open Office tries to fetch a description of the table for updating it's list of available tables using DatabaseMetaData.getTables() and passes the tableNamePattern in mixed case. DatabaseMetaData.getTables() builds a query against the catalogs that hence includes the table name in mixed case in a like comparison. As the table name is stored in the catalogs as lower case the like comparison fails and an empty result is returned, so the newly created table doesn't appear in Open Office list of available tables. I tried to perform a toAsciiLowerCase() on the table name string before getTables() is called. This results in an update of the tree view in the OO Base main window, but the table name appears in the tree view as mixed case, opening the table shows no editable columns and reopening the table design shows no columns at all. An extra call of Catalog.refreshTables() after creating the table also didn't do a correct refresh. Could I do anything else in the driver to repair this? You also have to check getColums, getPrimaryKey, getExportedKeys and all occurrences where a table or column name can be asked for. The best way is to look at the databasemetedata where a resultset is returned. Best regards, Ocke Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ocke Janssen Tel: +49 40 23646 661, x1 Dipl. Inf(FH) Fax: +49 40 23646 550 Sun Microsystems Inc. Nagelsweg 55 mailto:[EMAIL PROTECTED] D-20097 Hamburg http://www.sun.com/staroffice Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
RE: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Ocke, That would be great. But an issue where you attach the bugdoc would even be better :-) I got the following mail from our JDBC driver developer, which makes me think it's not an issue. What do you think? --- snip --- Working with LOB columns is extremely difficult due to many restrictions on when the data can or must be accessed. Autocommit makes it very difficult to handle LOB locators. I do not recommend enabling locators during autocommit, especially with a cursor mode of 'multi'. Simulating autocommit to support multiple open cursors (which Ingres does not support) results in full transaction commits being issued by the driver. A full commit invalidates a LOB locator, which is probably the cause of your problems. With locators disabled, the application must process the streamed LOB data. This restricts what actions may be taken on the connection. The application is attempting to issue a new query when there is LOB data still to be processed. The driver protects the data stream with locks, which is causing a dead-lock in the application. Most generic applications are not disciplined enough to follow JDBC portability guidelines of reading all columns in order and only once when processing result-sets. My suggestion is that you do not enable lob locators (use default settings), but that you enable the caching of LOB data. This will avoid the transaction conflicts with locators and restrictions on processing LOB data streams. The downside is that LOB data will need to fit in memory. Please review the BLOB Column Handling section of the JDBC chapter in the 2006r3 Connectivity Guide. --- snip --- The suggestion to enable the caching of LOB data works for me. Maybe this is what databases which run out of the box with OO do by default. While doing more tests of the driver unfortunately I discovered the following two problems: When I click the save button in the table design view for a new table without having set a primary key beforehand a dialog appears which allows me to let OO create a additional column 'ID' as primary key. That's fine so far. When I click the 'Yes' Button in the dialog the create table statement is executed correctly, but OO doesn't recognize the new table until the tables are refreshed manually by clicking 'View - Refresh Tables'. In table design view you may again click the save button as OO doesn't recognize that the table is created successfully. Clicking the button again produces an SQL error as the table already exists. Similar thing happens when I use the table wizard to create a table. Clicking finish executes the create table statement correctly, but the table isn't displayed in the list of tables and the wizard doesn't close itself. Clicking the finish button again produces an SQL error as the table already exists. Any ideas what might be the root cause? I did a bit code reviewing but found nothing suspicious so far. Do you know what queries are usually executed after saving a table? Possibly there is one that doesn't work with Ingres in these situations. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Moin Micha, Michael Strobel wrote: Hi Ocke, That would be great. But an issue where you attach the bugdoc would even be better :-) I got the following mail from our JDBC driver developer, which makes me think it's not an issue. What do you think? --- snip --- Working with LOB columns is extremely difficult due to many restrictions on when the data can or must be accessed. Autocommit makes it very difficult to handle LOB locators. I do not recommend enabling locators during autocommit, especially with a cursor mode of 'multi'. Simulating autocommit to support multiple open cursors (which Ingres does not support) results in full transaction commits being issued by the driver. A full commit invalidates a LOB locator, which is probably the cause of your problems. With locators disabled, the application must process the streamed LOB data. This restricts what actions may be taken on the connection. The application is attempting to issue a new query when there is LOB data still to be processed. The driver protects the data stream with locks, which is causing a dead-lock in the application. Most generic applications are not disciplined enough to follow JDBC portability guidelines of reading all columns in order and only once when processing result-sets. My suggestion is that you do not enable lob locators (use default settings), but that you enable the caching of LOB data. This will avoid the transaction conflicts with locators and restrictions on processing LOB data streams. The downside is that LOB data will need to fit in memory. Please review the BLOB Column Handling section of the JDBC chapter in the 2006r3 Connectivity Guide. --- snip --- The suggestion to enable the caching of LOB data works for me. Maybe this is what databases which run out of the box with OO do by default. While doing more tests of the driver unfortunately I discovered the following two problems: When I click the save button in the table design view for a new table without having set a primary key beforehand a dialog appears which allows me to let OO create a additional column 'ID' as primary key. That's fine so far. When I click the 'Yes' Button in the dialog the create table statement is executed correctly, but OO doesn't recognize the new table until the tables are refreshed manually by clicking 'View - Refresh Tables'. In table design view you may again click the save button as OO doesn't recognize that the table is created successfully. Clicking the button again produces an SQL error as the table already exists. Similar thing happens when I use the table wizard to create a table. Clicking finish executes the create table statement correctly, but the table isn't displayed in the list of tables and the wizard doesn't close itself. Clicking the finish button again produces an SQL error as the table already exists. Any ideas what might be the root cause? I did a bit code reviewing but found nothing suspicious so far. Do you know what queries are usually executed after saving a table? Possibly there is one that doesn't work with Ingres in these situations. After save the table we ask the db metadata with getTabes and the parameter filled for the table we saved. May be that doesn't return no information. When you do a refresh it is mostly like creating a new connection. Best regards, Ocke Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ocke Janssen Tel: +49 40 23646 661, x1 Dipl. Inf(FH) Fax: +49 40 23646 550 Sun Microsystems Inc. Nagelsweg 55 mailto:[EMAIL PROTECTED] D-20097 Hamburg http://www.sun.com/staroffice Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
RE: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Ocke, You may have a look at connectivity/source/commontools/FValue.cxx. This class is used to fetch the values from the result set and dbtools.cxx as well. How does your table structure look like? Could you create another db (may be hsqldb) for a testing purpose with some sample data so that I may have a look at it? Creating another db is no problem, if you think it's useful. I'm using a very simple test case, one table t1 with columns c1 int, primary key, c2 varchar(5), c3 long varchar containing one row (1, 'test', 'test') and the trace output from the JDBC driver. I can send you the trace output, just didn't attach it here because of it's size. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi MIcha, Michael Strobel wrote: Hi Ocke, You may have a look at connectivity/source/commontools/FValue.cxx. This class is used to fetch the values from the result set and dbtools.cxx as well. How does your table structure look like? Could you create another db (may be hsqldb) for a testing purpose with some sample data so that I may have a look at it? Creating another db is no problem, if you think it's useful. I'm using a very simple test case, one table t1 with columns c1 int, primary key, c2 varchar(5), c3 long varchar containing one row (1, 'test', 'test') and the trace output from the JDBC driver. I can send you the trace output, just didn't attach it here because of it's size. That would be great. But an issue where you attach the bugdoc would even be better :-) Best regards, Ocke Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ocke Janssen Tel: +49 40 23646 661, x1 Dipl. Inf(FH) Fax: +49 40 23646 550 Sun Microsystems Inc. Nagelsweg 55 mailto:[EMAIL PROTECTED] D-20097 Hamburg http://www.sun.com/staroffice Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Moin Micha, Michael Strobel wrote: Hi Ocke, Your patch work's fine with the test programs, but I'm still unable to read and write long varchar columns in OO Base. I guess OO Base may be mislead by our JDBC driver, which unfortunately returns always 0 for the length and precision of long varchar columns. Methods that return always 0 for the length and precision of long varchar columns: - XConnection.getMetaData().getTypeInfo() in PRECISION (column 3) - XConnection.getMetaData().getColumns(...) in COLUMN_SIZE (column 7) - XResultSetMetaData.getPrecision(...) It's possible to switch our JDBC driver in two different modes. First mode disables use of clobs, long varchar columnss are described as type -1 in ResultSetMetaData. This mode causes OO Base to freeze, when it tries to read long varchar column using getString(). Second mode enables use of clobs, long varchar columnss are described as type 2005 in ResultSetMetaData. In this mode Base displays the long varchar columns always empty, values may be entered, but disappear as you leave the input field with the cursor and don't go to the database. Could the length and precision values cause such a behavior in Base? No, the length and precision are only used when you try to change the table layout or to create a new table. The problem here seems to be that the data could not be read. The method getString should always return something. So may be calling getString for a long var char column doesn't work for your jdbc driver. Best regards, Ocke Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ocke Janssen Tel: +49 40 23646 661, x1 Dipl. Inf(FH) Fax: +49 40 23646 550 Sun Microsystems Inc. Nagelsweg 55 mailto:[EMAIL PROTECTED] D-20097 Hamburg http://www.sun.com/staroffice Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
No, the length and precision are only used when you try to change the table layout or to create a new table. The problem here seems to be that the data could not be read. The method getString should always return something. So may be calling getString for a long var char column doesn't work for your jdbc driver. You're right, changing the length and precision in our JDBC driver didn't resolve the problem, calling getString() for a long varchar column works fine in my test programs. The problem that appears when not using clobs is that a race condition between two threads in our JDBC driver is caused by the use of multiple simultaneously opened result sets, but I cannot say at moment if this is because of our JDBC the way OO handles long varchar columns. I hope our JDBC driver developer can tell me. I still don't know what's wrong when using clobs. From the tracing info I got from the JDBC driver I can only tell that OO fetches the column description and afterwards doesn't try to read/write column values using getClob() but simply ignores them. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Ocke, Your patch work's fine with the test programs, but I'm still unable to read and write long varchar columns in OO Base. I guess OO Base may be mislead by our JDBC driver, which unfortunately returns always 0 for the length and precision of long varchar columns. Methods that return always 0 for the length and precision of long varchar columns: - XConnection.getMetaData().getTypeInfo() in PRECISION (column 3) - XConnection.getMetaData().getColumns(...) in COLUMN_SIZE (column 7) - XResultSetMetaData.getPrecision(...) It's possible to switch our JDBC driver in two different modes. First mode disables use of clobs, long varchar columnss are described as type -1 in ResultSetMetaData. This mode causes OO Base to freeze, when it tries to read long varchar column using getString(). Second mode enables use of clobs, long varchar columnss are described as type 2005 in ResultSetMetaData. In this mode Base displays the long varchar columns always empty, values may be entered, but disappear as you leave the input field with the cursor and don't go to the database. Could the length and precision values cause such a behavior in Base? Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Moin Ocke, XClob is not well tested in OOo. Which type does your column have? May be getCharacterStream works as well. Please submit an issue for the XClob. Thank you. The column type is long varchar. Using the the test programs - a JavaApp and a OOoClientApp - mentioned in the last mail for testing with a MySQL database the problem, also occurred. I'm wondering how OOo Base actually reads/writes long varchar columns on a MySQL database? Not via XClob? I have created Issue 90114 for the XClob and hope everything is filled in correct. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
XClob is not well tested in OOo. Which type does your column have? May be getCharacterStream works as well. Please submit an issue for the XClob. Thank you. Ahh, sorry, I didn't notice getCharacterStream. That explains how OOo Base could retrieve the data from a MySQL database. Hmm, no doesn't work over SDBC-JDBC with MySQL and Ingres, JDBC works. Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Moin Micha, Michael Strobel wrote: Moin Ocke, When you call at the metadata the getTypeInfo method which results do you get? You could for example use the code in the qa folder as template. I wrote a small test program that calls getTypeInfo and shows the result. Used NetBeans for this, very cool :) The value is actually set to the string supplied with the Properties, but as before there is no change in Open Office. Unexpected values as the string null don't produce any errors? What do you want to achieve with the TypeDescriptionInfo? May be your Double type doesn't need any parameters, just a guess. Currently null is not recognized as keyword, you have to adjust the RowFunctionParser.cxx when you don't want to appear the word null as the column value. So this is necessary to set a value in the result to null, because so far only substitution of values is possible? When null is really needed, may be should could change the RowFunctionParser to accept null as well. It's not that complicated ;-) Freeze is not good. Does this happen also with other dbs? Sometimes we are calling getObject(xx) and some methods are not handled well. It depends on the column which method is called, may a look in ORowSetValue might help or dbtools.cxx No, it doesn't happen with MySQL at least. As far as I could see OOo uses LOB locators to retrieve LOB values from the DBMs. What happens if LOB locators are not supported? I think Ingres supports them in the version I'm using. Maybe our JDBC driver developer can give more hints. You have an own JDBC driver? Then change the getTypeInfo there :-) Best regards, Ocke Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ocke Janssen Tel: +49 40 23646 661, x1 Dipl. Inf(FH) Fax: +49 40 23646 550 Sun Microsystems Inc. Nagelsweg 55 mailto:[EMAIL PROTECTED] D-20097 Hamburg http://www.sun.com/staroffice Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
RE: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Moin Ocke, What do you want to achieve with the TypeDescriptionInfo? May be your Double type doesn't need any parameters, just a guess. You have an own JDBC driver? Then change the getTypeInfo there :-) Right, the Ingres double type doesn't expect any parameters. It's definitely a bug in the getTypeInfo() method of our JDBC driver. Just thought I can fix it that way, until our JDBC driver guy fixed it in the JDBC driver :) The LOB thing is strange. It turned out that I used an old version of the JDBC driver and the newest version doesn't cause Open Office to freeze, but it's still neither possible to read nor to write LOBs. A small test program written in NetBeans showed, that calling getClob() on a XRow doesn't return an XClob as expected, while doing getClob() on a Row in Java with the JDBC driver returns a Clob. Possibly a problem with passing the LOB reference from Java to C++? If I call getString() on XRow for a CLOB column I get the string. Confusing... Best regards, Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
The rename entry is already there. I would take the sources from the mysql driver and change the sql statement in such way that ingres understand it :-) It has been quite a while and there is still more refinement needed, but finally the driver compiles and the basic stuff works :-) Thank's again for your help! Best regards, Michael
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Moin Michael, Michael Strobel wrote: Moin Ocke, thanks for your fast reply :-) Normally I attach the debugger to the process or start soffice.bin directly. But it depends on your operating system ;-) Okay, make debug seems to be sufficient to create the symbols for the debugger :-) I'll keep trying to load the symbols in the MS debugger, seems to be harder than with gdb. The driver will be queried for these interfaces. If the result is NULL it isn't one :-) That means OOo calls Driver-queryInterface(XDataDefinitionSupplier) and queryInterface returns ReferenceXDataDefinitionSupplier(this) if it is implemented and NULL if not? Let's assume I implement empty methods for the interface(s) exported by the service(s) needed to rename a table. Just for testing ;-) Is this sufficient to provide a rename menu item in the context menu on a table? The rename entry is already there. I would take the sources from the mysql driver and change the sql statement in such way that ingres understand it :-) - oj Best regards, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ocke Janssen Tel: +49 40 23646 661, x1 Dipl. Inf(FH) Fax: +49 40 23646 550 Sun Microsystems Inc. Nagelsweg 55 mailto:[EMAIL PROTECTED] D-20097 Hamburg http://www.sun.com/staroffice Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Michael, Michael Strobel escribió: Hi, I try to develop a SDBC driver for Ingres and OOo Could you give me some advice how to manage this problem, please? Do I need to compile the whole OOo source code, besides using the OOo SDK or should I try something totally different? sure Frank will answer giving the exact insight. I can only tell you there are two different ways if you want to develop in OOo with C++ (unfortunately not very clearly separated in http://wiki.services.openoffice.org/wiki/Main_Page#Getting_started_with_OOo_development) a) you can use only OOo API to extend OOo with independent UNO components, for this you only need the SDK build environment; you don't need to read a line of OOo source code (you *may*, if you want; but you can also be only a client of the API - even the C++ API of the URE libraries) [NOTE: by independent I mean you can *only* link against URE libraries] b) you can hack (horrible word/perspective)/develop in the core OOo source code. For this you need the OOo build environment (the one used to build OOo from the source code, NOT the SDK build environment) In the connectivity module you will find a how-to: connectivity/workben/skeleton/how_to_write_a_driver.txt The only C++ external UNO driver component I know is the PostgreSQL SDBC driver, but this component is not a true independent extension, as it is (AFAIK) build linking against the connectivity module libraries. And by reading Stephan Bergmann's mails (for example in http://extensions.openoffice.org/servlets/ReadMsg?list=devmsgNo=1324), a driver developed/build this way *may* be broken in the 3-layer OOo. Questions to Frank: * do you have any idea if external drivers linking against connectivity libs. will break in the 3-layer OOo? * is it possible to develop a really independent C++ UNO driver component (as an extension), i.e. using only OOo UNO API and linking only to the URE libraries (that is, not using any code form the connectivity module at all)? I guess it must be possible (if not, a UNO driver component in oder language than C++, let's say Python, Java, will be impossible). Regards Ariel. -- Ariel Constenla-Haile La Plata, Argentina [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ArielConstenlaHaile.com.ar/ooo/ Aus der Kriegsschule des Lebens - Was mich nicht umbringt, macht mich härter. Nietzsche Götzendämmerung, Sprüche und Pfeile, 8. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi, The only C++ external UNO driver component I know is the PostgreSQL SDBC driver, but this component is not a true independent extension, as it is (AFAIK) build linking against the connectivity module libraries. the postgresql driver is an implementation, that just links to ODK libraries and uses only the pure API interface. You don't need to implement XUnoTunnel. I think, it can give you a good start, as all functionality is in these few source files. http://dba.openoffice.org/drivers/postgresql/index.html However, it is currently built within the office build environment (find an explanation in the above document), so you need to rewrite the makefiles to build it within the ODK, but this will work in the end (you need to translate the makefile.mk). To make your driver work, you additionally need some configuration elements. You may check the content of the above uno package. Bye, Joerg And by reading Stephan Bergmann's mails (for example in http://extensions.openoffice.org/servlets/ReadMsg?list=devmsgNo=1324), a driver developed/build this way *may* be broken in the 3-layer OOo. Questions to Frank: * do you have any idea if external drivers linking against connectivity libs. will break in the 3-layer OOo? * is it possible to develop a really independent C++ UNO driver component (as an extension), i.e. using only OOo UNO API and linking only to the URE libraries (that is, not using any code form the connectivity module at all)? I guess it must be possible (if not, a UNO driver component in oder language than C++, let's say Python, Java, will be impossible). Regards Ariel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Joerg, Joerg Budischewski escribió: Hi, The only C++ external UNO driver component I know is the PostgreSQL SDBC driver, but this component is not a true independent extension, as it is (AFAIK) build linking against the connectivity module libraries. the postgresql driver is an implementation, that just links to ODK libraries and uses only the pure API interface. You don't need to implement XUnoTunnel. I think, it can give you a good start, as all functionality is in these few source files. http://dba.openoffice.org/drivers/postgresql/index.html However, it is currently built within the office build environment that gave me the *wrong* (sorry for that :-) ) idea it was build linking against connectivity to Michael: if you manage to create a makefile to build Joerg's driver with the SDK build environment, it would be nice if you can put it in the (up to now quite empty) Wiki page http://wiki.services.openoffice.org/wiki/PostgreSQL_Driver together with a few lines. Regards Ariel. -- Ariel Constenla-Haile La Plata, Argentina [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.ArielConstenlaHaile.com.ar/ooo/ Aus der Kriegsschule des Lebens - Was mich nicht umbringt, macht mich härter. Nietzsche Götzendämmerung, Sprüche und Pfeile, 8. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver
Hi Ariel, (answering the easy questions first, sorry Michael, your questions are more time-consuming to answer) * do you have any idea if external drivers linking against connectivity libs. will break in the 3-layer OOo? Joerg already pointed out that the PostgreSQL driver in fact is what was formerly called a well-formed component (didn't hear this term for quite a while - not sure it is stil. valid) - linked against URE only. For C++ components which link against non-OOo libraries, the problem is not in the 3 layer office, but in the unstable API of those libraries: Only URE libraries are guaranteed to have a stable API/ABI, no matter which version you use. (Of course if you use functionality from a newer URE lib than you can't use an older version of it.) Non-URE libs don't have this ABI compatibility promise, so any components linked against such a lib is highly likely to break sooner or later. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
