Hi Frank,
Frank Schönheit - Sun Microsystems Germany escribió:
Hello Ariel,
Date calculation is one of the missing things in HSQLDB: there is the
DATEDIFF function, but it lacks of other important function present in
important RDBMS: DATE_ADD, DATE_FORMAT, etc.
Besides, the string formating of dates is made by default to en-US [1].
I found a solution for my personal needs, let me tell you:
...
after all this I wrote my own SQL functions in Java:
...
I send you the JAR file and an ODB to test it.
Hey, this is really cool!
And brings me to: Did you already play with making this an extension? As
I understand it, you should be able to create an .oxt which contains the
JAR, and thus adds the functions to any OOo installation.
Yes, and added some things:
1. add a AWT dialog with an edit control to display the .script
content (it shows in its first lines the create alias ... statements).
What I do is dump the script in the user temp. dir., read the
content, and display it in the dialog. The user can save the script via
FilePicker where he/she wants.
2. add an own configuration schema to store user preferences (for
example to decide if he/she wants an XJob to create the aliases every
time he/she opens an embedded db., aliases, etc.)
3. add a tool bar button to execute the CREATE ALIAS FOR "..."
commands ( read the ALIASes and the function names from the extension
configuration node)
4. add a wizard where the user can choose which aliases to
create/execute for the functions shipped with the extension, and he/she
can add his/her own functions (or simply change the aliases I suggested,
or give new/localized aliases to HSQLDB functions). All this is to be
written into the extension's configuration node path
Some problems I've found and I'm working in them:
* Unfortunatelly, I've tried to get the locale for the date formatting
functions from OOo configuration node; but I've experienced some
crashes, so I get the default/system locale of the JVM, what isn't
really a "prytty thing", because OOoLocale and the JVM default locale
CAN BE DIFFERENT.
My hypothesis: we have to proccesses, HSQLDB and OOo. When my Java
methods are invoked from OOo, it's HSQLDB that invokes them. In order to
get the locale from the configuration, I must bootstrap the Office,
because I don't get any XComponentContext or any other OOo API interface
to get the Service manager as I would have if my extension component was
called from the ProtocolHandler or the Job environment: it's HSQLDB who
is invoking them, NOT OOo.
I guess it crashes when I try to bootstrap because HSQLDB can't
find/load the API JARs.
So, I should ship the required JARS with my extension OXT file, as if
it was a client application (?), I should include in my JAR ALL the
classes required for a client app. (?), and should also
include the dymanics libraries for the diferent OSs (?) :-( .
* as in my testing with a database containing some binary files (some
pics == script.length()= 1,565,309) I discovered that the edit control
has some length limits, I added the posibility to directlly open the
script in a Writer doc. instead of the dialog.
The problem here is that the actual length limit
isn't documented in the API refrence, and is independient from the
setMaxTextLen() method in interface
:com::sun::star::awt::XTextComponent, and seems to be binding-dependent
Here I must find the exact max. text length, in order to advise the user
that the script displayed in the AWT isn't fully displayed.
When I finish my reserch, I will ship it as an extension (of course the
jar alone can be shipped, but it is too poor: create the aliases in
every ODB everytime is annoing!).
Bye and thanks
Ariel
--
Ariel Constenla-Haile
La Plata, Argentina
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.arielconstenlahaile.com.ar/ooo/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
