Roman Rokytskyy írta:

>KAMI,
>
>
>
>>Currently there are complete UNO language bindings for:
>>
>>
>
>
>
>> * C
>> * C++ (compiler dependent, please see http://porting.openoffice.org
>>for a list of supported platforms)
>> * Java
>> * Python
>>
>>
>
>Probably I was not precise enough... As I understand, you post it here since
>you plan to implement it in Java. Right?
>
>
>
>>Built in support for database. You doesn't need external module.
>>The SDBC Driver allows to use the database from OpenOffice.org
>>without any wrapper layer such as odbc or jdbc.
>>
>>
>
>What's wrong with such wrapper layer?
>
>Does SDBC component becomes a part of the OpenOffice.org suite? If not, does
>it need less configuration than JDBC? How is SDBC component installed?
>
>I suspect that SDBC component in C++ would not require JRE to be installed.
>But if the implementation language is Java, what's the difference?
>
>
>
>>I don't know anything about new features. But I don't have knowedge
>>about component modells. But from Frank Schönheit:
>>"
>>Additionally, SDBC (more precise: its extensions SDBCX and SDB) provide
>>additional features which are not present in JDBC, or were not
>>present at the time SDBC was invented.
>>"
>>
>>
>
>Let me explain why I ask this. Firebird has some internal limitations (like
>absence of autoincrement field, absence of scrollable and updatable cursors,
>etc.). Because of this, JayBird does not provide full JDBC implementation,
>some parts are missing (like getting the auto-generated PK on INSERT,
>updatable cursors). If additional features declared in SDBC are going to
>provide access to the functionality that is not present in Firebird anyway,
>I doubt that implementing SDBC component in Java brings any advantage
>compared to JDBC.
>
>When JayBird was started, we had already a JDBC driver called InterClient.
>That was a type 3 JDBC driver that required a server-side component to be
>installed on the same host with server. In addition to the configuration
>burden, there were some other issues associated with it - multithreading
>performance, etc. Creating a pure Java implementation of wire protocol
>brought an advantage of having a lightweight type 4 JDBC driver that does
>not have issues present in InterClient (though we have lost in some other
>places, for example, "wire" protocol of InterClient was better optimized for
>JDBC calls compared to native Firebird wire protocol - performance of
>InterClient in some cases was better). Same happened with type 2 JDBC driver
>(driver that accesses Firebird through JNI layer) - we gained ~30% when
>connecting to a server running on the same machine via IPC and we have a
>possibility to use an embedded Firebird.
>
>Similarly, if you want to implement SDBC "driver" for Firebird, I would try
>to answer first the question "What does it bring?". An answer "Because it
>would be native OpenOffice.org component" is not good enough for me (though
>I do not mind if it satisfies you :) ).
>
>
>
>>Please contact with Frank (Frank.Schoenheit*nospam*Sun.COM)
>>*nospam* means @
>>
>>or you may write to users@... (project's users
>>mailing list)
>>
>>
>
>If you're going to implement SDBC, you have to do this :)
>
>Roman
>
>
>

Hello!
Sorry am am not a programmer :o( I think I can not deliver a required
code...

Here is Frank's answer from: users@...


In fact you should, already today, be able to access Firebird via their
JDBC driver, using OOo's generic JDBC access.
What you were originally proposing is a "nativ"e access to Firebird in
the sense that a dedicated SDBC driver (SDBC is OOo's database access
API) is written. This would probably have the following advantages:

- It would not rely on Java, which might better suite to, say, some
Linux distros.
Yes, you *could* write an SDBC driver in Java, but experience shows
that this would have certain disadvantages, if it's really only a pure
Java driver. So, you would probably write an SDBC driver in C++.
[1]

- It would be able to work around certain quirks in Firebird more
easily.
There's definately no offense intended against Firebird. It's simply
a matter of fact that accessing *any* database via JDBC (or ODBC or
ADO, for that matter) in OOo has the potential of losing some
perculiarities of the target database, since OOo tries to be as
generic as possible then. A dedicated "Firebird only" driver could
be made to work with Firebird explicitly, without need to care for
the least common denominator of a lot of other databases, too.

- Yes, SDBC drivers are normally shipped with OpenOffice.org. There are
also mechanisms to deploy them into existing installations, but if
they have production quality at the moment OOo is shipped, why not
include them?





Bast regards,
KAMI