NGA

Oh ja, habs nicht genau gelesen. Dachte es geht nur um eine DB.

Hey, du könntest die Serverrolle "dbcreator" ausprobieren. Ansonsten einfach eine eigene Rolle mit spezifizierten Rechten anlegen.

Hallo, das ist nur eine kleine Test Prozedur :) , um zu sehen wie sich THROW etc. überhaupt auswirkt. Man gehe davon aus, die Queries wären voneinander abhängig. Vorher sah die Prozedur so aus, um einen Fehler zu provozieren: (Null- Werte werden in der Spalte "test_text" nicht erlaubt) -- Step 1 INSERT INTO AccessTests.dbo.excp_test (test_text) VALUES (null); -- Step 2 INSERT INTO AccessTests.dbo.excp_test2 (test_text2) VALUES ('test'); Dann wird eine Fehlermeldung richtig zurückgegeben. Uns ging es nur um die Infomeldungen. Wir wollen in Zukunft die meiste Programmlogik auf dem SQL- Server in den Prozeduren lassen, um Grund- Funktionen nicht im Access Programm haben zu müssen, die dann einen neuen Rollout des Programmes erfordern. Dadurch dass aber RAISERROR (veraltet seit 2012) und THROW eine Meldung vom Typ Error an unsere VBA Klasse liefert, müssen wir darin prüfen, ob "200Info" in der zurückgegebenen Meldung enthalten ist. Wenn ja --> Kein Fehler - Wenn nein: Fehler

Hallo, wir besitzen einen SQL- Server 2012 der auf einem Windows Server 2012 R2 läuft. Im Unternehmen werden einige Access- Programme für beispielsweise Abwesenheitsliste, Urlaubsprogramm usw. verwendet. Access dient hier als Front- End. Via einer eigens entwickelten Verbindungsklasse (ADO) wird die Verbindung zwischen Front- End und Back- End hergestellt. Stored Procedures dienen dann zur Abhandlung von Datenbankeinträgen, -updates oder -löschungen. Nun ist es aber so, dass wir bei manchen Aktionen an den Client eine Fehler-/Infomeldung anzeigen lassen wollen. Verwendet werden soll hier die TSQL- Funktion "THROW". Fehlermeldungen anzuzeigen ist kein Problem. Bei Infomeldungen haben wir folgendes überlegt: if @proctype = 3 -- check how info messages thrown BEGIN BEGIN TRANSACTION t1; BEGIN TRY -- Step 1 INSERT INTO AccessTests.dbo.excp_test (test_text) VALUES ('t'); -- Step 2 INSERT INTO AccessTests.dbo.excp_test2 (test_text2) VALUES ('test'); COMMIT TRANSACTION t1; THROW 53000, '200INFO! Daten erfolgreich gespeichert', 1 END TRY BEGIN CATCH --PRINT 'Catch block2'; IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION t1; THROW; END CATCH END Sobald die beiden INSERTs ok sind, wird ein COMMIT der Transaktion t1 durchgeführt. Somit ist die Transaktion abgeschlossen. Über THROW wird nun eine Meldung erzeugt, die an den Client (Access- Programm) zurückgeliefert wird. Dadurch, dass THROW aber eigentlich verwendet wird, um Fehler zurückzugeben, springt das Skript in den CATCH- Block. Die Prüfung bezüglich dem @@TRANCOUNT (prüft, Anzahl von BEGIN TRANS...) verhindert, dass ein ROLLBACK der vorher positiv abgewickelten SQL- Queries durchgeführt wird. Nun könnten wir die Meldung, die vom SQL- Server zurückgeliefert wird in unserer VBA- Verbindungsklasse parsen und prüfen, ob das Muster "200INFO!" darin enthalten ist. Dadurch können wir den Programmablauf besser steuern --> Recordset = true und nicht false. Gibt es eine schönere Variante? Wasw meint ihr dazu? Hab schon einige Einträge im Internet durchsucht, aber nichts besseres gefunden. Ich bedanke mich schon einmal für eure Antworten.