I have a legacy app that uses mySQL as the embedded RDBMS. The app makes explicit invocations to mysql library functions. There is no ODBC layer being used at all.
I wish to replace mySQL with SQLite. Since I am bothering to do this, I wish to introduce an ODBC layer.
I have learned about the existence of a SQLite-ODBC library (http://www.ch-werner.de/sqliteodbc/html/index.html) and that's a good thing.
Just today I learned about a MySQL-ODBC bridge!!! (http://www.iodbc.org/index.php?page=mysql2odbc/index). This is a *very* good thing in that it seems I may not have to modify existing source code (with db calls spread all over the place). Or *is* it a 'very good thing'?
Am I working too hard at avoiding work? That is, should I not use a the mySQL-ODBC bridge and hand-modify the existing source base to make ODBC call directly? maybe refactoring it to better encapsulate DB operations?
What about existing SQL statements (explicit arguments to mysql function calls) that use SQL keywords/contructs (eg, REGEXP) not supported by SQLite? Is there a best-practices way of doing this kind of transition from one DB to another?
advice welcome.
-- rich coco [EMAIL PROTECTED] 781.736.1200 x165 Starbak Inc. 29 Sawyer Rd. Waltham, MA 02453
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
