Dear David: It is good to see that OO Base continues to draw the attention from the community who are experienced to both small and large business environments. Frank and many others active in the OO Base community will certainly provide you important advice. Since you mentioned large businesses (multi-national company) as part of intended customers for your financial database applications, I would like to make one simple suggestion that has not received much attention in the database designs for small business or personal applications.
In the USA market, financial and database software products are significantly impacted by the USA Sarbanes-Oxley Act (SOA) [ref. 1]. Due to the potential legal consequences from SOA on company executives, all financial and database products have to prove SOA safe, at least at the level of architecture design, in order to prevent SOA litigation. This guideline generally applies to both internal development and external purchased products. I am sure that Sun Microsystems, currently headquartered in USA and a primary coordinator of OpenOffice development, also implemented its own strategy to prevent SOA legal liability. This legal requirement leads to a technical challenge. In medium to large business environments, there are incumbent database applications managing critical business knowledge. There are robust SQL modules, after millions of dollars and years of field testing, connecting and communicating with various business applications to keep revenue coming. The SQL DB communication is very likely done through one of the popular standard connection protocols, including JDBC. Prospective customers will courageously replace 100% of their existing financial DB with a completely brand new product only if the new product has been proven 100% SOA safe in the USA market, in addition to other business requirements. A more likely scenario is selling financial OO Base products initially as a secondary component to the medium to large businesses. This strategy requires the reuse (not duplicate) of the existing, well tested SQL modules built for incumbent SQL DB, to minimize the SOA legal liability. This requirement of reusing SQL modules leads to a need of conversion from sdbc.XConnection to java.sql.Connection [ref. 2] as previously discussed elsewhere. I think that the relevant discussion starts at the 4th or 5th message in the thread. This conversion is not possible in the current version of OO Base API, if I am not mistaken. OpenOffice is constantly enhancing its architecture design for market competition. Perhaps a solution is already in the works and USA SOA safety will soon no longer be an issue or impediment for selling OO Base products. Perhaps there is an alternative (practical) approach that can obviate the need of conversion from sdbc.XConnection to java.sql.Connection. I would very welcome such ideas. I believe that you will have a wonderful experience in the conversion to OO Base. Wish you the best about the small business clients, as well as future success about the medium to large business clients. Sincerely, Ray Jahn ----- 1. Sarbanes-Oxley Act http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act 2. Base data source discussion multiple subject lines: * Base data source * transporting non-UNO Java interfaces via the Java UNO bridge * conversion from sdbc.XConnection to java.sql.Connection http://api.openoffice.org/servlets/BrowseList?list=dev&by=thread&from=1786737 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
