[Gelöst] Kryptische Meldung wg. Berechtigung vom SQL Server

Hallo,

wir haben ein zur besseren Übersicht der aktuellen Änderungsprotokollposten ein Änderungsprotokollpostenarchiv erstellt. Dieser Report ruft nach erfolgreichen "archivieren" (entspricht einer Kopie) unter anderem den Löschreport des Änderungsprotokolls auf. Auf unserem Entwicklungssystem funktioniert es soweit. Nun wollen wir es auf unserem Testsystem zum laufen bringen und erhalten die Fehlermeldung u.a. " 42000[Microsoft][ODBC SQL Driver][SQL Server]"aus dem Screenshot.

screen.jpg

Weis jemand einen Rat? Welche Informationen sind für die Fehlersuche relevant?

Viele Grüße,

Janosch

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Zuletzt geändert von janosch am 11. März 2010 12:30, insgesamt 1-mal geändert.

Sofern die ausgeschwärzen Namen stimmen, und da geh ich jetzt mal von aus, fehlen dem ausführenden Benutzer die Rechte auf diese Tabelle.
Du kannst ja das ganze mal mit seinem SA laufen lassen und schauen ob es dann klappt.
Wenn es das war die Rechte des eigentlichen Benutzers noch anpassen.

Hi!

Das Problem ist folgendes:
Wenn ich richtig verstanden habe, dann habt ihr die "Change Log" Funktionalität kopiert?
In "Change Log Entry" wird die "Entry No." via "AutoIncrement" (= IDENTITIY INSERT) erzeugt; d.h. der SQL Server vergibt die Nummern selber.
AI funktioniert aber nur, wenn kein expliziter Wert - hier für "Entry No." - vorgegeben wird; d.h. "Entry No." muss mit 0 (Null) initialisiert sein. Wird ein Wert <> 0 vorgegeben, dann versucht NAV die AI/IDENTITY INSERT Eigenschaft zur Laufzeit zu ändern - und das dürfen nur User der Rolle "db_owner". Ist der User nur "public" wird exakt der beschriebene Fehler generiert.
Oft wird bei solchen Sachen in NAV vergessen, dass z.B. ein INIT die Primärschlüssenfelder nicht (!) initialisiert; da "Entry No." eben PK ist, kann es hier also passieren dass Werte <> 0 mitgegeben werden ...

An den Stellen, wo hier DS eingefügt werden, muss man im Prinzip wie folgt vorgehen:

Code:

ChangeLogEntry.INIT;
ChangeLogEntry."Entry No." = 0;
...
ChangeLogEntry.INSERT;

Hoffe das hilft was!

Schöne Grüße,
Jörg

Hallo Jörg und Danjo,

vielen Dank für eure Antworten.

Wenn ich richtig verstanden habe, dann habt ihr die "Change Log" Funktionalität kopiert?

Richtig.

In "Change Log Entry" wird die "Entry No." via "AutoIncrement" (= IDENTITIY INSERT) erzeugt; d.h. der SQL Server vergibt die Nummern selber.
AI funktioniert aber nur, wenn kein expliziter Wert - hier für "Entry No." - vorgegeben wird; d.h. "Entry No." muss mit 0 (Null) initialisiert sein. Wird ein Wert <> 0 vorgegeben, dann versucht NAV die AI/IDENTITY INSERT Eigenschaft zur Laufzeit zu ändern - und das dürfen nur User der Rolle "db_owner". Ist der User nur "public" wird exakt der beschriebene Fehler generiert.
Oft wird bei solchen Sachen in NAV vergessen, dass z.B. ein INIT die Primärschlüssenfelder nicht (!) initialisiert; da "Entry No." eben PK ist, kann es hier also passieren dass Werte <> 0 mitgegeben werden ...

An den Stellen, wo hier DS eingefügt werden, muss man im Prinzip wie folgt vorgehen:

Code:

ChangeLogEntry.INIT;
ChangeLogEntry."Entry No." = 0;
...
ChangeLogEntry.INSERT;

Ich werde deinen Hinweis prüfen. Deiner Beschreibung nach müsste das der Grund sein. Melde mich sobald ich es verifizieren konnte.

Vielen Dank erst Mal.

Viele Grüße,

Janosch

Hallo Jörg,

An den Stellen, wo hier DS eingefügt werden, muss man im Prinzip wie folgt vorgehen:

Code:

ChangeLogEntry.INIT;
ChangeLogEntry."Entry No." = 0;
...
ChangeLogEntry.INSERT;

dieser "kleine" aber feine Unterschied hat es ausgemacht. Vielen Dank! Sind schon ziemlich ins Schwitzen gekommen woran es lag.

Viele Grüße,

Janosch

Gern geschehen
Dieses Problem ist sowas wie ein "Klassiker"

Hallo Jörg,

ich bin es leider noch Mal. Nachdem es letzte Woche so aussah als ob das Problem gelöst wäre, haben wir nun folgendes Verhalten:

- Wenn der Archvierungsvorgang (als ganzes, erst kopieren, dann löschen) immer sauber beendet wird, funktioniert es einwandfrei.
- Wenn der Archivierungsvorgang einmal abgebrochen wird (z.B. Frage vom Löschreport des Änderungsprotokollposten "Wollen sie wirklich löschen"), wird zwar alles zurück gerollt, aber der Zähler vom Autoincrement in der Zieltabelle bleibt um die x NICHT archivierten Einträge stehen und wird nicht auf den Wert VOR der Transaktion zurückgesetzt.

Das bedeutet für mich, das wir mit dem Auto Increment nicht arbeiten können oder gibt es hier einen andere Lösung?

Daher gehen wir nun jetzt folgendermaßen vor: Wenn ich das Änderungsprotokoll archivieren will, nehme ich jetzt einfach die LFD weiterhin als Key, diesen lasse ich aber nicht mehr per Autoincrement vergeben, sondern übernehme diese direkt aus den Änderungsprotokollposten. Oder gibt es eine elegante Lösung?

Viele Grüße,

Janosch

Hi!
Das Verhalten ist (leider) normal bei AI. Ich denke deine Lösung - das Kopieren der "Entry No." - ist hier am praktikabelsten!

Hallo Jörg,

ok. Haben wir dann nu auch so gemacht. Danke für die Antwort!

Viele Grüße,

Janosch