Tweet
Guten Tag,
ich haben micht mit unserem Problem schon schwarzgesucht im Netz und keine berfiedigende Antworten gefunden. Ich verspreche mir hier bei entwicklerforum näheres zu erfahren.
Wir haben eine WinForms-Anwendung mit typisiertem DataSet.
Zusätzlich zum DS gibts im Code noch die ein oder andere "adhoc" SqlConnection die, falls benötigt, kurz geöffnet wird um updates zu schreiben.
Grundsätzlich gibts einen connectionstring und einen einzigen user mit dem connections zum server geöffnet werden.
Nun wollen wir updates/inserst/deletes historisieren. Eingentlich kein Problem. Jedoch soll hier der aktuell an der Applikation angemeldete User geschreiben werden und nicht der User über den die Connection läuft. Leider kennt der SQL-Server 2005 nur den User der Connection.
Was wir tun könnten wäre bspw. die context_info ( sysprocesses) via @@spid abzufragen. Diese gilt aber nur für die aktuelle Session. Da aber ADO die Connection laufend öffnet (und wir um code auch adhoc Connections öffnen und schliessen, wären die context_infos weg weil wir ja eine neue @@spid bekommen.
- Also, jedesmal vor jeder connection/Statement explizit eine prozedur anstossen mit der wir die context_info selbst setzen, um diese dann im trigger abfragen zu können? Ist das nötig und...
- ...wie sage ich das dann dem DataSet, dass immer bestimmte Infos gesetzt werden sollen - wir müssten dazu ja die SQLConnection-klasse überschreiben?
- CLR-Trigger, also die Trigger in C# schreiben und sie dort ausführen?
Es muss doch einen ganz simplen, einfacheren Weg geben in ADO.NET dem DataSet/Adaptern etc.pp, quasi "global" einzustellen dass der Datenbank noch bestimmte infos zur Verfügung gestellt werden, oder?
Wo sind diese zu setzen?
Wir würden die Trigger aber gern auf der DB belassen.
Vielen Dank schon im voraus für Eure Unterstützung.
ich haben micht mit unserem Problem schon schwarzgesucht im Netz und keine berfiedigende Antworten gefunden. Ich verspreche mir hier bei entwicklerforum näheres zu erfahren.
Wir haben eine WinForms-Anwendung mit typisiertem DataSet.
Zusätzlich zum DS gibts im Code noch die ein oder andere "adhoc" SqlConnection die, falls benötigt, kurz geöffnet wird um updates zu schreiben.
Grundsätzlich gibts einen connectionstring und einen einzigen user mit dem connections zum server geöffnet werden.
Nun wollen wir updates/inserst/deletes historisieren. Eingentlich kein Problem. Jedoch soll hier der aktuell an der Applikation angemeldete User geschreiben werden und nicht der User über den die Connection läuft. Leider kennt der SQL-Server 2005 nur den User der Connection.
Was wir tun könnten wäre bspw. die context_info ( sysprocesses) via @@spid abzufragen. Diese gilt aber nur für die aktuelle Session. Da aber ADO die Connection laufend öffnet (und wir um code auch adhoc Connections öffnen und schliessen, wären die context_infos weg weil wir ja eine neue @@spid bekommen.
- Also, jedesmal vor jeder connection/Statement explizit eine prozedur anstossen mit der wir die context_info selbst setzen, um diese dann im trigger abfragen zu können? Ist das nötig und...
- ...wie sage ich das dann dem DataSet, dass immer bestimmte Infos gesetzt werden sollen - wir müssten dazu ja die SQLConnection-klasse überschreiben?
- CLR-Trigger, also die Trigger in C# schreiben und sie dort ausführen?
Es muss doch einen ganz simplen, einfacheren Weg geben in ADO.NET dem DataSet/Adaptern etc.pp, quasi "global" einzustellen dass der Datenbank noch bestimmte infos zur Verfügung gestellt werden, oder?
Wo sind diese zu setzen?
Wir würden die Trigger aber gern auf der DB belassen.
Vielen Dank schon im voraus für Eure Unterstützung.
Comment