quote:
You could design your application around an ODBC connection.
Not so much really. The "connection" isn't
really the issue but, as Kronin555 pointed out, there are different
"flavors" of SQL, so you would have to make your code as vanilla as
possible, which would mean that you would not be able to take any
advantage of your particular DBMS and its built in functions.
Things like string and date functions differ widely between
databases, and you would have a very hard time making your CF code
portable.
The only practical way that you might be able to make your CF
code more portable would be to strictly use stored procedures
instead of imbedded SQL so that all of your SQL would be contained
in your particular database, and you would create "standard"
procedure calls in CF with cfstoredproc, cfprocparam, and
cfprocresult tags. In other words, your proc calls would just need
to pass parameters to and from your stored procedures, and possibly
return result sets, and these proc calls could be standard in your
CF code, with the stored procedures behind the scenes designed for
the applicable DBMS. T-SQL in SQL Server and PL/SQL in Oracle are
very robust and even MySQL has stored procedure capability
(depending on the version).
Phil
7
Replies
AdChoices