-----Original Message----- From: Puneet Kishor [mailto:[EMAIL PROTECTED] Sent: Thursday, March 18, 2004 7:31 PM To: SQLite Subject: Re: [sqlite] moving from mySQL to SQLite - A guidance request
> At 3:12 PM -0500 3/18/04, rich coco wrote: >> 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. > <snip> >> 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. ------------------------------------------------- Yes, about that c.firstname thing... Do we need to turn in some kind'a formal "enhancement request?" Seems the feeling of those responding was that a configurable option was most desired. Perhaps a PRAGMA? So Richard, in all your spare time, what'd y'a think? Fred --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
