On Mar 3, 2008, at 12:55 AM, Kee Wee wrote:

>
> I would be very interested to follow-up this subject closely,
> as we are actually performing the same kind of work as you are  
> looking for.
>
> One of the answer you got was that it is not possible to reuse a  
> prepared
> statement from one database to another.
> This answer was too quick, and did not include any explanation ->  
> so I would
> rather prefer to ask again the question, and obtain why it is not  
> possible.
>
> I would say that the test I have performed until now make this thing
> possible.
> I agree that this requires to tweak a little bit the way SQLite is  
> working
> (without recompiling anything, only using the internal members of  
> the opaque
> structures).
>
> If VDBE programmers think that I am getting too deep inside the VDBE
> internal structures to handle this problem, (or that it is too  
> risky for
> data integrity), please feel free to comment vigorously on this  
> subject.
>
> The work performed was to swap Database Handles.
> Following code is included in XMLRAD DacSQLite3 to address exactly  
> this
> problem:
>
> procedure StmtSwapVdbe(Statement: TDISQLite3StatementHandle; NewDB:
> Pointer);
> var
>   Vdbe: PVdbe;
> begin
>   Vdbe := PVdbe(Statement);
>   if Vdbe.db = NewDB then
>     Exit;
>   // Uninstall Vdbe from its actual Vdbe.db
>   if Vdbe.pPrev <> nil then
>     Vdbe.pPrev.pNext := Vdbe.pNext
>   else
>     Vdbe.db.pVdbe := Vdbe.pNext;
>   if Vdbe.pNext <> nil then
>     Vdbe.pNext.pPrev := Vdbe.pPrev;
>
>   // Install Vdbe to the NewDB
>   Vdbe.db := NewDB;
>   if Vdbe.db.pVdbe <> nil then
>     Vdbe.db.pVdbe.pPrev := Vdbe;
>   Vdbe.pNext := Vdbe.db.pVdbe;
>   Vdbe.pPrev := nil;
>   Vdbe.db.pVdbe := Vdbe;
> end;
>
> Once again, if any programmer of the VDBE could comment on this, I  
> am even
> willing to pay money to get audit of the code, and get confirmation  
> that
> this technique is valid and does not put at risk data integrity of
> databases.

It think this risks database corruption.

Vdbe programs hard-code the schema-version number and the
locations of tables and indexes in the database file. These
might be different for different databases, even those with
the same schema. If the table/index locations are different
but the schema cookie is the same, you are risking database
corruption.

Also, prepared statement structures contain some pointers
back to the database handle that was used to create them.
Not sure what the implications of this are, but it doesn't
seem safe.

There might be other reasons this is dangerous too.

Dan.






> -- 
> View this message in context: http://www.nabble.com/Multiple- 
> databases-tp15035409p15790869.html
> Sent from the SQLite mailing list archive at Nabble.com.
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to