Am Mittwoch, den 20.06.2007, 17:07 -0400 schrieb Jahn, Ray (R.): > Dear Marc:
Hi Ray, > Thanks for suggestions. > > > 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? > > If I am not mistaken, all these approaches eventually lead to the same > issue of conversion between sdbc.XConnection and java.sql.Connection. > Frank has succinctly summarized the situation in his previous comments. I feared so, too. That's why I suggested thinking over the design again (as far as possible). Other things coming to my mind: - HSQL can run in server mode and would therefor be connectable from .odb and java apps. - simple communication between java app and OO.o can be built by simply using sockets or other IPC (from BASIC too) > Many applications are designed and based solely on the OO Base *.odb > files. The *.odb files are used either as the sole gateway to other > JDBC data sources (MySQL, Oracle, etc.) or as a genuine data source > (embedded HSQLDB). Therefore these applications would not encounter the > need of conversion between sdbc.XConnection and java.sql.Connection. > Unfortunately my business constraints make this approach impractical. So concluding you have some applications in .odb's being data containers of which some are lateron transferred to central server databases? I think reading the references threads would help me develop a deeper understanding ... the biggest problem in helping you is not knowing the existing structure and the contraints given. > > use dirty tricks aka workarounds to achive your goal until the API > solution has made it's way into the code of OO.o. ;) > > > 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 ... > > That is why I was soliciting advice from the OO teams. The OO teams > have established a long term vision on the comprehensive OO > architecture. The OO UNO design is particularly strong in terms of > uniform interface for cross platform and remote invocation. Development > effort (workaround) misaligned with the OO architecture vision might not > be in the best interest of OO growth. Maybe they're on vacation all together? ;) > Regarding the donation, it becomes the old chicken and egg issue. > Employees have to align with company's official line of business > partnership alliance. So we turn to the tried and true "bait and > switch" strategy: demonstrate the benefit in prototype and then pursue > the official adoption. Always an art in subject, easier said than done. > Let us move this item off this technical forum. I'm not applying for that job, I would have mailed you in private if so. I only wanted to name some possibilities. Marc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
