Native DB oder SQL DB
17. März 2007 01:09
Hallo,
habe hier schon des öfteren gelesen, dass das Setzen von SETCURRENTKEY bei Einsatz von SQL nicht unbedingt sinnvoll ist.
Kann man per Code ermitteln, ob es sich bei DB um eine Native DB handelt, oder aber ob ein SQL Server im Hintergrund arbeitet.
Gruß und Danke
Bobby
habe hier schon des öfteren gelesen, dass das Setzen von SETCURRENTKEY bei Einsatz von SQL nicht unbedingt sinnvoll ist.
Kann man per Code ermitteln, ob es sich bei DB um eine Native DB handelt, oder aber ob ein SQL Server im Hintergrund arbeitet.
- Code:
Native = Funktionsaufruf (mit Ergebnis Native oder SQL)
IF Native THEN
SETCURRENTKEY();
Gruß und Danke
Bobby
17. März 2007 01:31
Ja, es gibt einen Weg, um herauszufinden, ob der MS SQL-Server eingesetzt wird:
Der Navision Database Server unterstützt nur TableLocking, wohingegend der MS SQL-Server auch RecordLevelLocking unterstützt, und genau dafür gibt es einen Befehl:
Um es mal ganz laienhaft zu erklären:
Wenn du dem SQL-Server mit SETCURRENTKEY einen Schlüssel übergibst, dann interpretiert er das als "Wunsch/Vorschlag" und prüft, ob dieser Vorschlag einen Sinn ergibt bzw. ob er einen besseren Schlüssel findet.
Lässt du es bleiben, so sucht er sich selbst den besten Schlüssel und braucht nicht noch zusätzlich deinen Vorschlag zu prüfen.
Der Navision Database Server unterstützt nur TableLocking, wohingegend der MS SQL-Server auch RecordLevelLocking unterstützt, und genau dafür gibt es einen Befehl:
- Code:
IF RECORDLEVELLOCKING THEN
// MS SQL-Server im Einsatz
ELSE
// Navision Database Server im Einsatz
Um es mal ganz laienhaft zu erklären:
Wenn du dem SQL-Server mit SETCURRENTKEY einen Schlüssel übergibst, dann interpretiert er das als "Wunsch/Vorschlag" und prüft, ob dieser Vorschlag einen Sinn ergibt bzw. ob er einen besseren Schlüssel findet.
Lässt du es bleiben, so sucht er sich selbst den besten Schlüssel und braucht nicht noch zusätzlich deinen Vorschlag zu prüfen.
17. März 2007 14:37
VON EINEM SOLCHEN VERFAHREN RATE ICH DRINGEND AB
Grundsätzlich gilt: SETCURRENTKEY bestimmt die ORDER BY clause des SQL Statements; fehlt SETCURRENTKEY, so wird im ORDER BY der Primäschlüssel gesetzt.
Ob ein SETCURRENTKEY sinnvoll ist oder nicht hängt von einigen Faktoren ab:
Wie sieht die Abfrage aus? Ist Sortierung/Gruppierung erfroderlich? Welche Filter sind gesetzt? Welche Indexe existieren? Wie sieht der Primärschlüssel aus? Wie ist der gruppierte Index aufgebaut?
Man kann sagen: Existiert ein optimaler Index der für die Bearbeitung einer Abfrage genutzt werden kann (Filter!!!), und spielt die Sortierung des Result-Sets keine Rolle, und entspricht der gruppierte Index dem Primärschlüssel, so ist es besser auf SETCURRENTKEY zu verzichten, als eine schlechten SETCURRENTKEY zu verwenden (also anders zu Filtern als zu Sortieren); andernfalls muss SQL Server "kostspielig" die Datensätze umsortieren.
Aber in den meisten Fällen spielt die Sortierung der Daten in NAV eben schon eine Rolle; eine fehlender SETCURRENTKEY würde dann die Prozess-Logik zerstören.
Ebenso ist es im Standard i.d.R. der Fall, daß zu jedem Key auch ein Index existiert; auch werden Filter meistens nur auf Felder dieses Keys/Index gesetzt; d.h. WHERE und ORDER BY clause passen ohnehin zusammen - damit ist der SETCURRENTKEY kein Problem.
Lediglich in Einzelfällen, wenn man Indexstrukturen z.B. von Hand optimiert, kann so eine Maßnahme zur Perfromance Steigerung beitragen; werden hier Fehler gemacht, dann "geht der Schuss nach hinten los".
Wer also hier nicht GENAU weiß, was er tut, sollte lieber die Finger davon lassen ...