Originally posted by: Sef
This is a lot of self-promotional hype. Contrary to what you said, ADO should be used in the vast majority of cases. It's simplicity makes it far less prone to errors which is reason enough to use it most of the time. In response to your points:
1) Variants are a pain but hardly an issue here. One easy solution: simply add your recordset object to a C++ class as a member variable. Your C++ class acts a wrapper and you can provide standard C++ public functions to gain access to it. Very simple, very clean. Clients merely call a member function like "SetEmployeeName()", passing the name as an ordinary C++ string (string, TCHAR *, CString, or whatever you want). No COM based types to worry about whatsoever. Only the function itself needs to get its hands dirty with these types but that's easy also. It merely needs to call some standardized base-class function to do so (i.e., derive your class from some reusable class such as "CADORecord" which you write to provide functions to handle these common operations). This is not difficult and very quick to implement. It also promotes good data hiding techniques - the very hallmark of good OOP design.
2) The extra layer going through ADO instead of OLE DB directly is not an issue in the vast majority of cases. The speed difference is negligible for all but the most time-critical apps.
3) Your comments on use of #import are grossly inaccurate. See article ID Q175784. #import in fact makes life much easier and exceptions do too in many cases. Your own examples use exceptions.
4) Having to check HRESULTs is not an ADO issue, it's a COM issue which you yourself cite as problem with the templates. So your emphasis that it's a drawback to using ADO doesn't wash.
I'll stop here rather than elaborating further. There are simply too many reasons to stick with ADO without going into a treatise on the subject. The last thing programmers need is yet another way of doing the same thing. Programmers are inundated with way too much technology these days which is partly responsible for the shoddy state of most software. There are a dozen complex ways of doing everything and most can't get a handle on it. Yet another library only hurts the situation in spite of the best of intentions. It results in a steeper learning curve when new employees arrive and have to learn yet another library. That's an error prone activity and reduces the quality of your software. This affects everything from customer satisfaction to employee morale and ultimately the bottom line. ADO is now the de facto standard for accessing data and it's much better to rely on a tried-and-proven system with a huge corporate backing. It may not be perfect but neither is any solution. There are trade-offs to everything you do and the same applies to your "complete" library (merely another series of wrapper classes). To all novices out there. Take the advice of someone who's been around the block a few times. Evaluate your tools based on your needs but seriously consider ADO. You'll find that it easily solves your problems most of the time.
Reply
Originally posted by: Gasparote
I'm using this excellent library in my projects but now I have to store BMP files in one MS-Access database (OLE Object data type).
Could you please provide me an example showing how to load and store these BMP files and then display them on the GUI?
Thanks in advance!
Originally posted by: Jim Cornell
I tried to download the library from your site. But the site is too slow and I can not download it. Is there any alternate site for download?
ReplyOriginally posted by: Chris
You wrote:
"If you use #import statement, you cannot avoid jump-to-exception situation even if you want to avoid it. "
This is not completely true:
Just use the raw_METHODNAME or for properties the GetPROPERTYNAME methods on the smart pointer.
Like
HRESULT hr;
ADO::_RecordsetPtr spRecordset;
hr = spRecordset->get_Status();
this uses directly the interface implementation without error checking.
Can be quite handy when the method/property is expected to fail but you don't want the overhead of the exception handling which makes the program much slower.
Otherwise a great article (haven't yet examined the source files), only 4 weeks too late for me - just switched from DAO to ADO ;-)
best regards,
christoph
Originally posted by: Colin Dyckes
Looks very promising, but a third party library without source code is just not useable for mission critical projects.
I'll just have to stick with ADO and ADO.NET
ReplyOriginally posted by: Michael Berlenz
The following files are missing so I cannot compile the projects:
Where can I get this files?
I downloaded the file "EODL_demo.zip" which contains the sample projects.
AddrBook.mdb, SypODLAll.h, SypOleDbLib.rc and probably some other files.
Originally posted by: Paul
i install the SypExpressODL.exe normally and compile the sample "AddrBook" OK.
But it can not run , message is can not find the SYPEXPRESSODL.dll and else SYPEXPRESSODL*.dll while in UNICODE environment
Originally posted by: Manfred Mueller
I found only MoveFirst, MoveNext but no releative move, e.g.
Move 2 records from the actual Record or
Move 4 Records from the first record
is it possible to get a function like this???
thank you for the great DB Implementation
ReplyOriginally posted by: Werner Kaa
I just downloaded your Library. Before I start testing it, can you tell me if your Library supports UNICODE.
Can I translate it in an unicide environment and is it possible to write UNICODE strings to the database
Originally posted by: Werner Kaa
m_Conn.SetProvider("SQLOLEDB.1");
Server, Username, Password and database is correct. Using the ODBC API it is running.
Using Open I got following Error:
Errorcode : 1012
I tried to connect to a MS SQL Server:
m_Conn.Open( _T("au52030C"),
_T("sa"),
_T("Password"),
_T("DB Name" ) );
Internal error occurred. (GetSingleError)
Can not open data source.