At 3:12 PM -0500 3/18/04, rich coco wrote:<snip>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.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.
(funny, a mySql app is already a "legacy" app ;-).)
I am in a similar situation. I am developing an app on Windows using Perl, DBD-ODBC, and Access (for now, later to migrate to SQL Server). I am also porting it to SQLite (primarily so I can create a x-platform thingy and work on it at home on my Mac). There are the usual function-specific gotchas --
Iif(expr, trueval, falseval) changes to (case when expr then trueval else falseval end) kind of stuff. I can work around all this by creating queries/views in the database so I have to refer to the same "entity" in my scripts. However, I have run into the peculiar problem for which I asked for help a little while back (no answer thus far) -- aliased columns in SQLite don't seem to auto-alias (for the want of a better term) to the original column name. So, c.firstname is no longer recognizable as firstname. This has really thrown me because now all my views have to be re-done as
c.firstname AS firstname
I also am finding that parentheses are causing hiccups. If I have a query with a complicated set of joins, parens are useful and necessary for forcing the orders in joins to get rid of ambiguity. Some of the Access FROM clauses with a lot of parens are choking in SQLite.
Oh well... that is why all the databases are not the same...
good luck.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
