Hi Karsten,
I'd recommend using ANSI SQL. Almost all databases support it.
Specially regarding join syntax. Oracle is one example. I used to write joins
this way:
select foo
from blah1 a, blah2 b
where a.id = b.a_id
Writing that in ANSI SQL would be:
select foo
from blah1 a inner join blah2 b on (a.id = b.a_id)
After rewriting all my SQL statements to be ANSI-compliant, i didn't have
problems porting to
another database anymore.
Hope that helped.
Cheers,
Daniel Silva.
--- Karsten Silz <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I've used SqlMaps on a couple of projects and I'm quite happy with it.
> However, I don't know how to handle one requirement that has shown up
> recently: supporting multiple SQL dialects (i.e., different JOIN syntax
> etc.) when you interacting with different databases.
>
> If you assume that the query just look a little different, I could see
> how you have multiple sets of query files and just use / ship a
> different one for each installation. Now could you have a "base set"
> where most queries are in (because they are the same across databases)
> and then sets with queries that are specific for each database (similar
> to accessing resource bundles)? I would really like to avoid
> duplicating each and every query for each supported database. Or could
> you use the "namespace" feature for that?
>
> Now this breaks down when there are queries that are one query for one
> database and multiple queries / queries plus Java code for another
> database. Would you have to build a little framework around SqlMaps
> then? I guess SqlMaps isn't really build to handle this kind
> situation. Or is it?
>
> Any help would be appreciated.
>
> --
> Karsten Silz
>
> "It is dangerous to be sincere unless you are also stupid."
> George Bernard Shaw (quote found on http://www.theinquirer.net)
>
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
