> > 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. > > We neither have a master database, nor an agent service, nor database links > to access user dbs from a master one (or any other solution to this issue). > Shouldn't we think about something more realistic? Or at least postpone > scheduled tasks until we have a proper foundation built?
I certainly think so. People are confusing the features which are available from the heavy weight SQL engine installs (I mean install/footprint size), and thinking that the "engine" implements the scheduler features. As you correctly pointed out, they do not. There are supporting elements/components/elements which are responsible for that. Certainly none that easily map to an embedded simple DLL deployment model. Sean ------------------------------------------------------------------------------ "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
