On Tue, Jul 20, 2010 at 8:34 PM, Simon Slavin <slav...@bigfraud.org> wrote:
> > On 21 Jul 2010, at 12:42am, Sam Carleton wrote: > > > 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. > > You mean change the contents of that file, or change which file is > nominated as the EventDB file ? > the later, at one point in time EventDB might be D:\Events\Hopeville Classic\event.sqlite and later it will be D:\Events\Main Street Classic\event.sqlite True that it doesn't change often, but the admin can change it at will. > > > The second > > requirement means that connection can be attached to a database called > > EventDB, but it is the wrong (old) DB. > > What signifies the 'right' EventDB ? Are you creating at least two > different files (a right one and a wrong one) and giving them the same > filename in the same directory ? If they're different files they should > have different filenames. Some of your questions are answered above. Ultimately the concept is an "event" is like a word processor document or spreadsheet document. The event.sqlite file is only one physical file which makes up the whole of an "event". All the contents of the folder (Hopeville Classic or Main Street Classic) in which the event.sqlite resides makes up the whole of the "event". The system admin can, at will, go in and "load" a new "event", aka point the system to a new folder or simply create a whole new event. > It seems to me that you either need to attach an EventDB file only as long > as a command is trying to use it. If you can't do that you need a way to > tell your application that the EventsDB file it's currently connected to is > out of date, and it's time to go find a new EventDB file. > First off, please remember that I am doing in a web server that is using connection pooling. This is a very important fact... My issue with only attaching to the EventDB for only as long as a command is trying to use it is: The EventDB is used a LOT, a WHOLE lot. If I attach and drop between each little call, then within one HTTP request I might attach and drop 3 to 8 times. What is the cost associated with attaching/dropping a database? Since it involves attaching to a physical file, I am assuming it is a bit high. As far as telling my application when the EventDB file is out of date: It would be pretty easy for me to add a timestamp to the EventDB variable that is in the primary database, but... Once I get a connection from the connection pool, how do I know the age of that connection to know if the EventDB it is attached to is the new one or the old one? Is there some connection age or timestamp I could use? I am guessing not, which is why I am using the PRAGMA database_list to determine if the EventDB is attached and if so, find the physical path to the EventDB file to see if it matches with the current system settings. I am VERY open to any ideas that will help me improve the performance and design, I simply am not seeing any. I know for a fact that I am using both the Web Server and the database is a none classical ways, which makes for all sorts of funny requirements. The whole objective of my system is to allow none technical folks setup and manage a web server on an intranet and easily back things up without knowing a darn thing about web servers or databases! So far folks love the system, but the hoops I have to jump through to make it all work seamlessly, wow! Sam _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
