ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Grabowski <rongrabow...@yahoo.com>
Subject Re: Writing SQL Maps that support both SQL Server and Oracle
Date Fri, 21 Jan 2005 23:53:23 GMT
You could use stored procedures. 

I'm starting to port statements originally written for SQL Server over
to Access (with the .Net version of iBatis) and I think I can get away
with defining database specific functions in the properties file that I
define my database information:

	<add key="userid" value="xxxxx" />
	<add key="password" value="xxxxx" />
	<add key="database" value="xxxxx" />
	<add key="datasource" value="xxxxx" />
	<add key="getDate" value="NOW()" />
	<add key="selectKey" value="SELECT @@IDENTITY" />

Then in my sql maps:

<insert id="AddressInsert" parameterClass="Address">
	<selectKey property="AddressId" type="post" resultClass="int">

Another option would be to maintain database specific copies of your
sql maps :(

- Ron

--- "Barnett, Brian W." <bbarnett@scholarinc.com> wrote:

> We have a web app that runs against SQL Server. All of our SQL maps
> are SQL
> Server compliant. We now have to be able to support Oracle as well.
> (We
> never thought it would happen... a mistake.)
> Anyway, we are wondering if anyone has some general guidelines for
> writing
> SQL Maps so that they run against both databases. Before you get
> scared and
> close this email, let me say we're not looking for a list of
> differences
> between the two databases, and how to resolve those differences. We
> already
> have a doc that explains those things.
> The first issue we have run into is the CONVERT and CAST functions of
> Server. We make use of them in our SQL maps. We are debating on
> whether we
> should take them out and do the conversion or casting in java code or
> pass a
> parameter to the SQL map indicating SQL Server or Oracle and then
> have a
> <dynamic> element that generates the appropriate CONVERT or CAST
> syntax.
> All input is welcome.
> Thank you,
> Brian Barnett

View raw message