Exécuter une procédure stockée à partir d'un formulaire Windows de manière asynchrone, puis déconnecter?

Question

J'appelle une procédure stockée de mon application qui peut prendre 30 minutes pour s'exécuter.

Je ne souhaite pas que mon utilisateur laisse l'application ouverte pendant toute cette période. Donc, je voudrais appeler le sproc, le laisser voler, et les laisser fermer l'application et revenir plus tard.

Comment est-ce que je peux faire ceci?

Answer 1

laisser les arrêter l'application et viennent revenir plus tard

Si vous allez leur permettre de complètement fermer l'application, vous devez commencer un .exe séparé ou quelque chose dans un ThreadPool différent qui exécute votre code appelant la procédure stockée. Sinon, votre thread va mourir lorsque vous fermez l'application.

Answer 2

Vous pouvez utiliser les méthodes BeginExecuteXXX/EndExecuteXXX (en fonction du résultat renvoyé ou non) du SqlCommand, en passant un délégué de rappel.

Answer 3

Je suggère une réarchitecture. Créez une table "file d'attente de travail" dans laquelle vous consignez les demandes pour exécuter la procédure stockée. Ensuite, ayez un service Windows ou un travail SQL Server vérifiez cette file d'attente de temps en temps (ou soyez vraiment ingénieux et utilisez un déclencheur) pour lancer la procédure stockée. Avoir la procédure stockée mettre à jour la progression de temps en temps dans la table de file d'attente de travail, et votre front-end peut regarder que dire à l'utilisateur la progression, puis afficher les résultats quand ils sont faits.

Answer 4

Une autre méthode que vous pourriez faire serait de permettre à votre application de s'exécuter en arrière-plan (éventuellement dans la zone de notification), puis de quitter ou notifier quand le travail se termine. Vous pouvez l'utiliser en utilisant les méthodes BeginExecuteNonQuery et EndExecuteNonQuery pour lui permettre de s'exécuter dans un thread distinct.

Answer 5

Si vous voulez vraiment fermer complètement votre application, je vous suggère de définir un travail dans SQL Server Agent, et d'exécuter simplement une instruction T-SQL pour démarrer ce travail manuellement. La syntaxe est la suivante:

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] 

Le travail exécutera votre procédure stockée. Vous devrez être un peu créatif pour passer des arguments. Par exemple, insérez les paramètres dans une table "file d'attente" et demandez au travail de traiter toutes les lignes de la file d'attente.

Au lieu d'un travail, un déclencheur d'insertion dans votre file d'attente devrait également fonctionner.

Answer 6

La fenêtre principale de votre application n'a pas besoin d'être ouverte. Si vous l'avez lancé en tant que thread secondaire, il continuera à fonctionner aussi longtemps que IsBackground == false. Je préfère généralement faire ce travail via SQL Server Agent ou en tant qu'application client-serveur (rien n'empêche une application client-serveur de s'exécuter sur la même machine, ou même d'être le même binaire).

Il a été un moment ...

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

Je préfère utiliser un service de base pour le traitement hors ligne, où votre application utilisateur indique le service ce qu'il faut faire et puis se déconnecte. Le service peut enregistrer les temps écoulés et les erreurs/états, et redémarrer si nécessaire. WCF est conçu pour cela et prend en charge les files d'attente pour communiquer avec.

Answer 8

Ceci est en fait un scénario assez commun.Vous ne pouvez rien faire en fonction du client parce que le client peut s'en aller et se déconnecter et vous perdrez le travail accompli jusqu'à présent. La solution consiste à utiliser Service Broker Activation: vous créez un service dans la base de données et attacher une procédure activée. Dans votre application (ou page ASP), vous envoyez un message au service et intégrez les paramètres nécessaires à votre procédure. Une fois votre application validée, le message active la procédure de service. la procédure de service lit les paramètres du message et appelle votre procédure. puisque l'activation se produit sur un thread de serveur sans rapport avec votre connexion d'origine, ceci est fiable. En fait, le serveur peut même arrêter et redémarrer tout votre procédure est en cours d'exécution et le travail sera annulée puis a repris, depuis le message d'activation déclenche à nouveau la procédure de service après le redémarrage.

Mise à jour

J'ai publié les détails sur la façon de le faire, y compris exemple de code sur mon blog: Asynchronous procedure execution.