Löschen von Table Objekten ohne Lizenz

Hallo,

ich habe in einer DB 2 Table Objekte ohne Inhalt (Table Info) die nicht in unserer Lizenz enthalten sind (Altlast 2.00). Diese Objekte möchte ich gerne aus unserer 2009 R2 DB löschen.
Versuche bisher:
DB Sicherung und Wiederherstellung ohne Applikationsobjekte ohne Erfolg. Die Tabellen wurden trotzdem wieder angelegt. Meine Hoffnung lag darin das die Tabellen leer sind.

Kennt jemand einen Weg wie ich die beiden Tables los bekomme? Das Systemhaus von dem die Objekte kamen existiert soweit ich weiss nicht mehr.

Viele Grüße

Brainstocker

Welche Nummern sind das denn?

Auf SQL wirst du das relativ zügig los, aber sollte nur vom Fachmann getan werden. Deswegen verrate ich dir es hier auch nicht.

Hallo,

Tables
5022900
5022903

Gruß

Brainstocker

Hallo Brainstocker,

da die beiden Tabellen im geschützten Partnerbereich liegen, bleibt dir (meines Wissens nach) nur noch der Versuch, ob euer Microsoft Partner eventuell mit seiner Lizenz die beiden Tabellen löschen kann.

Jedoch sollte vor dem Löschen genau geprüft werden, ob die beiden Tabellen nicht doch noch irgendwo von einer Recordvariablen oder dergleichen referenziert werden.
Dies kann euer Microsoft Partner z. B. mit dem "Navision Developers Toolkit" oder dem "IDYN Object Manager" sehr zuverlässig herausfinden.

... Dies kann euer Microsoft Partner z. B. mit dem "Navision Developers Toolkit" oder dem "IDYN Object Manager" sehr zuverlässig herausfinden.

Das NDT hat eigene Granules, genauso wie der Object Manager. Sprich: Sie kosten Geld.
Wahrscheinlich muss die Analyse vom Partner ausgeführt werden. Wenn der Partner dazu nicht in der Lage ist, könnte er eine andere Lösung bereitstellen. Diese basiert auf einem anderen Ansatz, der durchführbar ist, aber nur von NAV+SQL-Spezialisten.

Hallo,

die Objekte zu löschen geht theoretisch ganz einfach:

• aktuellen Objektstand als .FOB exportieren.
• Neue DB erstellen
• exportierte Objekte bis auf die nicht gewünschten in die neue DB Importieren
• In alter DB die nicht gewünschten Tabellen leeren.
• evtl. in der Tabelle Object die Tabledata Einträge für die nicht gewünschten Tabellen löschen.
• Datensicherung erstellen in Alt-DB
• Datensicherung in Neu-DB importieren (natürlich ohne Objekte).
• Mandantenübergreifende Daten aus Alt-DB exportieren, in Neu importieren (evtl. geht das per Cut & Paste)
• Neue DB in Betrieb nehmen

Gruß, Fiddi

Hallo,

die Objekte zu löschen geht theoretisch ganz einfach:

• aktuellen Objektstand als .FOB exportieren.
• Neue DB erstellen
• exportierte Objekte bis auf die nicht gewünschten in die neue DB Importieren
• In alter DB die nicht gewünschten Tabellen leeren.
• evtl. in der Tabelle Object die Tabledata Einträge für die nicht gewünschten Tabellen löschen.
• Datensicherung erstellen in Alt-DB
• Datensicherung in Neu-DB importieren (natürlich ohne Objekte).
• Mandantenübergreifende Daten aus Alt-DB exportieren, in Neu importieren (evtl. geht das per Cut & Paste)
• Neue DB in Betrieb nehmen

Gruß, Fiddi

Wenn man schon in der tabelle object rumspielt, kann man auch gleich TableData, Table löschen und die sql tabelle, die zu den objekten gehört, droppen. Wohl gemerkt auf dem SQL Server, nicht per C/AL.

Wenn man schon in der tabelle object rumspielt, kann man auch gleich TableData, Table löschen und die sql tabelle, die zu den objekten gehört, droppen. Wohl gemerkt auf dem SQL Server, nicht per C/AL.

Table kann er nicht löschen, dafür fehlt Ihm die Lizenz

Die SQL-Tabelle muss er dann auch nicht mehr droppen, das sollte NAV für ihn erledigen

Gruß, Fiddi

Also technisch betrachtet kann man auch via SQL die Tabellen "failsafe" löschen. Aber logisch betrachtet bleibt natürlich das Risiko - wie es Timo schon gesagt hat - dass irgendwo im Code auf die Tabelle referenziert wird. Dieses Problem ist aber stets das selbe, egal wie man die Tabellen löscht, also z.B. auch via NAV.

Technisch könnte das so aussehen:

1. Alle Objekte in ein FOB exportieren - Backup!
2. Full SQL Backup der Datenbank (denn wer im folgenden Mist baut, der schrottet sich seine DB!)

3. Im SQL Management Studio:

Code:

USE [{DatabaseName}]  -- DB Namen ändern
GO

-- NAV Objekte anzeigen:
SELECT * FROM [dbo].[Object] WHERE [ID] IN (5022900, 5022903) AND [Type] IN (0, 1) -- TableData, Table
GO

-- NAV Objekte löschen:
DELETE FROM [dbo].[Object] WHERE [ID] IN (5022900, 5022903) AND [Type] IN (0, 1) -- TableData, Table
GO

-- SQL Tabelle(n) löschen:
DROP TABLE [dbo].[{CompanyName}${Table5022900Name}]  -- echten SQL Tabellen-Namen angeben!
GO
DROP TABLE [dbo].[{CompanyName}${Table5022903Name}]  -- echten SQL Tabellen-Namen angeben!
GO

Hier werden die Objekt-Informationen "TableData" und "Table" aus der "Object"-Tabelle gelöscht - für NAV sind damit die Tabellen nicht mehr existent.
ACHTUNG 1: wird NAV 2009 für RTC (Dynamics NAV Server enabled) verwendet, dann müssen auch die "Object Matadata" auf ähnliche weise gelöscht werden!
Jetzt müssen die echten SQL Tabellen noch aus der DB gelöscht werden. ACHTUNG 2: die Tabellen existieren u.U. je Mandant!

Sollte klappen ...

WARNUNG:
SQL Kommandos fragen nicht nach, "ob man auch wirklich löschen möchte". Es gibt auch kein "Undo" Funktion. Fehler werden NICHT verziehen, weg ist weg. Wer also versehentlich falsche IDs/Tabellen angibt, kann sich zu einer korrupten DB gratulieren, denn die enthaltenen Daten sind dann ggf. auch weg ... und Wehe dem, der vorher kein Backup gemacht hat!
Ich empfehle daher DRINGEND sowas zuerst auf einer TEST/DEV Datenbank ausgiebig zu testen!!!

OHNE GEWÄHR, KEINE GARANTIE, KEIN SUPPORT. NUTZUNG AUF EIGENE GEFAHR.

Viel Glück!

Auch wenn dieser Thread hier schon uralt ist, möchte ich eine kleine Anmerkung sowie einen Dank an stryk loswerden:

die beschriebene Systematik via SQL Studio hat für mich bei einer Tabelle funktioniert, die 1,5 Mrd. Datensätze enthielt. Die Tabelle war in unserer Lizenz enthalten, allerdings haben Löschversuche via DELETEALL oder Schleifen die 540GB Log-Partion komplett vollgeschrieben, so dass die Änderungen wieder zurückgerollt wurden. Mit der Variante des SQL Studios ist die Tabelle und die Daten nun weg. Daher: danke stryk!

...allerdings haben Löschversuche via DELETEALL oder Schleifen die 540GB Log-Partion komplett vollgeschrieben...

Mit dem SQL-Befehl TRUNCATE TABLE wäre es um einiges schneller gegangen