[gelöst] Rename G/L Account - native/SQL

[sweikelt]

Guten Morgen zusammen,

ich habe eine kurze Frage zwecks Umbenennung von Sackkonten für eine SQL-umstellung
Die Sachkonten sollen mit führenden Nullen aufgefüllt werden.... z.B.:

[alt] Sachkonto: 10
[neu] Sachkonto: 00010

=> ich glaube jeder weiß warum ^^

Nun hab ich allerdings ein kleines Performance-Problem....NAV (auf native) braucht extrem Lange(ich denke es war eine Stunde) für die Umbenennung eines Kontos

Jetzt meine Frage: Wäre es besser, die Konten in SQL umzubenennen?

Zuletzt geändert von sweikelt am 17. November 2011 11:38, insgesamt 1-mal geändert.

Hat schon einen guten Grund, wieso es so lange dauert. Jede Table Relation referenz muss umbenannt werden und dann noch der Programmcode auf dem OnRename Trigger.
Wenn Du das einfach im SQL Server machst, ist das System kaputt.

Ja ich weiß warum es solange dauert ;)

ich dachte mir nur, dass der SQL-Server das schneller kann .... also ich meinte mit "in SQL umbennen", dass ich die DB von native erst nach SQL migriere und dann dort meine rename-fkt (aus nav heraus) ausführe

Hatte vor 2 Jahren ein ähnliches Problem (Link).

Das Umbennen hätte 6 Tage am Stück gedauert...

Es gibt auch ein Rename Tool was dich zeitgesteuert unterstützt.
Du müsstest im Kontenplan übrigens dann auch noch die Filter für die Summen anpassen.

P.S.: Ich glaube nicht das es mit der SQL Datenbank wesentlich schneller geht.

mfg,
winfy

ah genau, an die blöden summenfilter hab ich ja garnicht gedacht :/

deinen post hab ich mir auch vorher schon angeschaut, mich aber nicht wesentlich weiter gebracht ... jedenfalls nicht in dem punkt, ob es mit sql schneller gehen könnte

aber dennoch konnte ich deinem post entnehmen, dass es echt tage dauern kann :(

das zeitgesteuerte rename tool hab ich gestern ebenfalls aus deinem beitrag genommen ;) ... aber noch nicht benutzt :P

nunja, ich lass den beitrag mal noch bis heut abend offen, falls noch eine antwort bezüglich performance-steigerung bei sql-nutzung kommt

Wenn das Umbenennen auf Native so lange dauert, weil da ewig mit dem falschen Schlüssel herum gesucht wird, kannst du mit SQL erheblich Zeit sparen. Hier war das so beim Umbenennen eines Artikels: Native ~ 35 Min, SQL ~ 30 Sekunden.

hehe - das wollte ich hören

danke an alle für die schnellen antworten

Wenn das Umbenennen auf Native so lange dauert, weil da ewig mit dem falschen Schlüssel herum gesucht wird, kannst du mit SQL erheblich Zeit sparen. Hier war das so beim Umbenennen eines Artikels: Native ~ 35 Min, SQL ~ 30 Sekunden.

Wenn es natürlich für die Sachkonten in den zich Tabellen kein Schlüssel gibt, dann rödelt er ohnehin die ganze Tabelle durch auch wenn es nicht einmal einen Eintrag mit dem Konto gibt. Mich würde es daher wundern wenn es mit dem SQL Server schneller ginge.

Aber Versuch macht kluch!

mfg,
winfy

Der Vorteil beim SQL-Server wäre, dass man direkt beim Umbennen den Profiler mitlaufen lassen und für teure Abfragen direkt auf dem SQL-Server neue Indizes erstellen kann. Das ist bei einer Native-Datenbank ja so nicht möglich (ohne den Umbennungsvorgang zu unterbrechen).

Ja ich weiß warum es solange dauert ;)

ich dachte mir nur, dass der SQL-Server das schneller kann .... also ich meinte mit "in SQL umbennen", dass ich die DB von native erst nach SQL migriere und dann dort meine rename-fkt (aus nav heraus) ausführe

Ah okay, habe ich das falsch gelesen.
Ich schlage auch das zeitgesteuerte Rename Tool (auch wenn ich es nicht kenne). Wenn Du mit dem Profiler erst die Löcher suchst und dann die Schlüssel anlegst, dann musst Du dafür die Objekte anpassen.

Wenn Du mit dem Profiler erst die Löcher suchst und dann die Schlüssel anlegst, dann musst Du dafür die Objekte anpassen.

??? Welches Objekt muss man anpassen, wenn man einer Tabelle einen zusätzlichen Index verpasst? Das geht "on-the-fly" und ohne ein NAV-Objekt anzupassen.

EDIT: zur Erklärung: der Index muss ja nur auf dem SQL-Server existieren, nicht in NAV. Der SQL-Server entscheidet schließlich alleine, welcher Index für eine Anfrage von NAV verwendet wird (unabhängig von einem SETCURRENTKEY), es sei denn Index Hinting ist aktiviert.

Ich nehme mal an, dass sich Jan dabei auf eine Native bezogen hat.

Ich nehme mal an, dass sich Jan dabei auf eine Native bezogen hat.

Und welchen "Profiler" gibt es für die Native-DB? Wenn er Native gemeint hätte, hätte er wohl eher "Client Monitor" geschrieben.

Ich meinte SQL, und Schlüssel auf dem SQL Server anlegen, ohne das das NAV es weiß, ist auch nicht ohne Vorsicht zu genießen.
Der TE ist ein Schüler/Student, kein Senior NAV/SQL-Nerd, der nur gerade einen Tick in die richtige Richtung brauchte.

Guten Morgen,
wenn das Umbenennen abgeschlossen ist, dann sollte man nicht nur an die Summenkonten im Kontenplan denken sondern auch z.B. an Kontenschemata.

Gruß
Jörg

du meinst sicherlich die Kontenschemazeile und dort dann die Zusammenzählung - das die auch noch geändert werden muss, oder?
Das ist kein Problem ... dauert ja dann auch nicht so extrem lange