Subject | Re: [firebird-support] Re: FB to SQL Server |
---|---|
Author | David Johnson |
Post date | 2005-04-21T02:19:31Z |
On Wed, 2005-04-20 at 08:16 -0600, Todd Brasseur wrote:
the Java world, I use Hibernate because it is free, fast, easy to use,
and it supports 60 something different DBMS' out of the box.
Barring a complete migration to java, an alternative approach is to
emulate the JDBC model, like Jim is doing with the Vulcan internals.
Establish an interface that acts as a programmatic contract that
insulates your application from the actual underlying DBMS. Then your
users can pick _at_ _runtime_ which DBMS interface to use, and your
application doesn't care.
To be fair, my designs rarely use triggers or stored procedures. This
is in part because my products must be able to live within the
"enterprise architecture" of my customers, but also in part because I
keep the real work of the application in memory and persist to the DBMS
as necessary.
>< ... snip ...>
> Clay Shannon wrote:
>
> We want so much to be able to support both Firebird and SQL Server. WeIsolate the application from the database with an abstraction layer. In
> can't find a practical approach to doing this. We don't even mind
> keeping two versions of the database going and supporting both. The
> problem is the differences in the front end of our application. If
> anyone has any ideas, please let us know.
>
> Todd
the Java world, I use Hibernate because it is free, fast, easy to use,
and it supports 60 something different DBMS' out of the box.
Barring a complete migration to java, an alternative approach is to
emulate the JDBC model, like Jim is doing with the Vulcan internals.
Establish an interface that acts as a programmatic contract that
insulates your application from the actual underlying DBMS. Then your
users can pick _at_ _runtime_ which DBMS interface to use, and your
application doesn't care.
To be fair, my designs rarely use triggers or stored procedures. This
is in part because my products must be able to live within the
"enterprise architecture" of my customers, but also in part because I
keep the real work of the application in memory and persist to the DBMS
as necessary.