At 01:43 AM 3/7/2001 +0200, Dimitar Selensky wrote:

>>We had/have the same "problem" with our commercial application. Our
>>solution is to have our application support multiple database engines
>>(InterBase, Oracle, MS SQL Server, Sybase & Informix). InterBase is the
>>"default" database, but if someone is an Oracle shop, we aren't going to
>>get them to change. This also covers situations like when people want
>>over 1000 concurrent users on one database--which InterBase can't
>>handle. This may not be an option for you, but I thought I'd at least
>>mention it.
>>
>>----------
>I'm working on a project that'll have an application, connecting
>SIMULTANEOUSLY to several servers - Interbase, MS SQL and Oracle. The BIG
>problem is that they simply aren't compatible - for example one uses
>generators, the other auto incrementing fields, the third sequences. The
>stored procedures syntax is quite different, the syntax for joins in some
>cases differs, too. How did you manage to write a real world application
>that'll be able to work with any of the servers you listed above? I'm
>really curious!!!
>
>Are you kind of sticking with just ANSI sql? I can't believe that it's
>possible to do it with a real application.

I worked for a company that built a cross-database program. We defined the
core set of actions we required from a database and then built a driver for
each that implemented those features. It worked pretty well, except for
transaction management, where the then current version of Sybase bayed at the
moon.

The problem with sticking with ANSI SQL is that the set of features implemented
by all databases is less than Entry Level, and that's not enough to build
an application. Even products without non-standard features select different
sub-sets of the upper level, making their applications non-transportable.


Regards,

Ann
www.ibphoenix.com
We have answers.