--- In [email protected], Thomas Hruska <[EMAIL PROTECTED]> wrote: > > Nico Heinze wrote: > > --- In [email protected], SMD <chat@> wrote: > >> On Tuesday 13 March 2007 14:23, kose_senol wrote: > >>> Could someone advice me a good book or a good site(www....com) > >>> about using C++ codes for SQL, e.g, retrieving information > >>> from databases using C++ CLASSES OR functions ,changing values > >>> and tables,updating or deleting ,adding new record to tables. > > <snip> > > > > If you don't want to work for some specific database only > > (and trust me, I know quite a few companies which have > > chosen to switch to another DBMS even though they knew this > > would cause much trouble), I would suggest you first work > > with ODBC; this is a universal interface > > to relational DBMS, and it's really not bad. > > > > Regards, > > Nico > > Thank you Nico. > I don't know why anyone recommends anything else. ODBC is > available for *NIX as well as Windows although Windows' > implementation of ODBC has more prominence (weird, huh?). > Platform independence is another excellent reason to use ODBC. > The ONLY downside to ODBC is that it takes a VERY MINOR > performance hit per query (<1ms to 5ms depending on the RDBMS' > ODBC implementation when compared to the same RDBMS' raw API > implementation - most modern ODBC implementations are a > lightweight layer around the API and the only real transactional > cost involved any more is making a connection to the backend DB). > In other words, use ODBC unless you need some extremely > high-performance from the app. (i.e. you are going to be > running several thousand SQL queries per second).
Well, there is one reason not to use ODBC if you are working on an application running on different RDBMS systems: the choice of data types for RDBMS systems is quite incompatible as soon as you leave the most basic data types. It's not even sure whether Unicode characters will be stored in UTF-8, in UTF-16, in UCS-2, or in UCS-4. Or maybe in some MBCS code page? Another point of interest is that in particular IBM DB2 UDB will cause trouble as soon as your records might be larger than the pagesize which the database is set up with. No single record in DB2 can be larger than 32 KB minus a few bytes. So if you need large strings, you will have to use BLOBs, no matter whether it makes sense in your application or not. And not every application manufacturer is as stern as SAP; they simply state that they run on DB2 solely if the pagesize is 32 KB. Period. Not every software company dares to behave like that. Or take date/time values. On Informix, you have the data type DATE which stores dates from 1/1/4713 B.C. until 12/31/9999. No time part included. On Oracle, your DATETIME values may range from 10/15/1582 (the first day of the Gregorian Calendar) until 12/31/9999. Including a time part consisting of hour, minute, and second. DB2 allows you to store the time with an accuracy up to the microsecond. So, what to do if you need timestamps? And you want to make your application run on Informix databases as well? Or even funnier: Certain Informix versions don't allow using the VARCHAR data type; you have to use CHAR here, no matter whether you want it or not. For these reasons I can understand why some companies are reluctant to using some open portable technology. Stick with some RDBMS, and you're on the safe and easy side. Make your application portable, and you will have to work harder. That's one reason why many companies don't use ODBC. Just my 2 pennies. Regards, Nico
