Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Frank Schönheit - Sun Microsystems Germany]

Hi Michael,

> Okay, I went through some documents introducing to the CWS concept. In
> case using a CWS to apply my changes, I'll need to checkout the most
> recent milestone via cwsquery, create the CWS via cwscreate, apply my
> changes locally to the CWS and commit them to the CWS via a CVS commit,

right so far. If you want us to, we can create the CWS for you - that's
a service for first-time contributors ;) to relieve them from some stuff.

> but I'll need to get an CWS account, right? How do I get the account?

For committing, you definitely need a SSH key submitted to us. Since we
just migrated to Subversion, I refer you to
http://wiki.services.openoffice.org/wiki/OOo_and_Subversion#SSH_Setup
here, which describes how to create and submit your SSH key.

When you submit an issue where you attached the SSH key, put me (fs) on
CC, so I can approve your request for commit access.

Finally, enter your data on
http://wiki.services.openoffice.org/wiki/DomainDeveloper, as appropriate
(name and OOo login name, IRC nick and company if applicable/desired).


Note that since the migration from CVS to SVN realy just happened
yesterday, I expect problems on the way - personally, I did not yet work
on a SVN-CWS, probably some tooling might not yet be as polished as
desired, and so on. So, I beg for your patience when working with this ...

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: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Dienstag, 30. September 2008 13:29
> To: dev@dba.openoffice.org
Hi Frank,
 
> If you want, we can create a CWS based on this milestone, and commit
> your changes (or you can do yourself, if you want, after we granted
> you permissions to do so). Any adjustments which are possibly needed
> can then happen in this CWS, and we can fine-tune it without
> disturbing other development.
> 
> Such a dedicated CWS would be easier (than a patch in IZ) in case you
> expect more changes to the first patch version, but has more overhead
> in case your first patch is perfect :)

Okay, I went through some documents introducing to the CWS concept. In
case using a CWS to apply my changes, I'll need to checkout the most
recent milestone via cwsquery, create the CWS via cwscreate, apply my
changes locally to the CWS and commit them to the CWS via a CVS commit,
but I'll need to get an CWS account, right? How do I get the account?
Possibly the driver needs some more adoptions then I thought at first,
so doing the integration the CWS way is probably preferable.

Best regards,
Micha



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

Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Frank Schönheit - Sun Microsystems Germany]

Hi Michael,

> It's been a while since I wrote to the mailing list last time, because I
> was on vacation. You may remember that we were working on a driver. We
> are finished with the driver so far and would like to integrate it into
> the core code base. Probably we need to do some small changes to code to
> integrate it in base's connection dialog and some more stuff. What is
> the current OOo built which should be used as foundation for this? I
> will submit an issue with type enhancement or feature with code patches
> if this is what you need for integration into the core code base.

DEV300 m31 is the most recent milestone (m32 is the first SVN-based
milestone, not sure when it will finally be released).

If you want, we can create a CWS based on this milestone, and commit
your changes (or you can do yourself, if you want, after we granted you
permissions to do so). Any adjustments which are possibly needed can
then happen in this CWS, and we can fine-tune it without disturbing
other development.

Such a dedicated CWS would be easier (than a patch in IZ) in case you
expect more changes to the first patch version, but has more overhead in
case your first patch is perfect :)

Your decision.

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: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

Hello Frank and Ocke, 

It's been a while since I wrote to the mailing list last time, because I
was on vacation. You may remember that we were working on a driver. We
are finished with the driver so far and would like to integrate it into
the core code base. Probably we need to do some small changes to code to
integrate it in base's connection dialog and some more stuff. What is
the current OOo built which should be used as foundation for this? I
will submit an issue with type enhancement or feature with code patches
if this is what you need for integration into the core code base.

> Submit an issue in IssueZilla, attach your changes. They'll be
> reviewed, possibly you'll be asked to do some changes, and then we'll
> take care of integrating it.

Best regards,
Micha

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

Re: AW: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Ocke Janssen]

Hi Micha,

Michael Strobel wrote:

Hi Ocke,

  

I'm back :-)



That's great news, at least me ;-) Hope you had a good vacation.
  

Yes, Indeed I became a father. So less sleep. :-)
  

First of all I have to clarify that default values which you enter
in the table design window are never propagated to the driver.
These default values are only UI values which will be shown when
you open the table to add data.
What may me confuse is the fact that your alter command is called.
Normally I would argue that some props of the column type has
changed. May be the problem is databasemetadata::getColumns for
that table (type nfo of the column), but that is only a guess.



What could be the problem with properties of the column type
exactly? If it is because of a difference between the result of
getTypeInfo() and getColumns() this is likely a fault in our JDBC
driver, which explains why the problem does not appear with MySQL
and the SDBC-JDBC bridge, but as far as I could see the problem is
independent of the column type. I'll check that and the results of
the both methods.
  
I only thought that this could be the problem of the alter statement. 
The table design checks if any changes happen. The best place to look at 
is :DoSave in TableController.cxx in dbacces or alterColumns.


- oj

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]

AW: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

Hi Ocke,

> I'm back :-)

That's great news, at least me ;-) Hope you had a good vacation.

> First of all I have to clarify that default values which you enter
> in the table design window are never propagated to the driver.
> These default values are only UI values which will be shown when
> you open the table to add data.
> What may me confuse is the fact that your alter command is called.
> Normally I would argue that some props of the column type has
> changed. May be the problem is databasemetadata::getColumns for
> that table (type nfo of the column), but that is only a guess.

What could be the problem with properties of the column type
exactly? If it is because of a difference between the result of
getTypeInfo() and getColumns() this is likely a fault in our JDBC
driver, which explains why the problem does not appear with MySQL
and the SDBC-JDBC bridge, but as far as I could see the problem is
independent of the column type. I'll check that and the results of
the both methods.

Best regards,
Micha

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

Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Ocke Janssen]

Moin Micha,


Michael Strobel wrote:

Hi Frank,

  

The table designer is in dbaccess/source/ui/tabledesign. Saving a
changed design is centrally done in OTableController::alterColumns -
this is where I would start.

For the various column classes involved ... I'm not sure which of the
ones in dbaccess/source/core/api would be the best to start with (Ocke
would be able to answer this more precise, but he's still on


vacation),
  

I'm back :-)

I suggest you simply touch every file with "column" in its name, and
every file which a "grep DEFAULT *" mentiones, build them with
"debug=1", and let the debugger guide you, starting from the
aforementioned alterColumns method.



I managed to compile the dbaccess module with debug information, but I'm
still stuck with the bug because I do not really understand the code in
dbaccess and what's going on in there. Do you know when Ocke will be
back from vacation? Maybe he might have a clue as you said.

Looks like OColumnSettings in dbaccess/source/core/api/column.cxx is
used to work with the column specific information that is stored in the
base document, while m_aControlDefault holds the default value and
OTableController in dbaccess/source/ui/tabledesign/TableControler.cxx
has alterColumns(), which is called when you hit the save button in
Base's table designer for altering the column specific information.

I also need to say that the problem appears only when altering a column
default, but not when I add a new column with a default to an existing
table.
  
First of all I have to clarify that default values which you enter in 
the table design window are never propagated to the driver. These 
default values are only UI values which will be shown when you open the 
table to add data.
What may me confuse is the fact that your alter command is 
called.Normally I would argue that some props of the column type has 
changed. May be the problem is databasemetadata:.getColumns for that 
table (type nfo of the column), but that is only a guess.


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: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

Hi Frank,

> The table designer is in dbaccess/source/ui/tabledesign. Saving a
> changed design is centrally done in OTableController::alterColumns -
> this is where I would start.
>
> For the various column classes involved ... I'm not sure which of the
> ones in dbaccess/source/core/api would be the best to start with (Ocke
> would be able to answer this more precise, but he's still on
vacation),
> I suggest you simply touch every file with "column" in its name, and
> every file which a "grep DEFAULT *" mentiones, build them with
> "debug=1", and let the debugger guide you, starting from the
> aforementioned alterColumns method.

I managed to compile the dbaccess module with debug information, but I'm
still stuck with the bug because I do not really understand the code in
dbaccess and what's going on in there. Do you know when Ocke will be
back from vacation? Maybe he might have a clue as you said.

Looks like OColumnSettings in dbaccess/source/core/api/column.cxx is
used to work with the column specific information that is stored in the
base document, while m_aControlDefault holds the default value and
OTableController in dbaccess/source/ui/tabledesign/TableControler.cxx
has alterColumns(), which is called when you hit the save button in
Base's table designer for altering the column specific information.

I also need to say that the problem appears only when altering a column
default, but not when I add a new column with a default to an existing
table.

Best regards,
Micha

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

RE: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

Hi Frank,

> Hmm - you couldn't reproduce the default values vanishing, or you
> couldn't reproduce the default values not being passed to the driver?

I couldn't reproduce the vanishing. The defaults were saved correctly
when connecting via the SDBC-JDBC bridge to MySQL or via OOo's MySQL
driver. However, when connecting to Ingres via the SDBC-JDBC bridge or
using my driver the vanishing appears.

Playing around with the drivers a bit more I also recognized folloing:
When changing default values and using OOo/MySQL the method
OMySQLTable::alterColumnByName is not even called, which makes sense as
this doesn't require to execute anything on the database, but when using
OOo/Ingres OIngresTable::alterColumnByName is called.

> Sounds a little bit like there lingers another bug somewhere ...
> 
> The table designer is in dbaccess/source/ui/tabledesign. Saving a
> changed design is centrally done in OTableController::alterColumns -
> this is where I would start.
> 
> For the various column classes involved ... I'm not sure which of the
> ones in dbaccess/source/core/api would be the best to start with (Ocke
> would be able to answer this more precise, but he's still on
> vacation),
> I suggest you simply touch every file with "column" in its name, and
> every file which a "grep DEFAULT *" mentiones, build them with
> "debug=1", and let the debugger guide you, starting from the
> aforementioned alterColumns method.

Thanks for this. I will try get further from there.

Best regards,
Micha

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

Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Frank Schönheit - Sun Microsystems Germany]

Hi Michael Strobel wrote:

> There is no issue for this, because I wanted to get sure that this is
> problem is not related to our driver. Since I couldn't reproduce the
> behavior with MySQL today, but only with Ingres I'm not quite sure about
> that. On the one hand the default values are not saved by the driver to
> .odb, are they? On the other hand I couldn't reproduce it with MySQL.

Hmm - you couldn't reproduce the default values vanishing, or you
couldn't reproduce the default values not being passed to the driver?

> The exact behavior of OOo/Ingres is like this:
> 
> The default values are saved properly when I create a new table. If I
> try to change the default values in an existing table only the default
> value of the last column of the table is changed successfully. Moreover
> this doesn't seem to be saved to the .odb, as the default values are
> reset when the connection is closed and reopened.
> 
> Any suggestions what would be a good start for digging further into
> this?

Sounds a little bit like there lingers another bug somewhere ...

The table designer is in dbaccess/source/ui/tabledesign. Saving a
changed design is centrally done in OTableController::alterColumns -
this is where I would start.

For the various column classes involved ... I'm not sure which of the
ones in dbaccess/source/core/api would be the best to start with (Ocke
would be able to answer this more precise, but he's still on vacation),
I suggest you simply touch every file with "column" in its name, and
every file which a "grep DEFAULT *" mentiones, build them with
"debug=1", and let the debugger guide you, starting from the
aforementioned alterColumns method.

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: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

Hi Frank


> IIRC (it's a while since I last stepped through this code), the
> problem is that we the default value entered in the UI is stuck in the
> higher layers. We remember it in the ODB file (as part of the column
> settings), but we never pass it to the driver.
>
> Thus, the default value is "lost" before any SQL statements are
> generated and sent to the driver.

So that's why there is no "default ..." in the trace output. Since no
default value is passed to the driver it is never put it into any
statement. I could verify that, by looking at the corresponding
variables in the driver, which seem to be empty all the time.

> I don't remember the exact details, but there was something why a fix
> wasn't as easy as just passing the value down to the driver. Would
> need some time to investigate the relationship of the various default
> values ... Do we already have an issue for this?

There is no issue for this, because I wanted to get sure that this is
problem is not related to our driver. Since I couldn't reproduce the
behavior with MySQL today, but only with Ingres I'm not quite sure about
that. On the one hand the default values are not saved by the driver to
.odb, are they? On the other hand I couldn't reproduce it with MySQL.

The exact behavior of OOo/Ingres is like this:

The default values are saved properly when I create a new table. If I
try to change the default values in an existing table only the default
value of the last column of the table is changed successfully. Moreover
this doesn't seem to be saved to the .odb, as the default values are
reset when the connection is closed and reopened.

Any suggestions what would be a good start for digging further into
this?

Best regards,
Micha

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

Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Frank Schönheit - Sun Microsystems Germany]

Hi Michael,

> I'm still confused what is happening to the default values in Base. You
> mentioned before that they never appear in the database and are stored
> in the base document instead. Seems to be correct, they do never appear
> in the database, but how is that done?

IIRC (it's a while since I last stepped through this code), the problem
is that we the default value entered in the UI is stuck in the higher
layers. We remember it in the ODB file (as part of the column settings),
but we never pass it to the driver.

Thus, the default value is "lost" before any SQL statements are
generated and sent to the driver.

I don't remember the exact details, but there was something why a fix
wasn't as easy as just passing the value down to the driver. Would need
some time to investigate the relationship of the various default values
... Do we already have an issue for this?

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: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

Hi Frank,

> small misunderstanding - supplying the default from within the driver
> is exactly the item which we don't have an infrastructure for. We can
> easily add a setting to database documents, default it so that the
> current behavior is unchanged - but then everybody creating an .odb
> for your database type, using your driver, needs to (once) change this
> setting.

That's still better than showing the dialog (in our case).

I'm still confused what is happening to the default values in Base. You
mentioned before that they never appear in the database and are stored
in the base document instead. Seems to be correct, they do never appear
in the database, but how is that done? As far as I can see the drivers
in the connectivity module all have methods like alterDefaultValue(),
dropDefaultValue() in their Table class, which are at least called from
alterColumnByName() and execute an respective SQL statements to alter
default values. I have tried to implement this in our driver, but when I
look at the trace output of our JDBC driver such a statement is never
executed and default values are not always changed correctly. Similar
with the create table statements, they should contain a string "default
..." but it never appears in the trace output. Do you perform some extra
parsing of the statements before they are sent to the 'real' driver,
remove the default stuff and save it to the database documents?

Best regards,
Micha

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

Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Frank Schönheit - Sun Microsystems Germany]

Hi Michael,

> A flag saved at the data source / database document and supplying it's
> default from within the driver is absolutely sufficient for our needs.
> :-)

small misunderstanding - supplying the default from within the driver is
exactly the item which we don't have an infrastructure for. We can
easily add a setting to database documents, default it so that the
current behavior is unchanged - but then everybody creating an .odb for
your database type, using your driver, needs to (once) change this setting.

> Do you intend to change the driver infrastructure of
> OOo at the near future nevertheless?

No, that's more a plan, which commemorates itself from time to time,
exactly when we notice that the current architecture is too inflexible
in some respects.

> I have compiled our driver according to the software requirements on
> http://tools.openoffice.org/dev_docs/build_linux.html#BuildInstructions
> on a RHEL4 and tried to install it in OOo 2.4 and 2.4.1 on different
> Linux distributions. If I install OOo from the install packages on
> www.openoffice.org everything works fine, but if I install it from the
> software repositories of the distributions OOo freezes when I try to
> connect to a database. Is this expected? Do I need to compile the driver
> in a special way to support the OOo builds in the software repositories
> of the distributions? Are they doing such big changes to their builds so
> that the driver won't work with them? I didn't realize that before.
> Would be nice to have only one driver for the x86 Linux platform
> independent of the distribution, if possible.

Nice, but quite impossible. The Linux distributions can do all kind of
change to their build environment which will make your driver fail. The
most simple change: They usually use a much more up-to-date compiler
than the vanilla OOo builds use, simply because they do not need to care
for baseline requirements (Vanilla has a much wider range of target
systems, where the distribution's build of OOo just needs to run on this
distribution).

One more reason for including the driver in the core code - in this
case, everybody building an OOo with own build environment will
automatically also build your driver properly.

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: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Frank Schönheit - Sun Microsystems Germany]

Hello Michael,

> I didn't do any changes at Base's code base outside the driver so far,
> but nevertheless we would definitely like to contribute the driver back
> to the core code base :-)

Fine, that's welcome

> Most of the driver's functionality work's
> fine, we are still doing a lot of quality assurance, but possibly there
> is a chance to get the driver into the next release. Can you tell me
> what the usual procedure when contributing something back to the core
> code base is?

submit an issue in IssueZilla, attach your changes. They'll be reviewed,
possibly you'll be asked to do some changes, and then we'll take care of
integrating it.

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: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

Hi Frank,

Nearly forgot that:

> If the problem would only be the missing warning, I'd vote for adding
> it to the dialog which asks the user (which would be a Good Thing
> (TM), anyway) ..
> 
> There's no mechanism in place to disable the feature. We can introduce
> one, though I fear you have no time to wait for what I would consider
> the cleanest solution ;-) (namely creating an infrastructure for
> drivers to be deployed into OOo, together with a set of configuration
> based "meta-data" about the supported functionality of the driver).
> 
> Usually, disabling (or changing) a certain behavior is done by flags
> saved at the data source / database document. Would this be sufficient
> for you? I.e., everybody creating a new database document using your
> driver would need to do this setting once. (And perhaps we can
> introduce a mechanism to let the driver tell defaults for certain
> settings.)

A flag saved at the data source / database document and supplying it's
default from within the driver is absolutely sufficient for our needs.
:-)

> Alternatively, it would be possible to let the driver in general tell
> that a certain UI feature is disabled, but as said, there's no
> infrastructure in place for this at all - we would need to respect
> both the data source and the driver settings, where currently only
> data source settings are respected.

I couldn't figure out how large the difference in development effort is,
but from what have written I rather tend to your first suggestion at the
moment. Maybe your second suggestion could be implemented as long term
solution later on. Do you intend to change the driver infrastructure of
OOo at the near future nevertheless? I think I have seen a document
regarding this somewhere on www.openoffice.org, but I didn't realize if
it was more a conceptual idea or the really intended approach for future
releases of OOo.

And one more question, again ;-)

I have compiled our driver according to the software requirements on
http://tools.openoffice.org/dev_docs/build_linux.html#BuildInstructions
on a RHEL4 and tried to install it in OOo 2.4 and 2.4.1 on different
Linux distributions. If I install OOo from the install packages on
www.openoffice.org everything works fine, but if I install it from the
software repositories of the distributions OOo freezes when I try to
connect to a database. Is this expected? Do I need to compile the driver
in a special way to support the OOo builds in the software repositories
of the distributions? Are they doing such big changes to their builds so
that the driver won't work with them? I didn't realize that before.
Would be nice to have only one driver for the x86 Linux platform
independent of the distribution, if possible.

Best regards,
Micha

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

RE: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

Hi Frank,

> Which brings me to the following question: What you do currently - is
> this intended to be contributed back to the core code base? That is,
> if you do changes to Base's code base outside your driver, then you
> would either need to build an own OOo containing those changes, or
> contribute them to the project for inclusion in the next release.

I didn't do any changes at Base's code base outside the driver so far,
but nevertheless we would definitely like to contribute the driver back
to the core code base :-) Most of the driver's functionality work's
fine, we are still doing a lot of quality assurance, but possibly there
is a chance to get the driver into the next release. Can you tell me
what the usual procedure when contributing something back to the core
code base is?

Best regards,
Micha


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

Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Frank Schönheit - Sun Microsystems Germany]

Hello Michael,

> I would like to prevent that OOo Base asks if it should delete a column
> and append a new one, when the column definition can't be modified. Is
> it possible to do this from within the driver or switch it of in one of
> Base's option dialogs (I didn't see anything like this, but maybe I
> overlooked it)? There are two problems with this. First is that if the
> user has entered data into the column before the data is gone when the
> column is deleted and OOo Base shows no respective warning. Second is
> that in certain cases Ingres can't append a column to an existing table,
> for example if the column is not null and it has no default value. So I
> think it would be better to disable this feature when using Ingres.

If the problem would only be the missing warning, I'd vote for adding it
to the dialog which asks the user (which would be a Good Thing (TM),
anyway) ..

There's no mechanism in place to disable the feature. We can introduce
one, though I fear you have no time to wait for what I would consider
the cleanest solution ;-) (namely creating an infrastructure for drivers
to be deployed into OOo, together with a set of configuration-based
"meta-data" about the supported functionality of the driver).

Usually, disabling (or changing) a certain behavior is done by flags
saved at the data source / database document. Would this be sufficient
for you? I.e., everybody creating a new database document using your
driver would need to do this setting once. (And perhaps we can introduce
a mechanism to let the driver tell defaults for certain settings.)

Alternatively, it would be possible to let the driver in general tell
that a certain UI feature is disabled, but as said, there's no
infrastructure in place for this at all - we would need to respect both
the data source and the driver settings, where currently only data
source settings are respected.

Which brings me to the following question: What you do currently - is
this intended to be contributed back to the core code base? That is, if
you do changes to Base's code base outside your driver, then you would
either need to build an own OOo containing those changes, or contribute
them to the project for inclusion in the next release.

The feasibility of different solutions depends on how you want to handle
this.

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: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

Hi Frank,

> Is there a possibility to add some kind of "compatibility switch" to
> your DB's JDBC driver? That is, your wrapping driver could add some
> parameter (like "report-sequences-as-auto-increment=true" or whatever
> fancy name you can imagine) to the connection URL, and your JDBC
> driver would use this to control the behavior of isAutoIncrement.

I think this would be possible, but unfortunately our JDBC driver guy is
not very happy with introducing this change in the JDBC driver at the
moment.
 
> If this doesn't work, I would vote for introducing a generic mechanism
> in OOo's JDBC bridge (let me call it "bridge" instead of "driver",
> since it effectively bridges from JDBC to SDBC, and to not confuse it
> with a "real" JDBC driver) for manipulating the result set meta data,
> and then employ this mechanism from your wrapping driver.
> 
> As an example, consider the type info returned by the
> DatabaseMetaData.
> The JDBC bridge (and in particular the ODatabaseMetaDataBase class in
> connectivity/source/commontools/TDatabaseMetaDataBase.cxx) supports a
> setting "TypeInfoSettings" (passed in the PropertyValue sequence upon
> connecting), which is used to effectively transform the type
> information as retrieved from the database. So, if we have a
> database/setup which needs to fake the type information, this (to a
> certain extent) can be done by simply creating a proper
> TypeInfoSettings value.
> 
> Something similar could perhaps be done for the result set meta data.
> If we have a setting which captures the "when the default value of a
> column is 'sequence_name.nextval', then return 'true' in
> isAutoIncrement" rule, then your wrapping driver could pass this
> setting to the JDBC driver.
> 
> I suppose the RowFunctionParser in
> connectivity/source/*/RowFunctionParser.* already does almost or all
> of what is needed to create such a rule. Then only the
> ResultSetMetaData implementation of the JDBC bridge needs to accept
> and respect such a setting.

Sounds great, this is a far more neat approach than anything that came
to my mind. I have duplicated all the classes of the JDBC bridge in my
driver now, which works fine, but it is really nasty considering the
code duplication. Before starting anything new I need discuss this with
my project leader, who was on vacation for the last week and should be
back at work tomorrow.

One more thing:

I would like to prevent that OOo Base asks if it should delete a column
and append a new one, when the column definition can't be modified. Is
it possible to do this from within the driver or switch it of in one of
Base's option dialogs (I didn't see anything like this, but maybe I
overlooked it)? There are two problems with this. First is that if the
user has entered data into the column before the data is gone when the
column is deleted and OOo Base shows no respective warning. Second is
that in certain cases Ingres can't append a column to an existing table,
for example if the column is not null and it has no default value. So I
think it would be better to disable this feature when using Ingres.

Best regards,
Micha

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

Re: AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Frank Schönheit - Sun Microsystems Germany]

Hi Michael,

> first of all thanks for your response. I think I forgot to tell this,
> as I'm usuallyworking from Monday to Wednesday or Thursday only,
> it may take some time till I respond to the mails here.

As you might have noticed, my answers are delayed, too - I do not work
on Fridays, and sometimes not on Thursdays (parental part time, or
however this is called in English).

> Now towards the weird driver architecture. You are right, my driver
> does not inherit from the MySQL driver, it's rather inspired by the
> MySQL driver and wraps around the driver I inherit from the JDBC driver.
> The wrapping is to provide some SDBCX services in addition to the SDBC
> services of the driver I inherit from the JDBC driver, pretty similar to
> the MySQL driver providing SDBCX services in addition to the SDBC
> services of JDBC driver.

Okay, this part is slightly ugly, but hard too improve without
reasonable effort.

> The inheritance from the JDBC driver is mainly
> to overwrite the isAutoIncrement() Method of the XResultSetMetaData
> interface which the JDBC driver implements.

Now this part is *really* ugly :)

The JDBC driver can change in its ABI at any time without notice, since
it's considered an internal component. When you have a driver which
links against the JDBC driver and is not part of the core source tree,
this driver will sooner or later become non-functional.

Also, even if your driver where part of the core source, I would have
headaches with exporting all its classes and implementation structure
"just" to override such a single facet.


Is there a possibility to add some kind of "compatibility switch" to
your DB's JDBC driver? That is, your wrapping driver could add some
parameter (like "report-sequences-as-auto-increment=true" or whatever
fancy name you can imagine) to the connection URL, and your JDBC driver
would use this to control the behavior of isAutoIncrement.

If this doesn't work, I would vote for introducing a generic mechanism
in OOo's JDBC bridge (let me call it "bridge" instead of "driver", since
it effectively bridges from JDBC to SDBC, and to not confuse it with a
"real" JDBC driver) for manipulating the result set meta data, and then
employ this mechanism from your wrapping driver.

As an example, consider the type info returned by the DatabaseMetaData.
The JDBC bridge (and in particular the ODatabaseMetaDataBase class in
connectivity/source/commontools/TDatabaseMetaDataBase.cxx) supports a
setting "TypeInfoSettings" (passed in the PropertyValue sequence upon
connecting), which is used to effectively transform the type information
as retrieved from the database. So, if we have a database/setup which
needs to fake the type information, this (to a certain extent) can be
done by simply creating a proper TypeInfoSettings value.

Something similar could perhaps be done for the result set meta data. If
we have a setting which captures the "when the default value of a column
is 'sequence_name.nextval', then return 'true' in isAutoIncrement" rule,
then your wrapping driver could pass this setting to the JDBC driver.

I suppose the RowFunctionParser in
connectivity/source/*/RowFunctionParser.* already does almost or all of
what is needed to create such a rule. Then only the ResultSetMetaData
implementation of the JDBC bridge needs to accept and respect such a
setting.

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]

AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

Hi Frank,

> 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.

I realized that, but it also makes me wondering why it seems to work
well with HSQLDB, but not with MySQL and Ingres, in case the code is
the same. I will try to dig a bit more into that and enter a issue for
it.

Best regards,
Micha

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

AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

Hi Frank,

first of all thanks for your response. I think I forgot to tell this,
as I'm usuallyworking from Monday to Wednesday or Thursday only,
it may take some time till I respond to the mails here.

Now towards the weird driver architecture. You are right, my driver
does not inherit from the MySQL driver, it's rather inspired by the
MySQL driver and wraps around the driver I inherit from the JDBC driver.
The wrapping is to provide some SDBCX services in addition to the SDBC
services of the driver I inherit from the JDBC driver, pretty similar to
the MySQL driver providing SDBCX services in addition to the SDBC
services of JDBC driver. The inheritance from the JDBC driver is mainly
to overwrite the isAutoIncrement() Method of the XResultSetMetaData
interface which the JDBC driver implements. This is because Ingres does
not know autoincrement columns such as MySQL, but it knows sequences
which allow us to fake autoincrement columns. To do so instead of put
the word "auto_increment" behind the datatype in the create table
statement executed from OOo Base, we create a sequence which produces
the autoincrement values and assign "sequence_name.nextval" as default
value to the column that should behave like an autoincrement column by
putting "default value sequence_name.nextval" behind the datatype in
the create table statement. The problem is that the underlying Ingres
JDBC driver for the SDBC-JDBC bridge driver will always return false for
isAutoIncrement(), which is used by OOo Base to determine whether a
column should be displayed as autoincrement column in the table editing
view or forms, but we need it to return true for columns with the
default value "sequence_name.nextval", so we overwrite it accordingly.

I hope this helps to understand what I'm doing. As said before, I have
no better idea to resolve this problem without inheriting from the JDBC
driver unfortunately.

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

[Frank Schönheit - Sun Microsystems Germany]

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

[Frank Schönheit - Sun Microsystems Germany]

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

[Michael Strobel]

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

[Michael Strobel]

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

[Ocke Janssen]

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

[Michael Strobel]

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.

> - 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.)

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?

Best reagards,
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

[Ocke Janssen]

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_cast
  (static_cast(m_rParent).getPrivateViews());
if (pViews && pViews->hasByName(_ViewName_))
{
  pViews->dropByNameImpl(_ViewName_);
  ContainerEvent aEvent(static_cast(this),
makeAny(_ViewName_), Any(), Any());
  OInterfaceIteratorHelper aListenerLoop(m_aContainerListeners);
  while (aListenerLoop.hasMoreElements())
  {
static_cast
  (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

[Michael Strobel]

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_cast
  (static_cast(m_rParent).getPrivateViews());
if (pViews && pViews->hasByName(_ViewName_))
{
  pViews->dropByNameImpl(_ViewName_);
  ContainerEvent aEvent(static_cast(this),
makeAny(_ViewName_), Any(), Any());
  OInterfaceIteratorHelper aListenerLoop(m_aContainerListeners);
  while (aListenerLoop.hasMoreElements())
  {
static_cast
  (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

[Ocke Janssen]

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

[Michael Strobel]

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]

AW: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

Hi Ocke,

I didn't get the chance to finish the case sensitivity problem with Ingres yet, 
but meanwhile I have discovered other things and probably at least one of them 
is worth an issue.

For some reason Base can't handle values in long varchar columns that exceed a 
length of 65535 characters, although most databases can. Don't know if this is 
desired behavior or not. Possibly this is wanted because some databases, for 
example MS Access, have a limited of 65535 characters for long varchar columns. 
Unfortunately that is not the worst thing I discovered.

Try the following using Base and the SDBC-JDBC driver with MySQL and Ingres 
database: Copy a string that exceeds 65535 characters into a long varchar 
column. The string is cut and a warning is displayed, which is good, but 
surprisingly the string is cut to noticeably less than 65535 characters. The 
exact number of characters to which the string is cut seems depend on how long 
the string you try to insert is.

Then fill the long varchar column with additional characters until you reach 
65535 characters or more and click the save button. Now close the table and 
reopen it. You will see that the value you edited before is erased. I think 
this is be a really bad bug, as it might destroy the users data.

Last but not least, performance. Editing long varchar values in the table view 
is very slow, editing them in forms is a lot better. Maybe this is okay as 
forms work fine and improvement is difficult.

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

[Ocke Janssen]

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

[Michael Strobel]

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

[Ocke Janssen]

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

[Michael Strobel]

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

[Ocke Janssen]

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

[Michael Strobel]

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

[Ocke Janssen]

Hi Micha,

Michael Strobel wrote:
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.
  
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?


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

[Michael Strobel]

> 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

[Ocke Janssen]

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

[Michael Strobel]

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

[Michael Strobel]

>> 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

[Michael Strobel]

> 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.

Best regards,
Micha

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


-
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

[Michael Strobel]

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

[Ocke Janssen]

Moin Micha,

Michael Strobel wrote:

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...
  
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.


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

[Michael Strobel]

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

[Ocke Janssen]

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

[Michael Strobel]

> 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

[Ocke Janssen]

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 Reference(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

[Michael Strobel]

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 Reference(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?

Best regards,

Michael


-
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

[Ocke Janssen]

Moin Michael,

Michael Strobel wrote:

Hi,

the solution for the connection problem was rather simple, but hard to
find without the possibility to debug the component, the prefix
sdbc:ingres: is automatically added to the url string passed to the
connect() method and is not be entered in OOo. How do you debug
components compiled in the OOo SDK build environment?
  
Normally I attach the debugger to the process or start soffice.bin 
directly. But it depends on your operating system ;-)

To add the functionality of some sdbx services to the driver and I have
to implement the corresponding interfaces, but how does OOo recognize
that the interfaces are implemented? 
The driver will be queried for these interfaces. If the result is NULL 
it isn't one :-)

I have added
com.sun.star.sdbcx.Driver to the supported services in the component
description xml file and to the strings in the sequence returned by the
getSupportedServiceNames() method in the driver.cxx, but not implemented
the XDataDefinitionSupplier interface, yet. I can compile the component
and install it, as well as connect to the database using the component.
Why does OOo not complain about the missing implementation?
  
Yes, at least it should assert if the interface is not available. But 
instead it believes that the driver isn't a sdbcx one.
When you implement the sdbcx.Driver you must support the interface 
XDataDefinitionSupplier.


Best regards,

Ocke

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

[Michael Strobel]

Hi,

the solution for the connection problem was rather simple, but hard to
find without the possibility to debug the component, the prefix
sdbc:ingres: is automatically added to the url string passed to the
connect() method and is not be entered in OOo. How do you debug
components compiled in the OOo SDK build environment?

To add the functionality of some sdbx services to the driver and I have
to implement the corresponding interfaces, but how does OOo recognize
that the interfaces are implemented? I have added
com.sun.star.sdbcx.Driver to the supported services in the component
description xml file and to the strings in the sequence returned by the
getSupportedServiceNames() method in the driver.cxx, but not implemented
the XDataDefinitionSupplier interface, yet. I can compile the component
and install it, as well as connect to the database using the component.
Why does OOo not complain about the missing implementation?

Best regards,

Michael

-
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

[Ocke Janssen]

Michael Strobel wrote:

Hi All, Moin Ocke,

first of all I like to thank you all for your efforts in helping and
supporting my attempts to write a driver and especially Ocke for
answering the questions concerning his code in-depth. It's great to see
the community here is that active and fast responding :-) Sorry, that I
was not that fast, but I promise to do better next time.

To Ocke:

  

First of all you have to know which kind of driver you want. I just


look at the code and it looks promising to use either the ODBC or JDBC
in the 
independent way as well.


In fact while experimenting with your code I just focused on the JDBC
part of the code. I will keep this, as you say it is reasonable. 

  
The XUnoTunnel is used to get the implementation of an interface. In 

this case it is used to set the correct URL which should be returned 
when you ask the XDatabaseMetaData::getURL()
So when not doing so, the metadata will return for example the 
jdbc:ingres:xxx and not sdbc:ingres as you may want.


Guess clicking the 'Test Connection' button does among others check the
URL returned on a XDatabaseMetaData::getURL() call against the URL
provided by the user, but I didn't found the code that does this test
until now. Of cause such a test would fail in my current implementation.

  

When removing the code for OMetaConnection don't forget that you have

to 
store the XConnection objects inside the map of connections otherwise
you 
won't get a catalog for it.


I store instantiated XConnection objects in a member variable
m_xConnections of the type std::vector<
::com::sun::star::uno::WeakReferenceHelper > calling
m_xConnections.push_back(WeakReferenceHelper(xConnection)); before
returning from the drivers connect() method at the moment. When the
drivers dispose() method is called I iterate over m_xConnections and
call dispose on connections that are referenced. Did I forget something
here?
  

No. Perfect .-) Of course you clear your vector after iterating.
  

The work around for the URL problem would be to write a own connection



which would forward all calls to the JDBC/ODBC connection except the 
getMetaData() call and to write this one as well. Doing the same 
forwarding thing and just when asking for getURL() return the correct 
one.


Sounds like plan :-) I will try this and keep you informed if this
helps. 

  
When you create a new database file in OOo for mysql and you choose 

mysql jdbc you'll can on the next page select the driver name. So it is 
possible to define different names. By the way I never tried to insert a


different one ;-) Do you try to insert a ingres one?

Yes, I tried that. If I insert the Ingres driver class clicking the
'Test Loading Driver' button the message box says the test was
successful, but when I try to establish a connection a message box says
that the driver class "com.mysql.jdbc.Driver" could not be loaded. I'm
not quite sure if this is a bug in the MySQL driver or not. It seems
like the setting is ignored in the code and the Property Value for
"JavaDriverClass" is hard coded to be "com.mysql.jdbc.Driver".
  
Oh, so let discuss if it is a bug that value is used or that you see a 
field at the tab page :-)



Best regards,

Ocke



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

[Michael Strobel]

Hi All, Moin Ocke,

first of all I like to thank you all for your efforts in helping and
supporting my attempts to write a driver and especially Ocke for
answering the questions concerning his code in-depth. It's great to see
the community here is that active and fast responding :-) Sorry, that I
was not that fast, but I promise to do better next time.

To Ocke:

> First of all you have to know which kind of driver you want. I just
look at the code and it looks promising to use either the ODBC or JDBC
in the 
independent way as well.

In fact while experimenting with your code I just focused on the JDBC
part of the code. I will keep this, as you say it is reasonable. 

> The XUnoTunnel is used to get the implementation of an interface. In 
this case it is used to set the correct URL which should be returned 
when you ask the XDatabaseMetaData::getURL()
So when not doing so, the metadata will return for example the 
jdbc:ingres:xxx and not sdbc:ingres as you may want.

Guess clicking the 'Test Connection' button does among others check the
URL returned on a XDatabaseMetaData::getURL() call against the URL
provided by the user, but I didn't found the code that does this test
until now. Of cause such a test would fail in my current implementation.

> When removing the code for OMetaConnection don't forget that you have
to 
store the XConnection objects inside the map of connections otherwise
you 
won't get a catalog for it.

I store instantiated XConnection objects in a member variable
m_xConnections of the type std::vector<
::com::sun::star::uno::WeakReferenceHelper > calling
m_xConnections.push_back(WeakReferenceHelper(xConnection)); before
returning from the drivers connect() method at the moment. When the
drivers dispose() method is called I iterate over m_xConnections and
call dispose on connections that are referenced. Did I forget something
here?

> The work around for the URL problem would be to write a own connection

which would forward all calls to the JDBC/ODBC connection except the 
getMetaData() call and to write this one as well. Doing the same 
forwarding thing and just when asking for getURL() return the correct 
one.

Sounds like plan :-) I will try this and keep you informed if this
helps. 

> When you create a new database file in OOo for mysql and you choose 
mysql jdbc you'll can on the next page select the driver name. So it is 
possible to define different names. By the way I never tried to insert a

different one ;-) Do you try to insert a ingres one?

Yes, I tried that. If I insert the Ingres driver class clicking the
'Test Loading Driver' button the message box says the test was
successful, but when I try to establish a connection a message box says
that the driver class "com.mysql.jdbc.Driver" could not be loaded. I'm
not quite sure if this is a bug in the MySQL driver or not. It seems
like the setting is ignored in the code and the Property Value for
"JavaDriverClass" is hard coded to be "com.mysql.jdbc.Driver".

Best regards,

Michael

-
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

[Ocke Janssen]

Moin Michael,

first of all great to hear that you want to write a driver :-) I'll do 
my best I can to help you at any time.


First of all you have to know which kind of driver you want. I just look 
at the code and it looks promising to use either the ODBC or JDBC in the 
independent way as well.


Michael Strobel wrote:

Hi,

I try to develop a SDBC driver for Ingres and OOo, as the SDBC-ODBC and the 
JDBC-ODBC driver both support the features of the com.sun.start.sdbc.Driver, 
but not those of the com.sun.start.sdbcx.Driver service. What I like to do, is 
to implement a SDBC driver similar to the one in the OOo source code for MySQL, 
which uses the functionality of the SDBC-ODBC or the SDBC-JDBC driver and add 
features of the the com.sun.start.sdbcx.Driver service as far as possible.

Currently I managed to compile the driver skeleton from the OOo SDK and install the resulting component in OOo, which gives me an entry in the available drivers list, but of couse no real driver functionality. I already tried to simply copy the source code of the SDBC driver for MySQL and to adapt it, but I was not able to compile the source code, because I use the OOo SDK, but the source code includes some header files from the OOo source itself and just adding them to the include path or copying them to the OOo SDK gives a missing external symbol, as I do not know what lib is to link and how to do this. 
  

That the first step. Good.
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? 
  
First you should copy the YDriver.(hc)xx files. Remove/(Comment it out) 
or replace all code which doesn't compile. For example replace the 
defines with the real code. http://lxr.go-oo.org/ is a nice tool to search.


As I am a newbie to UNO programming I also have some questions concerning the implementation of the SDBC driver for MySQL. So far I can see the the SDBC-ODBC or the JDBC-ODBC driver is loaded when the connect() Method is invoked, but I don't  understand why the XUnoTunnel and the OMetaConnection object is needed in this Method. I tried to set up a connection omitting all steps concerning the XUnoTunnel and the OMetaConnection object, but it didn't work, so this seems to be something essential for establishing a connection that way. Could you please give me some hints on this? 
The XUnoTunnel is used to get the implementation of an interface. In 
this case it is used to set the correct URL which should be returned 
when you ask the XDatabaseMetaData::getURL()
So when not doing so, the metadata will return for example the 
jdbc:ingres:xxx and not sdbc:ingres as you may want.


When removing the code for OMetaConnection don't forget that you have to 
sore the XConnection objects inside the map of connections otherwise you 
won't get a catalog for it.
The work around for the URL problem would be to write a own connection 
which would forward all calls to the JDBC/ODBC connection except the 
getMetaData() call and to write this one as well. Doing the same 
forwarding thing and just when asking for getURL() return the correct 
one. May be I was a little bit lazy when implementing the mysql driver ;-)

I also don't understand why there is a map for multiple JDBC drives from 
different driver classes. Shouldn't there only be one JDBC driver from one 
driver class loaded by the SDBC-JDBC driver at any time?
  
When you create a new database file in OOo for mysql and you choose 
mysql jdbc you'll can on the next page select the driver name. So it is 
possible to define different names. By the way I never tried to insert a 
different one ;-) Do you try to insert a ingres one?

Regards,
Michael
  
So if you have question please feel free to ask. By the way I would 
prefer the independent way, just a little bit more coding but therefore 
everybody using a OOo2.x can use it otherwise you have to wait for 3.0.


Best regards,

Ocke


-
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

[Frank Schönheit - Sun Microsystems Germany]

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]

Re: [dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Ariel Constenla-Haile]

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

[Joerg Budischewski]

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=dev&msgNo=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

[Ariel Constenla-Haile]

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=dev&msgNo=1324), a 
driver developed/build this way *may* be broken in the 3-layer OOo.


that link is wrong, it should be:
http://extensions.openoffice.org/servlets/ReadMsg?list=dev&msgNo=1322

The important point there:
The change toward Three Layer Office (starting with DEV300m4, see 
) 
has made ever more obvious what had always been true---extensions can 
only link against URE libraries (mainly sal, salhelper, cppu, cppuhelper 
and any STLport and C++ runtime libraries coming with OOo---but see 
above, of course), not against OOo-specific ones (like vcl or tl).  See 
 for 
background information.




--
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

[Ariel Constenla-Haile]

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=dev&msgNo=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]

[dba-dev] writing a new SDBC(X) driver, similar to the MySQL driver

[Michael Strobel]

Hi,

I try to develop a SDBC driver for Ingres and OOo, as the SDBC-ODBC and the 
JDBC-ODBC driver both support the features of the com.sun.start.sdbc.Driver, 
but not those of the com.sun.start.sdbcx.Driver service. What I like to do, is 
to implement a SDBC driver similar to the one in the OOo source code for MySQL, 
which uses the functionality of the SDBC-ODBC or the SDBC-JDBC driver and add 
features of the the com.sun.start.sdbcx.Driver service as far as possible.

Currently I managed to compile the driver skeleton from the OOo SDK and install 
the resulting component in OOo, which gives me an entry in the available 
drivers list, but of couse no real driver functionality. I already tried to 
simply copy the source code of the SDBC driver for MySQL and to adapt it, but I 
was not able to compile the source code, because I use the OOo SDK, but the 
source code includes some header files from the OOo source itself and just 
adding them to the include path or copying them to the OOo SDK gives a missing 
external symbol, as I do not know what lib is to link and how to do this. 

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? 

As I am a newbie to UNO programming I also have some questions concerning the 
implementation of the SDBC driver for MySQL. So far I can see the the SDBC-ODBC 
or the JDBC-ODBC driver is loaded when the connect() Method is invoked, but I 
don't  understand why the XUnoTunnel and the OMetaConnection object is needed 
in this Method. I tried to set up a connection omitting all steps concerning 
the XUnoTunnel and the OMetaConnection object, but it didn't work, so this 
seems to be something essential for establishing a connection that way. Could 
you please give me some hints on this? I also don't understand why there is a 
map for multiple JDBC drives from different driver classes. Shouldn't there 
only be one JDBC driver from one driver class loaded by the SDBC-JDBC driver at 
any time?

Regards,
Michael


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