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

Reply via email to