An easy to use wrapper for SQLite3 (Totally free embedded database engine!)

First, in your .h file, your inline declaration of GetLastError() is misspelled -- it is listed as int GerLastError(){ return m_iLastError; }; which won't cause any compiler complaints, but it conflicts with your documentation.

Second, I note that you have a method (Table* QuerySQL2(LPCTSTR strSQL);) which leaves it up to the programmer to free the pointer memory. I come from the "I create it, I free it; you create it, you free it" school of thought. If everybody adhered to that principle it would make memory management issues much simpler. I think it would be much cleaner if you assigned the pointer to a member var before returning it, then check the var's null state in your destructor and free the memory if necessary. It would make your code cleaner and more user friendly, and it would adhere to fairly widely practiced programming standards of memory management.

Just fyi... I haven't run the code in an app yet, but it looks good on paper. I will vote for your article, once I have tested the code.. but it is logically structure very well. I like what you have done with this -- powerful simplicity. Nice Job!

I don't think that's necessary.. your Database class is creating/returning the pointer and it already has a constructor/destructor function. It could handle freeing the memory allocation as well. But, yes, however you do it I think it's better coding practice to be responsible for freeing any resources you allocate.. so if the Database class allocates the resource, then it should be freed in that class as well. That may seem picky, but remember people who aren't familiar with your code will be trying to read it and use it.

No, of course not... I didn't say they were ONLY for MFC. What I said was that it was MFC compatible. You can pass a CString directly to any function accepting an LPCTSTR (const char*) and MFC will automatically make the conversion and you don't have to worry about data loss, buffer overruns, etc. It's not quite so tidy with char* and char** -- now you're dealing with pointers, buffers and copying data, etc., or you have to type-cast to a non-const data type or pass a CString.buffer() address (both of which can have undesirable results should the data be modified) My point was if someone is coding in MFC why use a wrapper that isn't MFC compatible? Wrappers relying on standard strings and character pointers should be left to non-MFC apps.

There are still plenty of situations where MFC isn't a viable choice, and you don't want your code tied to it... but when you are using MFC you may as well take advantage of it's simplicity... your class allows for that... many of the others available don't. So to an MFC coder your class's MFC compatibility is one good reason to use it over the other 27 available wrappers - that was my point.

Dave, if you looked at all 27 classes you will note that they aren't all free, many of the free ones aren't very good, some aren't even supported anymore, and there is only ONE decent MFC wrapper -- and it isn't even supported anymore.

The whole point of a wrapper class is to substantially REDUCE the amount of coding necessary to achieve a result. If a wrapper class only changes the function name/data type you are using, or only eliminates 1 or 2 lines of code, but leaves you to still handle errors, handle data management on queries, etc.. then it really isn't wrapping much code.

While I haven't used the code in question here, and it may or may not be full of bugs, etc.. there are a few things I like about the logic of the class compared to the other wrappers available. 1) is it's simplicity. It doesn't wrap EVERYTHING that sqlite3 is capable of, but if you are developing an end-user app, more than likely basic read/write functions and error-handling are all you will need the vast majority of the time, so why add unnecessary/unused code to your app? 2) It is an MFC class -- because of his use of the LPCTSTR data type you can pass your C-Strings directly without first converting to a pointer or a memory buffer. When programming in MFC I like to let Windows handle memory management as much as possible. Just fill your app with pointers galore and then try to debug an invalid pointer and you will understand. 3) Finally, I love that he puts the query results in a table class. All you do is execute a query with one line of code and you now have results that you can manage anyway you like.. you can populate a list, you could export to a CSV or text file, you can fill form fields if you wish to use an old-school MFC type RECORD BASED interface -- you could even write the results to another database table. It does all the work for you, but still leaves you with enough flexibility to manage your data and display the results any way you like.

For a "simple" wrapper class, this is very well thought out. If the code works as good as promised, I will give a 5 for this project.

For those of you who don't want MFC, there are plenty of other choices... If you are doing a web-based app, stick with MySQL - the point of sqLite is it's "embeddability" - it's purpose is desktop/distributed apps. And some of us who still provide custom desktop solutions for the Windows platform, still use MFC. Thanks dude, you've simplified my life.

Dave Cross wrote:

Not knowing SQLlite, but being intrigued by the first few line I read, I wanted to know if it would be worth my while investigating further.

Glad I could help Dave.... but I must say that while I realize that programmers are generally lazy -- which is why we use CP, because it's easier to customize someone else's wheel than to reinvent the wheel ourselves -- however, to ask others what the code does (that someone else wrote and is making freely available to you) because you are too lazy to READ the article/code for yourself, that takes the cake. You really should get some sort of award for such a grand level of underachievement!!

All joking aside, taking a little time to read the docs and/or code will save you a LOT of time and headaches later, esp. when it come to DB apps.