Migration nach SQL (CC)

Wo ist denn genau daran unverständlich? Könntest du etwas genauer beschreiben?

Die Killerobjekte dienen zum Löschen von Objekten, die man sonst wegen Lizenzeinschränkungen nicht löschen könnte. Das geht auch nicht über die Objektabelle, wenn die Lizenz keinen Zugriff erlaubt. Man kann auch keine Killerobjekte direkt in NAV für Lizenzbereiche erstellen, die nicht zugänglich sind, also bleibt nur der Weg über die SQL-Server. Das macht man am besten in einer separaten Datenbank, die nur zu diesem Zweck dient, und legt in dieser die benötigten 0-Byte-Objekte an.

Mein SQL-Skript ist absolut gebrauchsfertig, einfach den benötigten Objektbereich eintragen, die Killerobjekt-DB im SQL Management Studio öffen und das dort ausführen, in ein paar Sekunden sind die Objekte da.
Die exportiert man dann ganz normal mit dem NAV-Client und importiert diese in die Zieldatenbank wo diese Objekte gelöscht werden sollen. Bei vorhandenen Tabellen wird dann im Import Worksheet automatisch im Feld Action "Delete" fest eingestellt. Das Löschen funktioniert mittlerweile (ab NAV 2013 R2) auch bei Tabellen, die noch Daten enthalten. Ich habe das eben noch mal für NAV 2015 geprüft. Die Schemaänderung muss dabei natürlich mit ForceSync durchgedrückt werden.

Hallo Kai,

das Skript von Carsten hatte ich nicht verstanden. Und dann war mir diese Delete-Funktion beim Einlesen der Objekte bislang überhaupt nicht geläufig, wahrscheinlich weil ich diese noch nie gebraucht hatte. Ansonsten käme ich wahrscheinlich jetzt mit deinem Skript klar. Trotzdem sind mir noch zwei Dinge unklar.

Die erste: Warum funktioniert es offensichtlich nicht, die zu löschenden Objekte zu exportieren und dann sofort wieder zu importieren und dabei die Delete-Funktion anzuwenden?

Die zweite: Warum soll die von mir bislang gewählte Methode nicht funktionieren, die Tabelle Objekt zu lesen, und aus den zu löschenden Datensätzen ein SQL-Skript zu generieren, das die betroffenen Datensätze löscht (in der Objekt-Tabelle) und, falls es Tabellenobjekte sind, auch die entsprechenden dazugehörenden Tabellen noch entfernt? Wir sprechen hier von NAV2009. Dass 2015 auch volle Tabellen löscht ist gut, hilft mir leider aber nicht weiter, da in 2015 mindestens eine Tabelle neu hinzukommt, die einen gleichen Namen wie eine vorhandene aber eine andere Nummer hat.

Gruß
Rainer

Hallo,

Kai's Weg ist NAV- versionsunabhängig, funktioniert von Version 2 - 2015, und sorgt dafür, dass der NAV- Development-Client alles zu den Objekten gehörende aufräumen kann. (die Objekt- Tabelle ist nicht die einzige Tabelle, in der Objektdaten enthalten sind).

Gruß, Fiddi

Hi,

aber ich sehe das doch richtig, dass ich vorher noch alle zu entfernenden Tabellen (bei NAV2009) leeren muss, oder? Kann es beim DELETEALL auch Lizenzprobleme geben?

Kann ich die Killerobjekte auch in eine native Datenbank einlesen (ich weiß, dass ich zum Erzeugen SQL brauche)?

Was passiert wenn ich ein Killerobjekt für ein nicht existierendes Objekt habe? Wird das einfach übergangen oder wird mit Fehler abgebrochen?

Warum funktioniert es offensichtlich nicht, die zu löschenden Objekte zu exportieren und dann sofort wieder zu importieren und dabei die Delete-Funktion anzuwenden?

"Delete" als Import Action kann man nicht manuell einstellen (da kommt dann eine Fehlermeldung "Delete is only allowed for emtpy objects"), das stellt sich nur genau durch diese 0-Byte Objekte auschließlich automatisch ein.

Die zweite: Warum soll die von mir bislang gewählte Methode nicht funktionieren, die Tabelle Objekt zu lesen, und aus den zu löschenden Datensätzen ein SQL-Skript zu generieren, das die betroffenen Datensätze löscht (in der Objekt-Tabelle) und, falls es Tabellenobjekte sind, auch die entsprechenden dazugehörenden Tabellen noch entfernt?

Solche Operationen sind sehr riskant, was in einer Version vielleicht noch funktioniert hat, kann in der nächsten schon die Datenbank ruinieren.
Den Weg würde ich nur nehmen, wenn die SQL-Konvertierung der unzugänglichen Tabellen Probleme bereitet. Ansonsten einfach hinterher aus der NAV 2015 löschen.
Der Weg mit den Killerobjekten ist ansonsten wesentlich sicherer. Das ist auch das dokumentierte Verfahren.
Das Tabellennamen (oder auch die anderer Objekte) sich wiederholen, ist zwar lästig, aber leider nichts ungewöhnliches. Wenn mehrere Add-ons in einer DB sind ist, kommt das regelmäßig vor.

Hi,

aber ich sehe das doch richtig, dass ich vorher noch alle zu entfernenden Tabellen (bei NAV2009) leeren muss, oder? Kann es beim DELETEALL auch Lizenzprobleme geben?
Kann ich die Killerobjekte auch in eine native Datenbank einlesen (ich weiß, dass ich zum Erzeugen SQL brauche)?
Was passiert wenn ich ein Killerobjekt für ein nicht existierendes Objekt habe? Wird das einfach übergangen oder wird mit Fehler abgebrochen?

1. Ja und Ja.
2. Ja (das gab er schon, als NAV noch gar keine SQL-Server-Option hatte)
3. Kein Fehler, wird übergangen.

Jetzt bin ich fast am Ende: Wie bekomme ich am besten die noch vorhandenen Datensätze aus den zu löschenden Tabellen, wenn ich keine Lizenz habe, vor allem bei einer nativen Datenbank (sonst hilft ja zur Not das SQL Mgmt. Studio)?

Gruß
Rainer

Bei einer nativen geht das nicht, da ist die Lizenz ja bei allen Client-Server-Aktionen aktiv.

Hast du denn eine Idee für ein Skript, das die Tabellen vorher leeren kann? Es sind mehrere 100 Tabellen, die teilweise in 4 Mandanten, teilweise aber auch mandantenübergreifend sind.

Was mir selbst eingefallen ist, ist die Tabelleninformationen in Excel zu kopieren und daraus ein SQL-Script zu generieren.

Gruß
Rainer

Was mir selbst eingefallen ist, ist die Tabelleninformationen in Excel zu kopieren und daraus ein SQL-Script zu generieren.

Da du weiter oben geschreiben hast, dass die Lizenz zur Nutzung der Tabellen vorhanden ist, würde ich das aus Sicherheitsgründen auch nur in NAV erledigen. Für alle fraglichen Tabellen durch alle Mandanten laufen, ein DELETEALL(TRUE) ergibt dort ja keinen Fehler, wenn nichts vorhanden ist.

Ich habe aber keine Lizenz, das ist doch das Problem. Teilweise hat sie der Kunde auch nicht mehr. Das ist doch auch der Grund, warum ich über die Killerobjekte gehen muss

Da bleibt dir wohl kein anderer Weg als über den SQL-Server. Denk aber auch an die VSifts beim löschen.

Gruß, Fiddi

Ok, ich werde das mal probieren. Danke auch für den Tipp mit den VSifts.

Ich habe aber keine Lizenz, das ist doch das Problem. Teilweise hat sie der Kunde auch nicht mehr.

Vor 10 Tagen war das aber noch anders.

In der Datenbank stecken hunderte (!) von Objekten, die aus Modulen stammen, die der Kunde nicht mehr nutzt. Die Kundenlizenz sieht zwar die Nutzung dieser Objekte vor, nicht aber deren Löschung.

@Kowa

das eine Kundenlizenz die Nutzung von Tabellen erlaubt, heißt noch lange nicht, das man auch Daten daraus löschen darf, ohne Code zu haben, der die nötigen Permissions hat. (Siehe Postentabellen).

Gruß, Fiddi

das eine Kundenlizenz die Nutzung von Tabellen erlaubt, heißt noch lange nicht, das man auch Daten daraus löschen darf, ohne Code zu haben, der die nötigen Permissions hat. (Siehe Postentabellen).

Das betrifft aber eher Standardtabellen, und das sind gesetzliche Einschränkungen, weil Löschungen hier das sind, was früher die Radierungen in den Geschäftsbüchern waren.
Sollte ein Add-on solche Tabellen beinhalten, würde ich solchen Fällen erst mal probieren, vom Hersteller des Add-ons einen Löschreport für die Inhalte der fraglichen Tabellen anzuforden, der eben diese Permissions zum indirekten Löschen mitbringt. Das ist dann auch für den Hersteller sicher, weil man diesen mit der eigenen Lizenz nicht wird verändern können.

[rainergaiss]

Ich habe diesen Post wieder gelöscht.

Zuletzt geändert von rainergaiss am 11. September 2015 08:53, insgesamt 1-mal geändert.

Jetzt brauche ich noch einmal eure Hilfe.

Ich habe das Script mit Excel erstellt und eine Datenbank mit den Killerobjekten gebaut. Vorher habe ich die entsprechendnen Tabelleninhalte, ebenfalls mit einem in Excel gebastelten Script gelöscht. Dann habe ich beim Export der Killerobjekte aus der Killer-DB die Meldung bekommen, dass die Table xxx leer ist. Mir war natürlich an der Stelle klar, dass ich auch die TableData anlegen musste. Dann habe ich exportieren können und in der Ziel-DB die Objekte rausgehauen. Nachdem ich es alles verstanden hatte lief das perfekt.

Nun kommt aber mein Problem. Ich habe noch ein zweites Projekt, wo ich das Ganze genau gleich gemacht habe. Und trotzdem bekomme ich beim Exportieren der Killerobjekte für Tabellen die Meldung "Tabelle 'xxx' ist leer". Hat jemand eine Idee, was ich noch falsch gemacht haben könnte? Wir sind wieder bei einer 2009R2.

HAllo,

Mandantenübergreifende Tabelle!? TableData mit bzw. ohne Company- Namen.

Gruß, Fiddi

Die Killerobjekte wurden in einer leeren 2009R2-Datenbank angelegt, mit SQL-Statements und nach dem Muster von Kai / Carsten und exact genauso wie ich es in einer anderen leeren Datenbank bei einem anderen Projekt auch gemacht habe. Kann es sich um ein Berechtigungsproblem handeln, dass die TableData nicht gefunden werden?

Hallo,

Bei einer Mandanten übergreifenden TableData ist der Company- Name leer, bei einer Mandanten gebundenen nicht. Das ist bei allen anderen Objekten immer leer.

Ich bezweifele allerdings, dass die das hilft, wenn da Daten drin sind.

Gruß, Fiddi

Hallo Fiddi,

ich weiß nicht, ob wir gerade aneinander vorbei reden. Ich habe eine leere SQL-Datenbank, angelegt mit einem 2009R2-Client. Da ist noch kein Mandant drin. Dann habe ich mittels eines SQL-Skripts in dieser leeren Datenbank die Killerobjekte angelegt. Die sehe ich auch mit dem Object Designer. Wenn ich diese Objekte exportieren möchte kommt die Meldung, dass die Tabelle xxx leer ist. Ich habe aber für jedes Tabellenobjekt die Tabelle und die TableData angelegt. Würden letztere fehlen, käme die Fehlermeldung zu Recht. Alle anderen Objekte außer Tabellen lassen sich exportieren und auch in die, nennen wir sie Zieldatenbank, zwecks Delete importieren.

Es schlägt also schon der Export der Tabellenobjekte aus der Killer-DB fehl. Ich habe auch schon die Object-Tabelle gecheckt, auch da ist alles richtig.

Sorry,

evtl. hilft es auch einen Mandanten in der Killerdatenbank anzulegen, und erst dann die Objekte zu exportieren.

Gruß, Fiddi

Wenn ich diese Objekte exportieren möchte kommt die Meldung, dass die Tabelle xxx leer ist. Ich habe aber für jedes Tabellenobjekt die Tabelle und die TableData angelegt.

Ich habe überhaupt nichts zusätzlich anlegen müssen. Eine leere Datenbank ohne Objekte, SQL-Skript laufen lassen, generierte Objekte im Object Designer markieren und exportieren. Fertig ist das Tabellen-Killerpaket.

evtl. hilft es auch einen Mandanten in der Killerdatenbank anzulegen, und erst dann die Objekte zu exportieren.

Leider nein!