Announcement

Collapse
No announcement yet.

Clientanwendung beenden und Prozedur weiter ausführen?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Clientanwendung beenden und Prozedur weiter ausführen?

    Hallo,
    ich erstelle gerade eine Clientanwendung (in C#), die unter anderem eine Gespeicherte Prozedur auf einem SQL Server 2005 ausführt.

    Da die Prozedur extrem lange dauern kann, soll der User die Clientanwendung schließen könne (sie wird nach dem start der Prozedur nicht mehr benötigt).

    Jetzt meine Frage: wird die Prozedur auf dem Server weiter ausgeführt, wenn man den Client schließt (also die Verbindung beendet)?

    So ruf ich sie momentan auf:
    Code:
     SqlCommand cmd = new SqlCommand("myProc", con);
                cmd.CommandType = System.Data.CommandType.StoredProcedure;
                con_db.Open();
                cmd.ExecuteNonQuery();
                con_db.Close();
    Vielen Dank.

  • #2
    Hallo,

    ja geht. Die Prozedur läuft ja in einem eigenen Prozess und wird deinem Programm "nur" gestartet. Es werden keine Ergebnisse zurückgegeben (ExecuteNonQuery) und somit wartet der Aufrufende (dein Programm) nicht bis die Prozedur fertig ist - läuft sozusagen asynchron.

    mfG Gü
    "Any fool can write code that a computer can understand. Good programmers write code that humans can understand". - Martin Fowler

    Comment


    • #3
      Aber genau das schein nicht der fall zu sein…

      Wenn ich es so Ausführe bleibt die Anwendung (UI Thread) stehen. Ich habe alles also mal in eine Backgroundworker verfrachtet damit das UI dadurch nicht belastet wird. (Er wartet also bis es fertig ist)

      Ich habe mich auch grad mal im Server Profiler umgeschaut. Da wird mir angezeigt, dass die Prozedur beendet wird sobald auch die Verbindung getrennt wird. (wenn ich das richtig interpretiere…)

      Wo habe ich da den Fehler gemacht?

      Comment


      • #4
        Ok, dann muss ich genauer werden mich teilweise selbst korrigieren.
        1. In der Verbindungszeichenfolge festlegen dass Asynchron gearbeitet wird: Asynchronous Processing=true
        2. Den Command asynchron ausführen: cmd.BeginExecuteNonQuery();


        Sollte funktionieren.

        mfG Gü
        "Any fool can write code that a computer can understand. Good programmers write code that humans can understand". - Martin Fowler

        Comment


        • #5
          Danke für den Hinweis. Die Asynchrone Verbindung habe ich jetzt hinbekommen.

          Aber: Die Prozedur wird nach wie vor beendet sobald die Verbindung getrennt wird. Kann es sein das es doch nicht geht?


          Anbei noch ein Link wer Probleme hat mit asynchronen, lokalen Verbindungen:
          http://weblogs.asp.net/despos/archiv...22/190984.aspx
          Zuletzt editiert von Jonn55; 16.10.2008, 12:30.

          Comment


          • #6
            Dann habe ich die Erkenntnis dass die Prozedur an die Connection gebunden ist und nicht selbständig läuft wie angenommen - irgendwie logisch, aber auch nicht ganz

            Spontan fallen mir dann als Alternativen ein:
            • den asynchronen Callback abwarten
            • dein Client könnte einen Dienst oder ein Programm ohne UI aufrufen, das die Prozedur ausführt
            • im SQL Server einen Webservice erstellen der bei Aufruf die Prozedur ausführt
            • Remoting


            Sorry, da hab ich mich geirrt dass das so einfach geht.

            mfG Gü
            "Any fool can write code that a computer can understand. Good programmers write code that humans can understand". - Martin Fowler

            Comment


            • #7
              Kein Problem… haben wir wenigstens beide was gelernt.
              Danke für die Anregungen. Ich habe das ganze mittels Callback umgesetzt.

              Comment


              • #8
                beide was gelernt.
                Das stimmt. Das ist das Gute an der Sache.

                mfG Gü
                "Any fool can write code that a computer can understand. Good programmers write code that humans can understand". - Martin Fowler

                Comment

                Working...
                X