From what I remember, an attempt at database compatibility is attempted 
across major revision numbers (i.e. all SQLite v2 revisions can read 
SQLite v2 databases, all SQLite v3 revisions can read SQLite v3 
databases), but I can't remember.  I don't believe it's generally 
recommended to be doing what you are doing - is there any reason why 
they both can't be dynamically linked against a sqlite DLL, and then 
supply only the one version?

A good way to test would be to grab the versions being used by the DLLs 
off of the website, and write your own little test harness that 
simulates the situation and try to use 1 DLL version to write the 
database, and another to read & modify it, and finally read it back 
using the 2nd.

If you open a database read-only, then no corruption should occur since 
SQLite will not have the permissions on the file handle.

Kalipto wrote:
> Hello,
> For some particular reasons, one process loads two different DLLs, each 
> one linked with a static library of Sqlite. This two DLLs access the 
> same database. I know that there is no problem if you access to the 
> database from 2 different processes. But I was wondering if there would 
> be a problem in this situation. Maybe the two libraries would improperly 
> share some objects like mutex in the same process environment ?
> Another question is, does it makes a problem that the 2 versions of the 
> static Sqlite libraries are different (not the same release number) ?
> I ask all these questions because sometimes (even if it is rare) the 
> database gets corrupted. So I was wondering if it could be an 
> explanation of this problem or if I must look into another direction 
> (maybe the program would badly write in the database structure and 
> corrupt it).
> Last question: if I open a database in read-only mode, does it guarantee 
> that the database will not be corrupted.
> Thanks for your answers.
> Kal
> _______________________________________________
> sqlite-users mailing list

sqlite-users mailing list

Reply via email to