On 23 Jan 2014, at 1:58pm, Joachim Bürmann <jbuerm...@iftools.com> wrote:
> On a certain customer system (Windows7 64bit) the application cannot > read the example project files (created with sqlite3.6 library). And > when the user stores his own settings in a new project, the project file > is saved as a version 2.1 file (** This file contains an SQLite 2.1 > database...) instead of a sqlite3 compatible file (SQLite format 3...) The calls to anything that can make a version 2.1 file have different names. It can't just be a case of calling the wrong 'sqlite_open()' function because the function is actually called 'sqlite3_open()' with the '3' right there in the name. > But because the sqlite functionality is part of the application (static > linked), the program should never able to access an external sqlite DLL. I don't think that that logic is correct. Can you run 'strings' (or whatever the Windows7 equivalent is) on the compiled file and see whether there are any mentions of 'sqlite2' ? Is there a debugging tool which will list the names of all routines which are called ? Ignore whether it is internal or external, just look at the routine names. I suspect that that particular customer computer has something weird loaded. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users