Meine Delphi-Anwendung soll auf dem SQL-Server eine langlaufende Procedure starten oder eben einfach ein langlaufendes Skript ausführen - ist egal. Das kann gut mal 1 oder 2 Stunden dauern.

Die Ausführung auf dem SQL-Server soll nicht abgebrochen werden, wenn der Anwender meine Delphi-Anwendung beendet oder gleich den Rechner ausschaltet oder neu startet. Das scheint gar nicht so einfach zu sein. Auch mit asynchroner ADO-Verbindung bekomme ich es einfach nicht hin.

Windows-Dienste oder der Aufruf einer 2. Anwendung, die dann einfach weiter läuft, kommen wegen eventuellem Rechner-Neustart auch nicht in Frage.

Hat jemand eine Idee?

Agenden Job?
https://docs.microsoft.com/de-de/sql...l-server-ver15

Ich würde empfehlen, einen scheduled Job anzulegen.
Du startest also nicht mit delphi die eigentliche Verarbeitung, sondern planst die Durchführung eines definierten Scripts.
Das ist ein einmaliger, kurzer Vorgang.

Dieses Vorgehen hat verschiedene Vorteile, u.a. dass man mit jedem Tool, das auf Scheduled Jobs schauen kann, diese ebenfalls transparent beobachten Monitoren, canclen, .. was auch immer kann.

Produktiv genutzt habe ich sowas bis jetzt nur auf Oracle. Daher kann ich Dir keine Details nennen. Ich kann Dir nur versichern, dass Du damit mehr Informationen bekommst und kontrollierst, als mit Deinem Delphi Programm, das lediglich als Initiator dient.

Zu den Tasks gibt es mit Sicherheit Schnittstellen (Sp und Views), die den Status, Laufzeit, Ergebnis, Fehler und viele andere Attribute des Prozesses liefern. Wenn Du in Deinem Delphiprogramm etwas Daten "mitnimmst" die aus dem Job Create kommen, kannst Du darauf bezogen mit dem Delphiprogramm auch wieder abfragen, was los ist. Ob noch was läuft, ob es einen Fehler gab, ob neu gestartet werden muss oder kann usw.

Hier ist ein Link, den es sehr wahrscheinlich auch auf Deutsch und ohne Azure gibt (und in der passenden MSSQL Version).
https://docs.microsoft.com/en-us/sql...l-server-ver15

Mglw. ist das Ganze von der Edition abhängig. Mit der Express geht es sehr wahrscheinlich nicht.

Danke für die beiden Vorschläge. Es gibt leider nur Berechtigungen (db_owner) auf die eigene SQL-Datenbank. Keine Berechtigungen für die SQL-Server oder die SQL-ServerAgents. Dazu werden die Kisten auch von ziemlich eigensinnigen und unzuverlässigen Rechenzentren betrieben - da müsste ich immer hinterher telefonieren.

Noch jemand eine andere Idee?

Mmh, also hast Du Dir "die beiden " Vorschläge mal angesehen? Es sind die gleichen, nur der eine Vorschlag hat einen anderen Begleittext als der andere.

Ich habe Dir mal den Code rauskopiert:

zusammenfalten · markieren

Delphi-Quellcode:

USE msdb ;
GO
-- creates a schedule named NightlyJobs.
-- Jobs that use this schedule execute every day when the time on the server is 01:00.
EXEC sp_add_schedule
    @schedule_name = N'NightlyJobs' ,
    @freq_type = 4,
    @freq_interval = 1,
    @active_start_time = 010000 ;
GO
-- attaches the schedule to the job BackupDatabase
EXEC sp_attach_schedule
   @job_name = N'BackupDatabase',
   @schedule_name = N'NightlyJobs' ;
GO

- Eine Aufgabe anlegen (mit Timing)
- Die Aufgabe mit einem (existierenden) Job verbinden (hier ein Backupscript)

Der Text in dem Beitrag redet zwar von Management Studio und Server Agents, aber am Ende der 20 Arbeitsschritte, die beschreiben wie Du das mit Mausklicks in den GUI Tools von MS machst, wird der obige SQL Code gezeigt, der das gleiche macht.

Wie gesagt, ich hab das bei MS SQL Server noch nie benutzt und ich nutze MS sowieso nicht, aber das ist eine Fähigkeit der DB, die Du per SQL nutzen kannst und der OWNER einer DB zu sein, dürfte so mehr oder weniger auch bei MS das fundamentalste Recht sein, das man haben kann.

Kann natürlich sein, dass ihr einen "günstigen" Dienstleister unter Vertrag habt. Trotzdem verstehe ich das Argument nicht. Wenn Du ein Insert oder Update mit Deinem Programm an die DB schickst, telefonierst Du ja wahrscheinlich auch nicht hinterher und fragst die Admins, wie es so läuft.

P.S.: Ein Job ist dasjenige was Du suchst, er führt asynchron ein Script aus. Du sagst ihm nur, was, wann wie oft. Und zwar per SQL. Also so etwas wie der Code oben, ist primär erstmal das, was Dein Programm "können" muss. Es geht viel mehr. Ich wäre sehr gespannt auf andere Möglichkeiten, die ähnliches leisten.

Vieleicht funktioniert es wenn du das Kommando als Skript mit abschließendem Commit im Skript übermittelst:

markieren

SQL-Code:

execute procedure XXX;
commit;

Zitat von jobo:

Mmh, also hast Du Dir "die beiden " Vorschläge mal angesehen? Es sind die gleichen, nur der eine Vorschlag hat einen anderen Begleittext als der andere.

Das habe ich natürlich bemerkt, sah aber keinen Grund dies zu kommentieren. Zwei gleiche Vorschläge sind weder schlechter als nur einer noch bedeutet es, dass es deshalb die beste Lösung für das Problem ist. Alte Börsenweisheit: "Die Mehrheit liegt meistens daneben - sonst wären wir alle reich"

Meine Kunden haben ihre IT physikalisch und administrativ an diverse Rechenzentren abgegeben. Meine Delphi-Anwendung verwendet eine SQL-AppRole, um auf die eigene Datenbank auf dem SQL-Server (bei diversen RZ) zuzugreifen. Diese AppRole ist Mitglied von db_owner. Somit verfügt meine Delphi-App über alle Berechtigungen innerhalb der Datenbank und kann somit alle Strukturen innerhalb der eigenen Datenbank (Tabellen, Sichten, Procs, Funcs usw.) erstellen, ändern oder löschen. Weder die AppRole noch die Anwender der Delphi-App (Windows-Authentifizierung) verfügen über Server-Rollen auf dem SQL-Server.

Für die Anlage eines Jobs mit sp_add_schedule sind jedoch folgende Berechtigungen erforderlich:
"Standardmäßig können nur Mitglieder der festen Serverrolle sysadmin diese gespeicherte Prozedur ausführen. Andere Benutzer müssen Mitglieder der festen SQL Server -Agent-Datenbankrollen in der msdb -Datenbank sein:

• SQLAgentUserRole
• SQLAgentReaderRole
• SQLAgentOperatorRole

Das heißt: Nur SQL-Server-Administratoren können diese Jobs erstellen. Da weder meine AppRole noch meine Anwender SQL-Server-Administratoren sind, kann meine App diese Jobs nicht erstellen. Hierzu müssten Mitarbeiter in den Rechenzentren manuell eingreifen, indem sie die Jobs manuell erstellen oder jemandem die entsprechenden Berechtigungen erteilen. Und spätestens an dieser Stelle erklärt sich der Begriff "hinterher telefonieren". Das geht leider gar nicht.

Deshalb suche ich immer nach Möglichkeiten, die Dinge quasi mit "Bordmitteln" und ohne fremde Hilfe (Serveradmins) umzusetzen.

Zitat von Blup:

Vieleicht funktioniert es wenn du das Kommando als Skript mit abschließendem Commit im Skript übermittelst:

markieren

SQL-Code:

execute procedure XXX;
commit;

Das geht leider auch nicht. Sobald die Connection geschlossen wird, wird auch die Ausführung der proc abgebrochen.

.. wenn Du die Kommunikation mit der Db über eine ServiceApplikation laufen lassen würdest,
diese hätte dann solange Verbindung zur DB wie der Rechner läuft.

Grüße
Klaus

Nja, du kannst dir den Scheduler selber bauen. Als DBO kannst du eine StoredProcedure erstellen, die immer läuft + zB Jobnamen aus einer Tabelle ausliest und diese ausführt. Dein programm muss also nichts anderes tun, als in die Tabelle den Jobnamen zu schreiben (oder ein Flag zu setzen) + ev. Parameter + gut ist es.
Als Variante kann dein Programm den Job neu ertselllen, solange sich die Signatur des Aufrufs nicht ändert, macht das ja nichts.

Siehe hier:
https://docs.microsoft.com/de-de/sql...l-server-ver15

Zitat:

There are two different ways to execute a stored procedure. The first and most common approach is for an application or user to call the procedure. The second approach is to set the procedure to run automatically when an instance of SQL Server starts.