On 04/29/14 16:32, Carlos H. Cantu wrote: > DY> 29.04.2014 12:09, Mark Rotteveel wrote: > >>> If you look at SQL Server, there jobs themselves are not defined for a >>> specific database (although they may depend on one or more databases). >>> AFAIK they are stored in the master database. Execution requires an Agent >>> service to be running. > DY> We neither have a master database, nor an agent service, nor database > DY> links to access user dbs from a master one (or any other solution to > DY> this issue). Shouldn't we think about something more realistic? Or at > DY> least postpone scheduled tasks until we have a proper foundation built? > DY> Dmitry > > I'm considering that "master database" would be used only to store the > jobs information. A client/daemon would read it, create all the > schedules and run the tasks at desired time (use of OS scheduler is an > option too). Such "master database" (better call it > jobs/tasks/scheduler database?) can be created and distributed with > new installations (like the security2.fdb already is). > > If you don't worry about mixing things a bit, maybe even security2.fdb > could be enhanced to store jobs data, avoiding the need to create a > new pre-installed database.
We do not have single fixed security database in FB3. Therefore us of it as jobs storage is not good choice. Adding new one looks better to me. But once again embedded problem is here - up to the fact that embedded user may have no rights to start daemons. ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
