Home › Forum › Nuclos Bedienung › Datenimport/export › Daten komplett importieren/exportieren
- Dieses Thema hat 10 Antworten und 6 Teilnehmer, und wurde zuletzt aktualisiert vor 11 Jahre, 5 Monaten von
Thomas Schiffmann.
-
AutorBeiträge
-
16 Dezember 2011 um 12:40 Uhr #4687
Yves Hoeppe
TeilnehmerHallo,
wie kann man dann ein Nuclet inklusive Daten exportieren und importieren?
Grüße,
hoeppi16 Dezember 2011 um 21:52 Uhr #4690Hans Dengel
TeilnehmerHallo Hoeppi,
also mir ist bisher nur ein Daetnbank Dump für so etwas bekannt.
Grüsse Hans
17 Dezember 2011 um 19:42 Uhr #4691Hans Dengel
TeilnehmerHallo hoeppi,
wenn ich es mir recht überlege gibt es auch noch die Möglichkeit, die Daten über das Druckersymbol als csv Daten zu exportieren, und dannn über einen Datenimport (Strukturdefinition und Objektimport) wieder zu importieren. Man muss dann aber selbst dafür sorgen, daß Referenzen richtig importiert werden ( Reihenfolge der Importe), Ausserdem verliert man evtl. Information aus den Editierungsfeldern.
Ich nutze diese Möglichkeit im wesentlichen bei der Entwicklung um einzelne (Service) Entitäten bzw. Wertelisten für Auswahlfelder wie Anreden, Titel, Masseinheiten oder ähnliches zu exportieren, damit ich bei einem Neueinstieg (Löschen der Datenbank) nicht wieder von vorne anfangen muss.
Für größere Datenbestände ist das wohl eher nicht praktikabel.Gruss Hans
19 Dezember 2011 um 11:19 Uhr #4692Yves Hoeppe
TeilnehmerHallo,
ja danke für die Antwort.
Ich bin nun folgendermaßen vorgegangen:
- 1. Ich habe jetzt das Nuclet der gesamten Instanz (Struktur) über Nuclos in das neue System eingespielt.
- 2. Danach habe ich einen reinen Daten-Dump (also ohne Struktur) aus der Bestands-Datenbank über alle mit t_eo_* beginnenden Tabellen gemacht (als INSERT – Statements).
- 3. Im Anschluss lässt man das entstandene SQL-Skript über die zu befüllende Datenbank laufen – und zwar so oft, bis keine Fehler mehr ausgegeben werden. So muss man die INSERT-Statements nicht extra nochmal umordnen. Sonst würde man ja wahnsinnig werden.
Grüße,
hoeppi19 Dezember 2011 um 12:52 Uhr #4693Matthias Haake
TeilnehmerHallo,
danke für die Ausführungen. Als Ergänzung zum geposteten Vorgehen über SQL-Skripte möchte ich noch anmerken: Wenn es sich um Entitäten mit Statusmodell handelt, dann fehlt in der Beschreibung noch der Ex- und Import der entsprechenden Datensätze aus der T_UD_GENERICOBJECT-Tabelle. Darüber „weiß“ Nuclos, welcher Entität ein Objekt angehört und kann z. B. in einer dynamischen Entität (Subform) per Doppelklick das richtige Formular öffnen.
Des Weiteren ist etwas Vorsicht mit den IDs (Primärschlüsseln) geboten. Bei einem Import per SQL-Skript in ein bestehendes Nuclos-System können u.U. während des Imports oder auch im späteren Verlauf doppelt vergebene IDs auftreten.
Sicherer (für ein Live-System) wäre da der Objekt-Import von Nuclos. Zum Testen mag die schnelle SQL-Variante aber sicher auch funktionieren.
Viele Grüße,
Matthias19 Dezember 2011 um 15:09 Uhr #4694Ramin Goettlich
TeilnehmerHallo,
es gibt bisher keine in Nuclos vorgesehene Möglichkeit, die gesamte Datenstruktur mit Daten zu exportieren. Was spricht denn gegen einen Datenbankdump? Der macht ja genau das und ist die sicherste Variante (auch im Hinblick auf laufende Transaktionen…)
Grüsse,
nuclosian19 Dezember 2011 um 16:03 Uhr #4696Yves Hoeppe
TeilnehmerDagegen spricht beispielsweise, dass, wenn man einen nativen bspw. PostreSQL-DB-Dump macht, man in Schwulitäten kommt mit der Dump-Reihenfolge, sich aufgrunddessen der Dump nicht einlesen lässt und – wenn man die Schemata, Usernamen etc. unterschiedlich benannt hat – nicht nur die Reihenfolge, sondern auch alle Statements an sich (sofern überhaupt möglich) anpassen muss. Das artet unter Umständen in richtig viel Arbeit aus, je nachdem, wie stark die Abhängigkeiten verschachtelt sind und so weiter…
19 Dezember 2011 um 18:10 Uhr #4697Hans Dengel
TeilnehmerHallo hoeppi,
aber doch nur wenn die Tabellen einzeln gedumped werden ( so wie ich das aus der Vorgehensweise mit den SQL Skripts entnehme). Wenn du einen Dump der ganzen Datenbank machst sollte es keine Problem geben (Also ich hatte bisher noch keine). Warum willts Du ausserdem die Schemata und user umbenennen? Ich habe es noch nie ausprobiert, aber klappt dann der Nuclet import überhaubt noch wenn das Nuclet aus einer db X mit Schema SX exportiert wird und dann in eine db X mit Schema SY importiert wird ? Ansonsten gebe ich dir recht, aber dann wird das ganze ähnlich schwierig wie über einen Objektimport weil ja auch dort über die Reihenfolge der Imports sichersgestellt wird daß alle referenzierten Daten zur rechten Zeit am rechten Ort sind.
Gruss
Hans
19 Dezember 2011 um 21:02 Uhr #4700Markus Glitzner
TeilnehmerAls Ergänzung für den SQL Server:
– Nuclos beenden
– DB aushängen
– DB auf neuen Server kopieren
– DB am neuen Server einhängen
– verwaiste DB Benutzer am neuen Server reaktivieren (falls nötig)
– Nuclos am neuen Server startenMit Backup und Restore funktioniert es natürlich auch, dann muss die Nuclos Instanz am alten Server nicht extra beendet werden, am neuen Server ist auf jeden Fall ein Neustart der Nuclos Instanz nötig.
Gruß Hugo
20 Dezember 2011 um 07:53 Uhr #4702Yves Hoeppe
TeilnehmerHallo,
ja, das Übertragen des Nuclet funktioniert schon. Es kann unter Umständen schon mal notwendig sein, dass man User umbenennt und falls man eine bereits bestehende DB nutzen muss, hat man da namenstechnisch eben auch evtl. ein Problem. Ich hatte da Schwierigkeiten mit Dump and Restore. Das Skript lief nie komplett durch, immer gab es irgendwelche Schlüsselverletzungen oder sonstwas für Fehler. Ich bin bald wahnsinnig geworden. Aber womöglich lag es daran, dass irgendwo ein Referenzfehler war oder das ganze nicht als reines SQL (da hatte es ja bei der beschriebenen Methode durch mehrmaliges Durchlaufen des Skripts irgendwann vollständig funktioniert) gedumpt wird, was die Probleme jedoch nicht entschuldigt.
Eigentlich traurig, dass bei so einem Dump die Reihenfolge nicht bereits von der Datenbank selbst berücksichtigt wird, zumindest, solange keine zirkulären Beziehungen existieren.
Grüße,
hoeppi20 Dezember 2011 um 11:54 Uhr #4703Thomas Schiffmann
TeilnehmerHallo hoeppi,
mit dem Default-Dumpformat habe ich die gleichen Erfahrungen gemacht (wobei ich immer vermutet habe, dass die Reihenfolge zwar stimmt, aber einzelne Datensätze (mit BLOBs oder CLOBs) nicht erstellt werden können und es bei referenzierenden Datensätzen daher zu Fremdschlüsselverletzungen kommt).
Abhilfe hat bei mir die Wahl eines anderen Formats gebracht: über den Parameter -Fc wählt man das Format „compress“, das dann auch nicht über einen normalen Sql-Client sondern über das Programm pg_restore wiederhergestellt werden muss.Bei Restore-Problemen mit Benutzernamen, Rechten, Tablespaces o.ä. können Sie auch mal einen Restore mit folgenden Optionen versuchen:
–no-owner
–no-privileges
–no-tablespaces
(siehe http://www.postgresql.org/docs/9.0/static/app-pgrestore.html)Viele Grüße
tsc -
AutorBeiträge