Hello Joachim, If you run it in the debugger, break it then look at the loaded modules. That'll tell you if the Sqlite dll got loaded somehow. I'd suspect some other part of the program might be loading the DLL manually and hooking the function calls. You could load DLL through ordinals (basically the function index in the DLL) and not have any Sqlite related strings in the EXE. I tend to load my own DLL's through ordinals.
If you see nothing, I might stick an Sqlite dll in the program folder and then run a second time and check again. Maybe something is trying to be smart and load the DLL when available but failing that, falling back on using internal static linked. How large is the .lib you're loading? My release build, 32 bit Sqlite lib is 2.1 megs. Release build 64 bits is 2.7 Megs C Thursday, January 23, 2014, 10:38:10 AM, you wrote: JB> Hello Simon, JB> thank you for your fast response. >> 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. >> JB> ok, my wording could missunderstand. Of course, also a statically linked JB> program can open a shared lib to access function from that. But our JB> application doesn't do that - not for sqlite. I only thought, that JB> accessing an external sqlite DLL could cause such a behaviour. But with JB> different names - as you mentioned - it's hard to believe that a older JB> DLL is the reason. JB> I don't know 'strings' for windows. I tried it with dumpbin (outputs all JB> dependencies and imports) and wintrc (similar to strace) and didn't find JB> any sqlite access (neither a function nor a library/dll open call with JB> sqlite in its name). That's why I'm so confused. >> I suspect that that particular customer computer has something weird loaded. JB> yes, I suppose that there is something different in that computer. More JB> than this: The customer told me, that he can reproduce the effect on JB> another notebook. So I think it isn't a matter of the OS but of some JB> other application he runs on both computers. JB> Anyway, thanks a lot for your response JB> Best regards JB> Joachim >> >> Simon. >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users JB> _______________________________________________ JB> sqlite-users mailing list JB> sqlite-users@sqlite.org JB> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- Best regards, Teg mailto:t...@djii.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
