Eseguire una stored procedure da un modulo di Windows in modo asincrono e quindi disconnettersi?

Question

Sto chiamando una procedura memorizzata dalla mia applicazione che può richiedere 30 minuti per essere eseguita.

Non voglio che il mio utente lasci l'applicazione aperta per l'intero periodo di tempo. Quindi mi piacerebbe chiamare lo sproc, lasciarlo volare e lasciarli chiudere l'applicazione e tornare più tardi.

Come posso fare questo?

Answer 1

farli arrestare l'applicazione e vengono tornare più tardi

Se avete intenzione di consentire loro di completamente chiudere l'applicazione, dovrete avviare un .exe separato o qualcosa in un ThreadPool diverso che esegue il codice chiamando la stored procedure. Altrimenti il ​​tuo thread morirà quando chiudi l'app.

Answer 2

È possibile utilizzare i metodi BeginExecuteXXX/EndExecuteXXX (a seconda se restituisca un risultato o meno) di SqlCommand, passando un delegato di richiamata.

Answer 3

Suggerisco una re-architettura. Creare una tabella "coda di lavoro" in cui si registrano richieste per eseguire la stored procedure. Quindi, avere un servizio di Windows o un lavoro di SQL Server controllare che di tanto in tanto lavori (o essere davvero geniale e utilizzare un trigger) per avviare la stored procedure. La procedura memorizzata aggiorna i progressi di volta in volta nella tabella della coda di lavoro e il front-end può controllare che l'utente indichi l'avanzamento e quindi visualizzare i risultati al termine.

Answer 4

Un altro metodo che si potrebbe fare sarebbe quello di consentire all'applicazione di funzionare in background (possibilmente nell'area di notifica) e quindi uscire o notificare quando il lavoro è completato. È possibile utilizzare ciò utilizzando i metodi BeginExecuteNonQuery e EndExecuteNonQuery per consentirne l'esecuzione in un thread separato.

Answer 5

Se si desidera chiudere completamente l'applicazione, suggerisco di definire un lavoro in SQL Server Agent ed è sufficiente eseguire un'istruzione T-SQL per avviare manualmente quel lavoro. La sintassi è:

sp_start_job 
    { [@job_name =] 'job_name' 
     | [@job_id =] job_id } 
    [ , [@error_flag =] error_flag] 
    [ , [@server_name =] 'server_name'] 
    [ , [@step_name =] 'step_name'] 
    [ , [@output_flag =] output_flag] 

Il lavoro dovrebbe eseguire la procedura memorizzata. Dovrai essere un po 'creativo per passare qualsiasi argomento. Ad esempio, inserire i parametri in una tabella "coda" e fare in modo che il processo elabori tutte le righe nella coda.

Invece di un lavoro, dovrebbe funzionare anche un trigger di inserimento sulla coda.

Answer 6

Non è necessario che la finestra principale dell'applicazione sia aperta. Se lo hai lanciato come thread secondario, continuerà a funzionare fino a IsBackground == false. Di solito preferisco fare queste cose tramite SQL Server Agent o come applicazione client-server (nulla impedisce che un'applicazione client-server sia in esecuzione sullo stesso computer, sia che sia lo stesso binario).

E 'stato un po' ...

using System.Threading; 

..... 

Thread _t = null; 
void StartProcedure() 
{ 
    _t = new Thread(new ThreadStart(this.StartProc)); 
    _t.IsBackground = false;//If I remember correctly, this is the default value. 
    _t.Start(); 
} 

bool ProcedureIsRunning 
{ 
get { return _t.IsRunning; } //Maybe it's IsActive. Can't remember. 
} 

void StartProc(object param) 
{ 
    //your logic here.. could also do this as an anonymous method. Broke it out to keep it simple. 
} 

Answer 7

Io preferisco usare un servizio in background per l'elaborazione in linea, in cui la vostra applicazione utente comunicato al servizio di cosa fare e poi si disconnette. Il servizio può registrare i tempi trascorsi e gli errori/lo stato e riavviare se necessario. WCF è progettato per questo e supporta le code con cui comunicare.

Answer 8

Questo è in realtà uno scenario abbastanza comune.Non puoi fare nulla in base al cliente perché il cliente potrebbe andarsene e disconnetterti e perderai il lavoro raggiunto finora. La soluzione è utilizzare Service Broker Activation: si crea un servizio nel database e si allega una procedura attivata. Nell'applicazione (o nella pagina ASP) si invia un messaggio al servizio e si incorporano i parametri necessari per la propria procedura. Dopo il commit dell'applicazione, il messaggio attiva la procedura di servizio. la procedura di servizio legge i parametri dal messaggio e richiama la procedura. poiché l'attivazione avviene su un thread del server non correlato alla tua connessione originale, questo è affidabile. Infatti, il server può anche arrestare e riavviare mentre la procedura è in esecuzione e il lavoro verrà ripristinato, quindi riprendere, poiché il messaggio di attivazione attiverà nuovamente la procedura di servizio dopo il riavvio.

Aggiornamento

Ho pubblicato i dettagli di come fare questo codice di esempio anche per quanto riguarda il mio blog: Asynchronous procedure execution.