Am Dienstag, den 19.06.2007, 10:33 -0400 schrieb Jahn, Ray (R.): > alternative subjects: (none possible in 2.2.0) > * universal SQL application code > * conversion between java.sql.Connection > and sdbc.XConnection > * Base linked tables > > Dear Frank Schönheit (OO Base team):
I'm neither Frank nor a member of any professional OO.o programming team but rather in a similar situation as you are, using and programming OO.o sometimes. > This is a continuation of previous discussions in various OO forums > [1, 2, 3]. Please redirect me if there is a more approriate forum for > this kind of discussion. > > I have been working on the feasibility of the following integration in > a medium size business environment: > > application (Java) + > GUI (local spreadsheet, OO Calc) + data 1 (local OO Base *.odb) + > data 2 (JDBC RDBMS) + data 3 (JDBC RDBMS) + etc. > > Unfortunately OO (API, Base, Calc) cannot sufficiently support this > integration at present (see references). I am at a cross road now for > the application design. I need to decide a substitute approach before > the OO Base API is enhanced to support the need of medium size > business environment. Some current candidates are: > > * wait for OO API to support Connection and XConnection conversion > > Waiting period is uncertain. > Waiting time is not likely on my side. > > * temporarily directly access the database content in *.odb > by circumventing sdbc.XConnection > > not robust design > anticipate deployment obstacle due to potential financial liability > > * eliminate OO Base *.odb from the integration list > > MS Excel is the default in my business environment. > MS Excel (not OO Calc) will likely be the GUI > if OO Base is eliminated from the integration. > > * switch to MS platform (MS Access, C#, etc.) > > a path of almost impossible return to OO > > * any other paths? * Donate Money or hire some programmer(s) for working at the XConnection- or linked tables-issue -> no waiting. Or tell your client to do so, he surely is saving enough from licence cost using OO.o ... * re-think the design (thin ice - not having followed the details or read all of the references, but ...) E.g. why do you have to fetch the connection from OO.o, wouldn't simply using the same database URL do for the different parts of the application? Maybe embedding OO.o via the OO.o-java-bean can help rearranging the relations between application parts? * write a component in your favourite language for handing over the connection to the java app? (more thin ice - don't know if it's possible to do without API change) * use dirty tricks aka workarounds to achive your goal until the API solution has made it's way into the code of OO.o. ;) HTH somehow, Marc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
