Hi,
I need to make an application to be as much independent of the DB as possiible, So that less work is required when it has to be deployed elsewhere, (elsewhere = diff database , different schema, diff name.....bla bla bla)

Any suggestions on the approach?

either

Stick to ISO/ANSI SQL only in your application

OR

develop the application using subclasses to handle SQL interface

OR

if you dont want to get involved in classes and sub classes then design your application in such a way that you can use a simple if then elseif construct to select which db implementations to use.

option 2 in my books is preferred, option 1 is tricky, option 3 can be made to work but is very very messy and prone to errors unless you are very tightly disciplined in your development process.

hmm....
guess i'll stick with ODBC, and connect all other DB's with ODBC!!!!!

except, im a bit unsure about calling stored procedures,
currently i use '{Call my_stored_procedure1(?,?)}' as my command text.

Will that change for other db's using odbc??/
or will odbc handle it?

thats precisely your issue....
theretically ODBC should provide a transparent mechanism effectively a class that sheilds you form having to get involved with db specific issues

....however not all db support the same functions, not all dbs stick to ANSI SQL (well if truth be told none of 'em are 100% ISO/ANSI SQL compliant)

...a ferinstance until recently MySQL didnt support stroed procedures, not all MySQL db's neccesarily support transactions and RI.

...each and every db manufacturer has legacy issues of ways they used to do things that still exist but are not ANSI compliant. sometimes they support the ISO/ANSI standard as well as their own variant. some of these enhancements are marketing hype (so they can show they do things better), some are just well we thought it better to do it that way, or even we think this is a important feature that we couldnt get adopted at the last standards review)

if you are using ODBC then that should be fine.. it it after all a mechanism to connect you to the data, However if your are trying to develop a db independent application I reckon these days you would be strongly encouraged to go down an object/class route so that when you need to support another db (conceivably an older / newer version of the same db) you create a class that handles the db interaction for that db/version. depending on your design you could inherit the parent classes methods and properties, and merely provide the db specific code in each inherited class.