Laden...

Überwachen von einer SQL Server Datenbanktablle

Erstellt von RayYago vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.777 Views
R
RayYago Themenstarter:in
19 Beiträge seit 2019
vor 4 Jahren
Überwachen von einer SQL Server Datenbanktablle

verwendetes Datenbanksystem: SQL Server + SSMS Tools

Hallo,

ich hatte eine ähnliche Frage bereits im Smalltalk gestellt, habe jetzt aber eine Spezifische Frage dazu:

Was wäre eine gute Möglichkeit, aus einem C# Dienst heraus eine SQL Server Tabelle zu überwachen?

Die Situation ist folgende:

Es gibt eine SQL Server Tabelle die nur ein paar Spalten beinhaltet. Dort werden Einträge abgestellt wann z.B. ein Vorgang komplett verpackt wurde. Sobald dieser Eintrag in der Datenbank erscheint, muss Sekunden später ein Lieferschein gedruckt werden. Es kann mehrere Einträge die Minute geben.

Nun möchte ich jeden neuen Eintrag gerne mitbekommen. Die Tabelle hat ein Verarbeitungsstatus, mit dem ich Abfragen kann, welche Einträge ich bereits abgearbeitet habe und welche offen sind.

Diese Eintrage möchte ich abfragen und dann dafür halt in der C# Anwendung (ich wollte ein Dienst dafür erstellen), die Daten weiter verarbeiten.

Ich Scrolle schon ein wenig durch das Web und die häufigsten Methoden scheinen zu sein:

  • SqlDependency
  • long polling

in vielen Artikeln habe User nur schlechtes über SqlDependency geposted, das Einträge häufig nicht erkannt werden etc.

Hat jemand Erfahrung damit?

Eine andere möglichkeit dachte ich mir, wäre vielleicht eine C# http Schnittstelle zu bauen und im SQL Server einen Tabellen Trigger zu verwenden, der für jeden Eintrag ein http Request schickt. Aber auch hier sagen die meisten "der SQL Server ist nicht dafür gemacht"

Kann mir jemand einen Tipp geben oder vielleicht Erfahrungen mitteilen. Ich soll den Aufwand abschätzen, bin mir aber nicht einmal sicher, wie ich genau vorgehen soll...

Danke im voraus!

T
461 Beiträge seit 2013
vor 4 Jahren

Dort werden Einträge abgestellt wann z.B. ein Vorgang komplett verpackt wurde. Sobald dieser Eintrag in der Datenbank erscheint, muss Sekunden später ein Lieferschein gedruckt werden. Es kann mehrere Einträge die Minute geben.

Ist nicht schon der Ansatz verkehrt?

Wieso werden die Lieferscheine nicht schon vom vorherigen System erstellt bzw. gibt es da keine Schnittstelle dazu, zu dem System?

Ich habe den Titel mal angepasst, so dass Suchende auch etwas damit anfangen können. EDIT: Ich sollte beim Wort "Shift" im Titel das "f" nicht vergessen... 😄

3.511 Beiträge seit 2005
vor 4 Jahren

Moin,

auch wenn ich ThomasE. zustimme, dass solch Notifications eigentlich in den Service selber gehören, kann man solche Fälle lösen, wenn man z.B. eine Message Queue verwendet:
MSMQ and SQL Server Integration

Gruß
Khalid

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

R
RayYago Themenstarter:in
19 Beiträge seit 2019
vor 4 Jahren

Es können keine korrekten Lieferscheine erstellt werden, das ganze System ist etwas älter und bietet keine Möglichkeit dafür. Zudem müssen die Lieferscheine aktuell sein, es kann sein das Ware verpackt wird aber nicht auf den LKW kommt. Im Post oben etwas falscher erklärt, der Lieferschein soll nur das beinhalten was wirklich auf dem LKW landet und das kann das eigentliche System momentan nicht. Deswegen der Umweg.

Aber das ist auch garnicht das Problem, das soll eine Übergangslösung werden bis das neue ERP System nächstes Jahr kommt.

Die variante mit MSMQ scheint mir relativ schwirig da man Einstellungen ander SQL Server Datenbank vornemmen muss, was mir leider nicht möglich ist.

2.298 Beiträge seit 2010
vor 4 Jahren

Wenn es nicht anders lösbar ist solltest du in der Datenbanktabelle eine "Status"-Spalte erngänzen.

Diese hat dann je nach dem wie der Verarbeitungsstatus ist einen anderen Wert(Standard wäre m.E 0 -nicht verarbeitet, 1 - erfolgreich verarbeitet, x - fehlgeschlagen).

Bei Eintragung in die Tabelle wird der Wert "0" voreingetragen. - Der Dienst ruft nun zyklisch alle im Status 0 ab, druckt den / die Lieferscheine und setzt den neuen Status (1 für erfolgreiche Drucks, x für Fehler).

Auf die Weise hast du später die Möglichkeit fehlgeschlagene Drucke durch Ändern des Status noch einmal ausführen zu lassen.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

F
10.010 Beiträge seit 2004
vor 4 Jahren

Ich habe in einem alten Projekt mit SqlDependency gearbeitet und da gab es nur bei den Kunden Probleme die ein unstabiles Netzwerk hatten.

Ich habe mich damit beholfen "gelegentlich" zu schauen ob die noch im Server registriert sind und ggf wieder neu erstellt.

Was die meisten falsch machen ist, die Sql Abfrage die man da benutzt, darf kein * beinhalten, und muss nach jedem auslösen neu erstellt werden.

R
RayYago Themenstarter:in
19 Beiträge seit 2019
vor 4 Jahren

@FZelle Danke erstmal für dein Erfahrungsbericht. Ich hätte da mal eine Frage wie du SQLDependency verwendet hast. Ich forsche gerade nach und probiere viel mit Testprojekten.

Ich sehe in manchen Projekten folgendes:


await this.sampleSqlCommand.ExecuteReaderAsync(CommandBehavior.CloseConnection);

und in anderen

using (SqlDataReader reader = command.ExecuteReader())
    //        {
    //            // Process the DataReader.
    //        }

Manche machen es Asyn und andere nicht. Macht es sind Aync zu benutzen, wenn man nur eine Tabelle überwachen möchte? Oder wäre Async in jedem Fall besser da dann mehr Datensätze abgearbeitet werden könne?

16.806 Beiträge seit 2008
vor 4 Jahren

Async macht immer Sinn, sobald I/O im Spiel ist.
Neue APIs/SDK bieten oft auch nur noch asynchrone Wege an - was auch gut so ist.

F
10.010 Beiträge seit 2004
vor 4 Jahren

Die Async Schlüsselwörter und damit auch die Funktionen im FW gibt es noch nicht so lange ( das pattern schon ),
so das du natürlich viel mehr Beispiele findest zur "alten" Herangehensweise.

Du musst nur verstehen das dieses Command nie Daten liefert, sondern lediglich dafür da ist die Anfrage an den Server zu stellen,
und man ja "irgendwann" benachrichtigt wird das diese Abfrage neue Daten geliefert hätte,
dann ist doch klar das sie in einem extra Task/Thread ablaufen muss.

Und seit wir Tasks haben ist das die deutlich resourceschonendere Variante.

Nur bei der Variante ohne async await, vergessen viele Leute das Command.Cancel was zu resourceproblemen führt.

Auch solltest Du, solange wie Du nicht wirklich fest bist in den Grundlagen, nicht irgendwelche Codes im Internet anschauen.
Da gibt es haufenweise Schrott.
Schau Dir an, wie es diejenigen die es designed haben tun.

Wenn ich mir manche Grundlagenbücher und vor allem Grundlagenvideos auf YT anschaue, dann schaudert es mich.

Viele gehen nach dem Motto vor, wir frickeln jetzt am Anfang, aber wir werden es später richten, nur nichts ist so beständig in der SW-Entwicklung wie das Provisorium.

Ich habe z.b. lange mit Buchautoren gestritten, das sie bitte niemals niemals niemals Parameter in SqlStrings frickeln sollen, nicht mal für das kleinste Beispiel, denn das was Du als erstes lernst bleibt am längsten hängen.
Und dann schau dir diese Teile mal in den Einsteigerbüchern an.

Also schau dir bitte erst die Grundlagen bei MS an, oder dem jeweiligen "Erfinder" von etwas, und wenn du es verstanden hast, dann, und erst dann, schaue Dir an, was andere daraus gemacht haben.