Re: Background processes inside the database.

You could always go for an intermediate step. Set a flag in a table, have an OS process (cron scheduled or whatnot) check that table to see if it should spawn the process you really want to run. cheers j. -.-- --- ..- / -. . . -.. / - --- / --. . - / .- / .-.. .. ..-. . .-.-.- / ... --- / -.. --- / .. .-.-.- ----- Original Message ----- From: "Topher TheRead" <tophertheread@netscape.net> To: <informix-list@iiug.org> Sent: Friday, October 03, 2003 12:19 PM Subject: Background processes inside the database. > I am looking for a way to have a session spawn a background process > and release. > > The user needs to be able to start a job which could conceivably take > days (don't ask what the job is, as I have customers reading this > froup and I do not want them to realise how messed up their database > is). The user's session must, therefore disconnect before the job is > completed, and no network connection can be expected to maintain a > connexion that long, so the app cannot just spawn another app to run > the job. > > On the OS, it is fairly easy to have one executable start a second > that runs in the background and not wait for the second to complete. > So, I can have an SPL procedure which makes a system call to the first > and more or less achieve my goal. This is our only option in IDS 7, > at least as far as I can make out, but system calls are a pain. > > I would hope a more elegant solution exists through UDR's, but I have > not found one. The mi_tab_execute_on_background() call was suggested, > but I can get no documentation on this. > > Does anyone have any advice, information, or suggestions? > > Sincerely (His and hers), > Topher B| > > Who knows what evil lurks in the hearts of SPL system calls? > sending to informix-list