[gelöst] Auf NAV SQL entwickeln und in Nativ importieren

[Perfi]

Hallo,

wir haben noch viele Kunden mit NAV als Nativ Datenbank und einige mit SQL Datenbank.
Auf unserem Server haben wir die Datenbanken unserer Kunden als Kopie gespeichert und entwickeln dort für sie die Objekte.

Jetzt würden wir gerne alle unsere gespeicherten Datenbank Kopien auf SQL Basis portieren und dort die Entwicklung fortführen.
Ich habe aber von anderen Entwicklern gehört, dass es Probleme geben kann, wenn man Objekte auf einer SQL Datenbank entwickelt, exportiert und später bei Kunden in seiner Nativ Datenbank importiert.
Stimmt das?

Gruß
Perfi

[McClane]

Aus meiner Erfahrung kann ich dir nur sagen, dass ich manchmal andere Ergebnisse kriege, wenn ich auf Native entwickle, und die Objekte dann auf den SQL-Server schiebe (ich weiß, andersrum als bei dir).
Das liegt daran, dass sich der SQL-Server die Daten gerne mal so holt, wie er das für richtig hält und nicht so, wie es die native tut.
Das kann zu einer anderen Sortierung in einer Form/einem Report und ordentlichen Performance-Unterschieden führen.

Daraus resultierte aber bisher nur etwas Nacharbeit. Sonst hatte ich noch keine Schwierigkeiten.

[stryk]

Aaaaaalso ... der SQL Server holt sich in der Tat die Daten tatsächlich "so wie er es für richtig hält", weil das Verfahren so auch richtig IST

Das Problem ist eigentlich, dass man sich der native Server einen Dr... um ISO-Standards schert (und das auch noch als "Feature" preist ), wenn es um die Sortierung von "Code" Typ Feldern geht:

"Code" ist ein alphanumerischer Datentyp, deshalb sollten Felder hier alphabetisch sortiert werden. Tut NAV "native" aber nicht, hier wird eine pseudo nummerische Sortierung verwendet; also z.B. 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 - das widerspricht (IMHO) jeglichen ISO-Standards!
SQL Server hält sich aber an die Spielregeln: "Code" - in SQL "varchar" - wird strikt alphabetisch sortiert; also: 1, 10, 11, 2, 3, 4, 5, 6, 7, 8, 9 - und das ist so auch KORREKT!

Das die Reihenfolge solcher Felder von C/SIDE zu SQL Server unterschiedlich ist wird vor allem dann zum Problem, wenn gefiltert wird: So liefert der Filter "1 .. 10" (eins bis zehn) unter C/SIDE 10 Datensätze, mit SQL Server nur 2 Datensätze ...

Deshalb (u.a.) ist es absolut notwendig Systeme auf der richtigen Plattform zu entwickeln!

[MatthiasKönig]

naja, die Probleme gehen von der sortierung bis hin zur datierung los und enden sicher noch nicht dort!

ich wuerde ehr empfehlen auf dem DBMS zu entwickeln, was der Kunde selbst auch nutzt!

ahh Stryk war schneller :D

[Perfi]

Mit Performance Unterschieden habe ich auch gerechnet.
Das ist auch verständlich, da der SQL u.U. auf andere Weise seine Indizes Aufbaut und auf sie zugreift.

Aber der Code in der SQL ist doch eigentlich der gleiche, wie in der Nativ.
Beide läufen ja schließlich auch in der unangepassten Basis-Version von Navision.
Interpretiert denn der SQL den Code anders als die Nativ?

Ahh, Stryk war auch hier schneller !!!

[MatthiasKönig]

wie gesagt, der SQL server sortiert anders! wenn du also ein REPEAT UNTIL machst, ist das schon was anderes!

BTW Stryk (auch ma eben OOT)

"Code" ist ein alphanumerischer Datentyp, deshalb sollten Felder hier alphabetisch sortiert werden. Tut NAV "native" aber nicht, hier wird eine pseudo nummerische Sortierung verwendet; also z.B. 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 - das widerspricht (IMHO) jeglichen ISO-Standards!
SQL Server hält sich aber an die Spielregeln: "Code" - in SQL "varchar" - wird strikt alphabetisch sortiert; also: 1, 10, 11, 2, 3, 4, 5, 6, 7, 8, 9 - und das ist so auch KORREKT!

ist dir hier schon einmal aufgefallen temporaere Tabellen nocht anders sortiert werden als native und/oder SQL Tabllen? Kennst du den Grund hierfuer? ich habe bis auf "der sortiert halt anders als SQL, das ist klar, ist der CLIENT nicht das DBMS" keine Gute argumentation aber warum sortiert der auch anders als die Native? weisst du/jemand andere das?

[Perfi]

Ok, das scheint jetzt sehr klar zu sein. Es können also wegen dieser anderen Interpretation der Sortierung an jeder Ecke Probleme entstehen.
Dann werden wir die DBMS in dem Zustand lassen, in dem sie sich auch jetzt befinden.
Danke Stryk & MatthiasKönig.

Gruß
Perfi

[McClane]

Aaaaaalso ... der SQL Server holt sich in der Tat die Daten tatsächlich "so wie er es für richtig hält", weil das Verfahren so auch richtig IST

Kleines Missverständnis, das meinte ich natürlich genau so

Mit Performance Unterschieden habe ich auch gerechnet.
Das ist auch verständlich, da der SQL u.U. auf andere Weise seine Indizes Aufbaut und auf sie zugreift.

Vor allem kann der SQL-Server einen miesen oder gar fehlenden Schlüssel durch einen schlauen ersetzen. Das kann bedeuten: auf SQL läuft alles fix, Native aber zum Gähnen, Kaffepause machen, in Urlaub fahren.

Aber der Code in der SQL ist doch eigentlich der gleiche, wie in der Nativ.
Beide läufen ja schließlich auch in der unangepassten Basis-Version von Navision.
Interpretiert denn der SQL den Code anders als die Nativ?

Bei einem verwendeten Key, der nicht voll qualifiziert ist, kann das passieren. Ist er voll qualifiziert, hat ihn der SQL-Server auch so, und dann gibt´s eigentlich - außer der grundsätzlich anderen Sortierung bei Code - keine Probleme.

[Timo Lässer]

Aus meiner langjährigen Erfahrung kann ich nur dringend empfehlen, dass euer jeweiliges Entwicklungssystem so ähnlich wie möglich dem beim Kunden eingesetzten Echtsystem entspricht.

Dies umfasst u. a.:
- Native oder SQL
- DB-Version (Objektstand) / RunTime-Version (fin.exe) / SQL-Version (2000, 2005, 2008)

Wir gehen bei uns sogar soweit, dass wir für jede RunTime-Version ein eigenes Client-Verzeichnis auf den PCs/Notebooks haben.
Mit "jede" meine ich auch absolut jede Version: Jedes SP, HF und auch sonstiges Update, welches die Build-Nummer der fin.exe/finsql.exe ändert, wird als eigenständiges Verzeichnis vorgehalten.
Im Laufe der Zeit sammeln sich da natürlich unzählige Verzeichnisse an.

Ebenso haben wir für jede Native-DB einen eigenen Native-Serverdienst in der exakt gleichen Build-Version.
Logischerweise haben wir auch mehrere SQL-Server, um die SQL-DBs in der entsprechenden Umgebung laufen zu lassen.

Das Einzige, was sich bei uns (logischerweise) von der tatsächlichen Kunden-Umgebung unterscheidet, ist die Hardware-Umgebung.
Da in aller Regel unsere Server etwas älter sind und deutlich mehr Datenbanken hosten müssen, ist die Performance auf unseren Systemen schlechter als auf dem Kundensystem.
Dies sehen wir jedoch als großen Vorteil, denn wenn die Anpassung bei uns schnell läuft, dann ist es beim Kunden noch viel schneller.

In ganz wenigen Großprojekten setzen wir jedoch sogar die exakt gleiche Hardware-Umgebung mit absolut identischer Konfiguration ein.
Dies stellt aber die Ausnahme dar.

[Perfi]

Danke Timo, für die präzise Antwort.

Wir haben mit der Zeit auch viele Client-Verzeichnisse auf jedem Rechner angesammelt.
Ich werde also ebenso wie Du so nah an der Kundenkonfiguration bleiben um Fehlerquellen auszuschliessen.

Nochmals danke an alle für die Hilfe.

Gruß
Perfi

[stryk]

ist dir hier schon einmal aufgefallen temporaere Tabellen nocht anders sortiert werden als native und/oder SQL Tabllen? Kennst du den Grund hierfuer? ich habe bis auf "der sortiert halt anders als SQL, das ist klar, ist der CLIENT nicht das DBMS" keine Gute argumentation aber warum sortiert der auch anders als die Native? weisst du/jemand andere das?

Ja, das Thema ist mir bekannt. Der Grund dafür ist, dass "temporäre" NAV Tabellen rein Client-seitige Gebilde (keine SQL Tabellen, nix in "tempdb" o.ä.) sind, die von C/SIDE erzeugt werden und deshalb den "nativen" Gesetzmäßigkeiten unterliegen ...

[MatthiasKönig]

@Stryk
meiner Erfahrung nach, sortieren diese aber noch anders als die Native Datenbank! was besagen wuerde "nativen-temp-table" gesetzmaeßigkeiten oder?

[stryk]

Vor allem kann der SQL-Server einen miesen oder gar fehlenden Schlüssel durch einen schlauen ersetzen.

Das ist so nicht ganz richtig; dieses weit verbreitete Mis(t)verständnis resultiert IMHO daraus, dass in nativem C/SIDE der Begriff "Key" und "Index" nicht wirklich unterschieden wird.
Definitionsgemäß ist ein "Key" ein CONSTRAINT - also eine "Einschränkung" oder auch "Regel". z.B. ist beim "Primary Key" die Einschränkung/Regel, dass jeder Wert eindeutig sein muss.
Alle anderen "Keys" in NAV - neben dem PK - sind eigentlich keine "Keys" sondern "Indexe": eine interne Hilfstruktur zum Auffinden von Datensätzen.

Während in C/SIDE Key & Index zu einem "Ding" vermischt wird, so wird in SQL schon deutlich unterschieden!

Am "Key" ändert der SQL Server gar nix - niemals nicht. Der in NAV definierte "Key" - per SETCURRENTKEY, Property, etc., egal ob voll- oder teilqualifiziert - bestimmt lediglich die Sortierung bei einer Abfrage, also die ORDER BY Clause. Wird kein "Key" explizit gesetzt, dann wird der PK verwendet.

Wenn es nun um das "Auffinden der DS" geht, dann wählt sich SQL Server den passenden "Index" dazu autark! Dazu wird in erster Linie der gesetzte Filter betrachtet (WHERE Cause) und erst in zweiter Priorität wird auf die Sortierung eingegangen; dennoch sollten "Key" (Sortierung) und "Index" (Filter) nicht zu unterschiedlich sein, da dies sonst Performance-Probleme heraufbeschwören kann.
Mittels "Index Hinting" kann man die SQL Server Index-Selektion übersteuern; d.h. man kann den zu verwendenden Index vorgeben - hier muss man genau wissen, was man macht, ansonsten erzeugt man eher Probleme.

Zu beachten ist dabei auch folgendes:
Je nach "Patch-Level" (also der NAV Build Nummer) werden für Result-Sets entweder "Fast Forward Cursor" (FFC) oder "Dynamic Cursor" (DC) verwendet.
FFC optimieren für den Filter (WHERE), DC für die Sortierung (ORDER BY). D.h. mit DC kann es mitunter zu erheblichen Problemen kommen - aber wie gesagt, aktuelle Updates stellen (wieder) um auf FFC.
Ein Beispiel dazu:

SELECT * FROM "G_L Entry" WHERE "G_L Account No_" = '12345' ORDER BY "Entry No_"

EIn FFC würde den Index "$1" ziehen (gehört zum "Key" "G/L Account No.", "Posting Date"), wegen "G/L Account No.". Der Plan wäre dann ein schneller "Index Seek".
Ein DC würde "...$0" ziehen (PK "Entry No."). Da dieser Index keinerlei Info zu "G/L Account No." enthält, bleibt nix anderes übrig als ein lahmer "Index Scan" ...

Schönes Wochenende,
Jörg

[stryk]

@Stryk
meiner Erfahrung nach, sortieren diese aber noch anders als die Native Datenbank! was besagen wuerde "nativen-temp-table" gesetzmaeßigkeiten oder?

Echt? Das muss ich mir mal näher ansehen ...

[mikka]

@Stryk
meiner Erfahrung nach, sortieren diese aber noch anders als die Native Datenbank! was besagen wuerde "nativen-temp-table" gesetzmaeßigkeiten oder?

Echt? Das muss ich mir mal näher ansehen ...

@MatthiasKönig
Hast du ggf. ein Beispiel hierzu?

Aus meiner Erfahrung kann ich dir nur sagen, dass ich manchmal andere Ergebnisse kriege, wenn ich auf Native entwickle, und die Objekte dann auf den SQL-Server schiebe (ich weiß, andersrum als bei dir).

Kleine Zwischenfrage:
Das Ergebnis sollte doch bei einer guten Programmierung immer gleich sein
Der Unterschied kann doch nur in der Sortierung sein, oder ?!

[McClane]

Das Ergebnis sollte doch bei einer guten Programmierung immer gleich sein

Na schönen Dank. DAS habe ich nun auch verstanden

Der Unterschied kann doch nur in der Sortierung sein, oder ?!

Exakt. Nehmen wir zB eine selbst gebaute EK-Historie, analog zu der im Verkauf. Als Sorting nimmt man "Buy.from Vendor No.", und auf der Native kommen die EK-Zeilen fein sortiert nach Belegnummer und Zeilennummer.

Schiebt man das auf den SQL-Server, war es bei mir zB so, dass die Zeilen nach der Belegnummer und der Artikelnummer sortiert sind. Das sieht da reichlich verwirrend aus. Das war mit anderen Ergebnissen gemeint.

[MatthiasKönig]

Das Beispiel:

ersteinmal kleine erlaeuterung!
Es war gemeint, dass eine Form mit Temporaerer Tabelle in SQL anders sortiert als Native und als SQL. Dies ist anders mit dem Native Client, hier sortiert Temp. und Normale Tabelle (bzw. referenz) gleich.

Beispiel:
1 Tabelle die nur ein Codefehlt besitzt.

1. Bild: SQL Client, Temporaer
2. Bild: SQL Client, nicht Temporaer
3. Bild: Native Client, Temporaer
4. Bild: Native Client, nicht Temporaer

die Bilder 1 und 3 (die Temporaeren) sind die interessanten....

hatt einer von euch dafuer eine plausible erklaerung?

[stryk]

Genau so wie ich es erwartet habe:

In "native" C/SIDE wird pseudo-nummerisch sortiert - sowohl beim Temp-Tabellen als auch bei "normalen".
Mit SQL Server wird "normal" alphabetisch sortiert, nur bei Temp-Tabellen wird auf das native Verfahren umgeschaltet.

Somit muss mann "höllisch" aufpassen, wenn man von C/SIDE nach SQL migriert, und temporäre Tabellen verwendet ... Ein einheitlicher Weg würde uns einige Probleme in der Programmierung etc. ersparen ...

[MatthiasKönig]

Mit SQL Server wird "normal" alphabetisch sortiert, nur bei Temp-Tabellen wird auf das native Verfahren umgeschaltet.

entweder bin ich blind oder sehe unterschiede zwischen der SQL Temp und der Nativen Version O.o

[stryk]

Nö - biste nicht, aber ich! Jetzt seh' ich's auch ... also doch 3 Versionen

[mikka]

Das Ergebnis sollte doch bei einer guten Programmierung immer gleich sein ?

Na schönen Dank. DAS habe ich nun auch verstanden

Das beruhigt mich, ich dachte schon es gibt Unterschiede von denen ich / wir bisher nicht wusten.
-->"Na schönen Dank" Ich wollte dir nicht "auf die Füße treten", nur das Thema hinterfragen. Falls ich es doch getan habe, dickes Sorry


@MatthiasKönig und Stryk
Danke Euch beiden, für diese wertvolle Info.
Das wird bestimmt Probleme bei der künftigen Entwicklung vermeiden

[t000bi]

Obwohl der SQL-Server nach ISO-Standard sortiert, gibt es denn keine möglichkeit die Sortierung vom Native auch auf dem SQL-Server zu bringen?

Unser Kunde möchte das so haben und wenn dem Kunden die ISO-Standards egal sind...
...gibt es vielleicht ne Einstellung auf dem SQL oder muss man die Sortierung programmieren? Hoffentlich habt ihr ein paar Tipps

gruß
Tobi

[stryk]

Obwohl der SQL-Server nach ISO-Standard sortiert, gibt es denn keine möglichkeit die Sortierung vom Native auch auf dem SQL-Server zu bringen?

Dafür gibt es bei "Code" Feldern die Option den "SQLDataType" zu ändern; z.B. auf "Variant" oder "Integer". Dann wird auch hier wieder quasi nummerisch sortiert hat aber andere potentielle nachteile:
"Variant": lässt alphabetische Zeichen zu, aber keine führenden 0 (Null); erforder ggf. implizite DT Konvertierungen (Performance!)
"Integer": streng nummerisch, keine führenden 0 (Null)

[Tim]

Dafür gibt es bei "Code" Feldern die Option den "SQLDataType" zu ändern; z.B. auf "Variant" oder "Integer". Dann wird auch hier wieder quasi nummerisch sortiert hat aber andere potentielle nachteile:
"Variant": lässt alphabetische Zeichen zu, aber keine führenden 0 (Null); erforder ggf. implizite DT Konvertierungen (Performance!)
"Integer": streng nummerisch, keine führenden 0 (Null)

Und Vorsicht. Ich bin daran mal fast verzweifelt. Hier ein Szenario:

1. Datatype auf "Varchar" stellen
2. Datensatz '100' erstellen
3. GET auf Datensatz '0100' machen und staunen, dass GET funktioniert

Muss man halt wissen, dass die führenden Nullen auch in der GET-Abfrage ignoriert werden.

[Kowa]

Die bislang mögliche Variante, den SQLDataType vereinzelt nach Bedarf auf "Integer" umzustellen, führt ab NAV 2013 R2 u.U. zu massiven Performanceproblemen in der Flowfieldberechnung, siehe hier.