On 21/12/10 07:20, Artyom wrote: >> Dear Users, >> >> The idea of having non-ODBC backend for SQL Server has been >> dangling in my head for some time. I'd like to roughly discuss this >> idea, collect your opinions about interest, how much would you >> like to have it, technology, etc. >> >> 1. Do you like this idea? 2. Is SQL Server Native Client for OLE >> DB best native approach (considering it as a replacement for old >> and rubbish ODBC) 3. Which (minimal) version of the SQL Server >> Native Client should we consider? 4. Which (minimal) version of >> SQL Server should we consider/ 5. ... >> >> If there is anyone interested in this idea, I'd appreciate any >> feedback. > > There actually 3 ways to communicate with SQL Server from C++: > > - ODBC Driver - OLE DB COM Driver - The "native" DB library. > > DB-Library ---------- > > The last one is seems to be not so recommended my Microsoft and they > tell us the ODBC is more then fine: > > http://msdn.microsoft.com/en-us/library/ms811006.aspx > > Also DB library seems to be badly documented.
I know this library a bit and it's been deprecated with SQL Serve 2008 http://msdn.microsoft.com/en-us/library/ms143729%28SQL.100%29.aspx So, I think it's little point to consider it. > ODBC ---- > > ODBC: it seems to be quite common way to connect to SQL Server also > it has an advantage that once implementing it (and I know its API is > horrible) you get support of many other data-bases out of box and it > is also widely deployed and used (Linux, Unix and others) so > virtually implementing ODBC you get a connectivity to any database > (modulo crappy ODBC drivers) Yes, but a backend for open API like ODBC has to make some compromises which not always can lead to fully-featured support of particular server or performance may be low. Mapping SQL datatypes to C++ types in ODBC is challenging, becuase not all ODBC drivers support all ODBC types. For instance, BIGINT is not supported in Microsoft Access, AFAIR. By the way, that's also the reason why some of SOCI ODBC tests are failing. > Also you get an advantage - having good ODBC driver you can connect > to MS SQL from non-Windows machines including Linux, Mac and others. Good point, but not critical for me. I'm thinking along this words: SQL Server is Windows-specific system, so "native" (in double quotes to not to confuse with SQL Server Native Client SDK) backend for it would be dedicated to Windows. If someone wants to call SQL Server from Unix, there is SOCI ODBC. > So IMHO if you want to improve the support of MS SQL Server it would > be better and easier to improve an ODBC driver it does not seems to > be very hard. I'm not considering dropping support or ODBC. ODBC is very important part. I'm asking and brainstorming if users who - target Windows platform only - use SQL Server as critical part of their system would see benefits in having "native" backend for SQL Server. > OLE DB ------- > > First of all it is **COM** API. The question is if you really want to > get into it? I have no problem with programming COM. COM is not ideal, but it solves many problems and the idea is pretty good. As I've mentioned, "native" backend would be Windows-only. > Other then that OLE DB is yet another generic API to connect to > general databases + some more features, similarly to what ODBC does. I know the differences between OLE DB and ODBC. As far as I've learned the matter, OLE DB is preferred way to access data sources. OLE DB is actually a successor to ODBC and I've been thought to use OLE DB whenever you can, but ODBC if you have to. > So it may be valuable to have OLE DB API but I don't think it would > give an advantage to use it over ODBC if not give more headache - due > to COM nature of such API. Certainly, OLE DB makes code more elaborate and ODBC is usually simpler. However, by design, there is potential OLE DB providers perform better than ODBC and this is one of the aspects I'm looking forward to hearing about from SQL Server users. > Also as additional point it would be quite hard to make the code > "cross-compiler" i.e. support non-MSVC compilers like gcc, intel or > borland as mostly for "sane" use of COM API you would like to use > ATL. I'd go for ATL, of course. As mentioned, it would be Windows-specific, so out of scope of GCC or any other compiler for which ATL is not supported. > My $0.02 Much appreciated, indeed! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
