On Sun, Oct 14, 2001 at 10:48:34PM -0400, Ilya Sterin wrote: > > > > DBI may be independent, but the fact that it does nothing with the SQL > > that is sent to the database and the fact that SQL varies from vendor to > > vendor means that there are database compatibility issues in SQL that > > are not and should not be handled by DBI but must be handled by a layer > > on top of DBI. > > > > I tire of stating this and I wonder why people want to gloss over this > > glaringly obvious fact: SQL varies from vendor to vendor.
Very true. I suspect that most people gloss over it simply because it's not relevent to them. Relatively few people really have to face porting non-trivial applications between databases. > Definitelly does, but if you stick to the SQL standard than you should have > no problems as most major db vendors implement the standard and if they > don't than maybe you should reconsider. Yes there are variances, but I > would argue that in 90% of the applications the different implementations > would not cause a problem. I think you're being a little optimistic. Any use of functions, date/time types, and non-trivial joins is very likely to take you into non-portable syntax. In the longer term the DBI will be getting some SQL rewriting functionality based on ODBC escape sequences. Right now I'd recommend DBIx::AnyDBD (or take a look at one of the bigger 'frameworks' like RecordSet, Tangram, Albazoo, etc., if you like that kind of thing). Tim.
