On Mon, Jul 19, 2010 at 9:46 PM, Simon Slavin <slav...@bigfraud.org> wrote:
> > On 20 Jul 2010, at 2:01am, Sam Carleton wrote: > > > On Mon, Jul 19, 2010 at 3:51 PM, Simon Slavin <slav...@bigfraud.org> > wrote: > > > >> You know, I think that the most efficient way to do what you want will > >> probably to always issue the 'ATTACH' command. If EventsDB is already > >> attached, you should get a specific error code, which you can notice but > >> ignore. > > > > So, there is foul simply trying to attach and ignoring the error if there > is > > one? That does sound ideal. > > Test it. Try it and see what happens. Ideally either you'll get a SQLITE_ > error code, or the second attach will be silently dropped. But it's > possible that the PRAGMA will show you've found a bug in SQLite in which > case please post here. > > If you get an error code, ignore that specific one only, and not all errors > returned by the ATTACH. > Ok, the distractions are gone, back on task! There are two equally important requires, one is to connect to the second "EventDB", the other is that the system admin can change the EventDB at any time. The second requirement means that connection can be attached to a database called EventDB, but it is the wrong (old) DB. Given the connection is attached to DB fileA as EventDB, is the behavior defined on what should happen when the ATTACH command is issued to attach DB FileB as EventDB? The keyword here is defined, fore if it will simply drop the old and attach to the new but this is not the defined behavior, it will be safer to simply do the check (which is already coded) in case the current behavior changes at some later date. Sam _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
