Hi, Ben. It appears that you do recognize the value of relying only on the documented API behavior, so my worry over any fly-by-wire-(driven by a computer) airplane I might ride is considerably alleviated. I hope you appreciate that, from your original post, it appeared that you intended to go outside of such droll constraints, and had already tried. And I imagine now that you appreciate that some inexperienced developers may need to think about how try-it-and-see (and hope for the best) approaches are likely to play out. Please accept my apology for hastily putting you into that category. Richard and the other members of the SQLite dev team are good about establishing, via documentation, what SQLite behavior can be relied upon. At the same time, they make substantial implementation changes to improve performance while holding to the documented API behavior and continuing to pass the extensive tests which help them catch inadvertent deviations from that behavior. It is for that latter reason that I considered your early failure to be fortunate, and thought you might also. Good luck with that replication project. I have seen how challenging it can be to get such to work well and reliably. If your tool does that, I would be very tempted to use it (for a personal project) if there was sufficient reason to believe it was reliable. Getting replication to work across live instances would be great, if it was reliable. Maybe a connection proxy, able to deal with the need for closing and reopening "real" connections, could be made to work. Cheers,<code> -Larry</code>