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:
<settings>
<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" />
</settings>
Then in my sql maps:
<insert id="AddressInsert" parameterClass="Address">
INSERT INTO Address
(
Street,
City,
Zip,
DateAdded
)
VALUES
(
#Street#,
#City#,
#Zip#,
${getDate}
)
<selectKey property="AddressId" type="post" resultClass="int">
${selectKey}
</selectKey>
</insert>
Another option would be to maintain database specific copies of your
sql maps :(
- Ron
--- "Barnett, Brian W." <[EMAIL PROTECTED]> 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
> SQL
> 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
>
