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=x /
add key=password value=x /
add key=database value=x /
add key=datasource value=x /
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
