On Tue, Jun 26, 2012 at 8:55 AM, <bi...@aol.com> wrote: > I do realize and appreciate the public domain source is available. My best > option is recompiling the DLL but since the project and make files aren't > designed for Visual Studio it will require time that like everyone her I > cherish.
To me the best option is to include the SQLite library in your project statically. It consists of two files, and adding them to your Visual Studio project is very easy. It solves the version issues you've run into, and also allows you to tweak the #defines for SQLite's build to target your particular app's needs. If you can't or don't want to include it statically, at least build your own version of the DLL, it's very straight forward and you'll have higher confidence over the feature set included. While having a version number in the resource section of the DLL would solve the "which version of sqlite3.dll is this that's been downloaded from sqlite.org?" issue (of course, so would calling sqlite3_libversion), it would not solve the "is this a random version of sqlite3.dll that someone else built?" And yes, I've seen all sorts of fun versions of sqlite floating around. > Creating a new build also requires me to follow an extensive test > plan. I do a complete test plan even if I make a simple text change. Having > the DLL out in the public being used by thousands beats any test plan. So you do extensive testing if you change a text string in your source, but don't test each and every version of libraries you use? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
