Hi Ariel and Frank,
@Frank: Again, thanks for your help and your explanations.
@Ariel:
public final class MyObjectFactory extends WeakBase {
private final XComponentContext m_xContext;
public MyObjectFactory(XComponentContext context) {
m_xContext = context;
}
Hi Ariel,
I assume everything is fine in OOo Base/Java UNO framework side.
May be something is wrong somewhere in your code (or something is horribly
broken in OOo side)... hard to guess without seeing your code.
Since nobody experienced this problem with the XComponentContext before I guess
Hi Frank,
I'm a bit confused. Actually our driver extension is written in Java, but I
guess getting the XComponentContext should be the same as if it were written in
C and most of the code for providing the entry point to it was generated by
NetBeans, so I didn't have to care much about it. I
Hi Frank,
Thanks for your answer. The StringResourceWithLocation service is exactly what
I was looking for. I also found some helpful example code under
http://markmail.org/message/sv2z4cvsgmgyctht, but it does not work yet because
I do need a Component Context which I do not have (the drivers
Hi All,
I'm looking for a possiblity to provide the user with custom exception messages
in a database driver extension, according to the locale of his
installation/system. The prefered solution from my side would be to provide the
messages strtings in some sort of plain text ressource file(s)
Hi Fernand,
That the behavior I´m expecting, but since the default values and column
descriptions are not saved to the odb file, I assume there is something missing
in our driver, but I have no idea what it is. Maybe the ControlDefault has to
be set to the DefaultValue when the DetaultValue
Hi Fernand,
The information is definitly stored in the odb file, which is organized like a
zip archiv. On a windows system you might just rename the whatever.odb to
whatever.zip and extract it´s contents with the explorer. If you do so, you
should find a file named content.xml, that seems to
Hi @All,
I have done a complete rewrite of our Ingres driver with the OOo SDK and Java.
It seems to work pretty well despite two issues. I found a workaround for the
first issue, but I could not solve the second issue yet. It´s about creating
tables using the table creation wizard. I will
-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
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
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
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.
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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 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 :-)
30 matches
Mail list logo
