Am 12.11.2009 um 20:08 schrieb Peter Haworth: > Thanks for all the info. I believe the problem lies within Revolution > since I'm pretty sure it includes its own private library of the > sqlite code. I've reported it to them and hopefully they will fix it. > > I understand the reasons for applications having their own copy of the > code like this but think there's equally good reasons why they should > use a common library installed on the computer, maybe as an option. > Right now, I have to rely on Revolution updating their code to solve > my problems whereas with a common library approach, I could download > and compile as several people have suggested and not have to rely on > Revolution.
I'd say this depends on the type of application: if an application uses sqlite for it's internal data management, but none of the SQL functionality is exposed to the user, then there are good reasons to include a private copy: the app might rely on certain features not available in older sqlite distributions which may exist on the deployment systems, or it might even have added some extension to sqlite which it relies on, etc. However, for applications that expose the SQL functionality (like php, perl modules, Revolution, SQL editors, etc.), it does make sense to use a shared library, which allows the user to update the SQLite implementation without having to wait for an application update... As usually: "it depends..." ;-) my €.02, </jum> _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
