Servermeldung an Access

[rooney 10]

Hallo liebe Community,

brauche dringend Hilfe, googeln brachte nichts mehr. :-)

 

Hab ein Access Frontend und SQL Server 2008 Backend.

 

Auf einer Servertabelle habe ich einen Trigger laufen, der nach einem Delete eine Meldung ans Access ausgeben soll.

 

Habe es mit Print und Raiserror versucht. Der Print Befehl wird vom Access scheinbar völlig ignoriert. Raiserror ab severity 10 gibt zwar eine Meldung ans Access aus, jedoch halt eben eine Fehlermeldung, die der Nutzer nicht einfach ignorieren kann.

 

Wäre nett, wenn mir jemand helfen kann. Einfach nur eine Art Messagebox ans Access schicken. Dürfte doch nicht so kompliziert sein, oder? :confused:

 

Danke im voraus

[Dukel 454]

Ich habe jetzt keine konkrete Lösung, aber es kann schon sein, dass das kompliziert ist.

Woher soll MSSQL und der Trigger etwas vom Frontend wissen und an dieses etwas schicken? Mit Trigger kann man SQL Befehle ausführen.

 

Man kann ggf. mit dem Trigger in eine extra Tabelle schreiben und Access schaut regelmäßig in der Tabelle und reagiert darauf.

[phoenixcp 10]

Hallo Rooney

 

Du wirfst hier grundsätzliche Sachen durcheinander. Du erwartest von deiner Datenhaltungsschicht, das sie Meldungen an die Anzeigeschicht weiterreicht? Wie soll das denn gehen? Andersherum wird ein Schuh draus: wenn in der DB ein Error geworfen wird, dann muss die Anzeigeschicht darauf reagieren, sprich sich den Error abgreifen. Hierzu muss es aber auch die entsprechenden Anpassungen in der entsprechenden Anzeigeschicht geben. Ob das mit Access zu realisieren ist wage ich stark zu bezweifeln.

 

Gruß

Carsten

[rooney 10]

Mmh... danke erstmal für eure Antworten.

Wenn ein Fehler zum Client geschleift wird, sollte das doch mit einer Meldung auch funktionieren? :confused:

Laut Microsoft gibt das Kommando PRINT "eine benutzerdefinierte Meldung an den Client zurück."

 

Falls das so nicht funktioniert, vielleicht habt ihr eine andere Idee, wie ich das Problem lösen kann:

 

Aus einer Servertabelle verschwinden ständig Datensätze, die wahrscheinlich an irgendeiner Stelle im VBA-Code meines Access-Projektes gelöscht werden. Da dieser Code ziemlich groß ist, wollte ich die Servertabelle dazu bringen, zu dem Zeitpunkt des Löschens dem Nutzer einen entsprechenden Hinweis auszugeben.

Falls das Löschen an der Stelle nicht erwünscht war, könnte ich zumindest den Suchbereich im VBA-Code stark eingrenzen.

 

Viele Grüßé

Rooney

[hh2000 10]

Moin,

 

PRINT geht nicht, RAISERROR ist hier Dein Freund.

 

Wie Dukel schon schrieb, per Delete-Trigger die "Löschungen" protokollieren und bei Beschwerden über fehlenende Daten, Logtabelle durchsuchen.

 

Gruß Kai

[rooney 10]

Hallo zusammen,

mit raiserror kann ich eine Meldung an den Client schicken, jedoch nur mit einer severity >= 10. Access behandelt dies dann wie ein Fehler und springt in den debug-Modus.

Jedoch darf der Nutzer ja auch Datensätze löschen, was den Fehler dann auch auslöst.

Die Protokolierung der gelöschten Datensätze in einer Tabelle hab ich. Jetzt weiß ich zumindest welche Datensätze unbeabsichtigt gelöscht wurden, jedoch nicht wann bzw. welches Access-Ereignis (Modul) den Delete ausgelöst hat?

 

Beste Grüße

[Dukel 454]

Wer hat die Anwendung den entwickelt? Derjenige sollte das doch debuggen können.

[hh2000 10]

Es muss in Access eine Fehlerbehandlung implementiert sein, um den RAISERROR abzufangen. Da du den Code nicht anfassen willst, solltest du im Log-Trigger Datum und Username (oder wird hier mit nur einem zentralen User gearbeitet?) mitprotokollieren, vielleicht reicht das ja an Information.

z.B.

Tabelle.User = SUSER_SNAME(),

Tabelle.Zeit = CURRENT_TIMESTAMP

 

Du könntest auch mit einer mdE statt einer mdB arbeiten, dann sollte RAISERROR einen Fehler melden, aber der client macht anschließend weiter.

 

Das sind nur Workarounds. Besser ist es, eine Fehlerbehandlung einzubauen.

Access: On Error Goto ....

SQL: RAISERROR

 

Gruß Kai

[Dukel 454]

Noch besser wäre es das Problem an der Wurzel zu beheben und den Fehler im Programm zu entfernen.