Hallo,

habe hier folgendes Problem :

Ich muß ältere Datenbestände, die nur als Textdatei vorliegen in eine IB-DB reinkriegen. Hierzu habe ich mir eine EXTERNQAL TABLE angelegt, in der ist auch schön alles zu sehen.

Jetzt will ich diese in eine "richtige" DB per insert einfügen. Entsprechende Generatoren und Trigger sind auch vorhanden. Der Haken ist aber jetzt folgender : In der DB ist z.B. Nr. vom Typ integer, aber in der EXTERNAL TABLE char (5). Was nu ?

Außerdem finde ich nirgendwo die richtige Syntax von INSERT INTO ... FROM EXTERNAL blabla. Wie muß man das genau schreiben ?

Gruß
Hansa

Hi Hansa

hansa hat folgendes geschrieben:

In der DB ist z.B. Nr. vom Typ integer, aber in der EXTERNAL TABLE char (5). Was nu ?

Geht so:

hansa hat folgendes geschrieben:

Außerdem finde ich nirgendwo die richtige Syntax von INSERT INTO ... FROM EXTERNAL blabla. Wie muß man das genau schreiben ?

Das hör ich zum ersten Mal Das Schlüsselwort External kenn ich nur im Zusammenhang mit User Defined Functions.

Gruss Lothar

IB macht doch eine automatische Konvertierung, wenn man einen Textwert in ein Integerwert packen will, oder vertue ich mich da jetzt?

Hallo,

LCS :

Zitat:

Das Schlüsselwort External kenn ich nur im Zusammenhang mit User Defined Functions

Das war auch zuviel des guten. Mit Create Table weiß Interbase ja schon von dieser Table:



So sieht der Code vorerst aus und er funktioniert auch.

Jetzt ist nur noch die Frage, wie ich die Daten aus der externen Table D in die richtige IB-Table kunde reinkriege. Mein Problem liegt darin, daß ich nicht weiß, wie ich ihm sage, daß er die Daten aus der externen Datei lesen soll.

Dann taucht das nächste Problem schon auf : die kunde - Table hat noch ID's von anderen Dateien (Im Moment müßte ich die auch importieren). Wie kriege ich die ID (also den Primary-Key) einer anderen Stammtabelle in diese Datei? Es bleibt wohl nichts anderes übrig, als mit einem anderen Kriterium z.B. Nr. des Stammsatzes den entsprechenden Satz zu lesen und die Ursprungs-ID an die Datei, die ihn braucht weiterzureichen. Oje, versteht das jemand ?

Gruß
Hansa

Hi

hansa hat folgendes geschrieben:

Oje, versteht das jemand ?

Ne, net so recht am Montagmorgen

Gruss Lothar

Hi Lothar,



So sieht die IB-Tabelle kunde8 aus, die externe Tabelle D steht ja weiter oben. Schau dir mal in beiden Fällen das Feld Nr. an. In der alten Datei steht es halt als char drin und das soll in IB ein integer werden. Das geht so :



In der Ergebnismenge steht dann auch das gewünschte.

Lasse ich aber jetzt folgendes ablaufen :


Das CAST ist also die Typumwandlung ! Das hab ich nun geschnallt. Aber bei obigem INSERT kommt die Fehlermeldung:

"Count of read write columns not equal count of values"

Da steht auch wieder ein SELECT drin. Das erste Select klappt ja, aber wo steckt denn eigentlich diese Ergebnismenge überhaupt ? Gebe ich nur ein

INSERT INTO kunde8

kommt "unexpected end of command". Das krieg ich einfach nicht hin. Habe alles mögliche probiert.

Nochmals zu den IDs : Es geht darum, die ID, der einem Kunden zugeordneten Kundengruppe als IDKGH (das ist die entsprechende Fremd-ID der Kunden-Hauptgrupe für einen Kunden) richtig in die Kunden-Table reinzukriegen. Oder so : IDKGH (in Kunde-DS, kein Primary) ist gleich der ID der Kundengruppe (Primary), d.h. der Verweis im Kunde-DS auf die ihm zugeordnete Kundenhauptgruppe. Uff.

Gruß
Hansa

Hi
Die Anweisung

liefert dir ja nur 5 Felder. Deine Tabelle Kunde8 hat aber wesentlich mehr. Also beschwert sich IB. Du musst angeben welche Felder der Tabelle mit diesen Werten gefüllt werden sollen:

Damit stimmt die Anzahl der einzufügenden Werte mit der Anzahl der Spalten des Select überein.
Das nächste Problem kriegst du allerdings wenn du bei dieser Aktion nicht allen Feldern mit not Null einen Wert zuweist, oder generierst.

Bei deinen IDs versteh ich das Problem immer noch nicht so ganz. Wenn diese Gruppen IDs in den zu übernehmenden Daten auch schon vergeben waren, müssen sie in der neuen Tabelle identisch übernommen werden. Das muss aber vorher passieren, weil du ja in der Kundentabelle darauf Bezug nimmst.

Gruss Lothar

Hi,

die Klammern hinter Insert "into kunde8 (...", ja das müßte es sein, nein das kann es nur sein. Übernehme ich so ungetestet, muß gleich weg. War selber nah dran, aber ??? Irgendwo hängt man dann fest wegen sowas.

Zitat:

. Wenn diese Gruppen IDs in den zu übernehmenden Daten auch schon vergeben waren, müssen sie in der neuen Tabelle identisch übernommen werden. Das muss aber vorher passieren, weil du ja in der Kundentabelle darauf Bezug nimmst

Moment mal, gaaaanz langsam. In der DB sind Generatoren vorhanden, um die IDs zu vergeben. Übernehme ich die alten IDs 1:1 müßte ich diese abschalten. Bei der Übernahme aus der externen table handelt es sich ja nur um eine einmalige Aktion. Später müsen neue IDs vergeben werden. Also brauche ich die Generatoren doch.

Gruß
Hansa

Hi

hansa hat folgendes geschrieben:

In der DB sind Generatoren vorhanden, um die IDs zu vergeben.

Genau das ist das Problem. Du willst bei der Datenübernahme die IDs neu vergeben und müsstest dabei auch alle referentiellen Integritäten abchecken. In der alten Tabelle sind die aber schon abgecheckt (hoffentlich).

hansa hat folgendes geschrieben:

Übernehme ich die alten IDs 1:1 müßte ich diese abschalten.

Genauso isses

hansa hat folgendes geschrieben:

Bei der Übernahme aus der externen table handelt es sich ja nur um eine einmalige Aktion. Später müsen neue IDs vergeben werden. Also brauche ich die Generatoren doch.

Wenn alle Daten übernommen sind, bekommen die Generatoren als Startwert die höchste übernommene ID zugewiesen und werden wieder aktiviert.
Damit sind die alten Daten 1:1 übernommen und neue Werte werden von dem Moment an automatisch erzeugt.
Damit umgehst du automatisch auch den Ärger mit den Anwendern, wenn die ID 17 in der neuen Tabelle auf einmal die ID 9 ist. Natürlich nur sofern die IDs sichtbar sind.

Gruss Lothar

Hi Lothar,

Alt-ID's sind nicht sichtbar. Die Integrität stimmt (hoffe es jedenfalls auch ).

Zitat:

Wenn alle Daten übernommen sind, bekommen die Generatoren als Startwert die höchste übernommene ID zugewiesen und werden wieder aktiviert.

Mensch Meier. Bin ich blöd. Manchmal braucht man wirklich jemanden, der einem auf die Sprünge hilft.

Nur eines noch, wie schalte ich eigentlich die Generatoren temporär ab ??

Gruß
Hansa

jetzt aber, nix wie weg.....

Hi

Zitat:

Nur eines noch, wie schalte ich eigentlich die Generatoren temporär ab ??

Einfache Antwort: Geht nicht
Im Ernst: Die Generatoren selbst kannst du nicht abstellen. Die kannst du ja nicht mal so einfach löschen. Das Einzige was du abstellen kannst sind die zugehörigen Trigger.


Gruss Lothar

Hi Lothar,

ja das wars, habe jetzt ca. 1000 Kunden in der DB, aber mehr oder weniger nur mit Adresse (also die Felder aus der externen Table). Nun gut, dann knöpf ich mir die mal vor und schreibe alles rein was vorhanden ist, da taucht bestimmt noch so ein Typ-Problem auf. Ohje, da brauche ich gar nicht lange zu überlegen: Aufzählungstypen, Arrays und was es so gibt.

Gruß
Hansa

Was mich allerdings wundert, das Konvertieren aus der Textdatei ging ohne merklichen Zeitverlust, wenn man hier so liest, wie manche um Minuten kämpfen ? Sogar die deutschen Umlaute sind richtig.

Hi,

da gehts schon los, verfügbare Bücher richten sich anscheinend nur an Leute, die sowieso alle Daten neu eingeben müssen. Wo gibts denn sowas. Heutzutage verkäuft man nur ein Programm falls derjenige, der es gerne hätte, eben zumindest nicht ALLES selber eingeben muß. Jetzt bleibe ich schon am date hängen. Wie soll ich das denn in die Textdatei schreiben, so daß IB das versteht ? Die Aufzählungs- und Bool-Typen muß ich wohl als smallint darstellen oder nicht ?

Mir jetzt egal, wird alles vorerst ausgeklammert. Ich will heute noch eine Datei haben, in der (bis auf diese Problemfälle) alles drin ist.

Gruß
Hansa

Hi hansa,
da wollt ich doch glatt nach deinem vorletzten Posting schon applaudieren

Zitat:

Jetzt bleibe ich schon am date hängen. Wie soll ich das denn in die Textdatei schreiben, so daß IB das versteht ?

Wenn du das direkt mittels SQL einliest, sollte eigentlich das Format 'dd.mm.yyyy' in Ordnung gehen. Im Zweifelsfall kannst du aber auch mal 'mm/dd/yyyy' testen.

Zitat:

Die Aufzählungs- und Bool-Typen muß ich wohl als smallint darstellen oder nicht ?

Wird wohl das Beste sein. Bool-Typen gibts bei IB nicht.

Gruss Lothar

Hallo,

weiß jemand, wie die boolean Typen sonstwo meistens umgesetzt werden, Smallint würde sich zwar anbieten, aber was ist mit CHAR (1) ? Wo lauern da eventuelle Fallen, bzw. was wäre besser ?

Aber noch einmal zu der Typumwandlung :

Also ich habe jetzt mal eine kleinere Table als Textdatei hergestellt, sie in eine Externe IB-Table und schließlich in eine richtige befördert. Da sind IDs drin, die ich für größere brauche. Dann habe ich dasselbe mit meiner Kunden-Table gemacht. Die Felder, die ich so lassen will habe ich übernommen, die die mir nicht gefielen habe ich vorerst ausgeklammert. Die Textdatei habe ich dann genau so, wie mit der kleinen Table vorher, in eine externe IB-Table befördert. Die gewünschten Felder und vor allem die Daten waren da.

Dann gings weiter mit der richtigen IB-Table !!! Am Anfang waren natürlich kleine Tipfehler und sowas drin, aber nach und nach kam ich weiter.

@Admin: der letzte Beitrag wurde urplötzlich ohne Abfrage geschickt ????

das wichtige kommt nämlich erst.

@Admin schon wieder ! Gibt es irgendeinen Hotkey, den man aus Versehen drücken kann?

Meine Externe Table hat ca. 60 Felder, das Erzeugen der IB-Table hat auch noch einwandfrei geklappt. Aber beim Einfügen der Daten (mit Typumwandlungen) kommt dann folgende Fehlermeldung :

Zitat:

Conversion from string " " on line

und dann das ganze insert Statement, paßt nicht auf eine Seite, für die IBconsole ist es eine einzige Zeile, wo 2mal 60 Felder aufgeführt werden. Ich sehe weder wo der Fehler ist, noch weshalb. Hat einer einen Tip parat ? Oder muß ich alles wieder neu machen ? Ohne Zeilenzahl ist das ganze wie gesagt auch noch.

Gruß
Hansa

Hi
die Fehlerausgabe von IBConsole ist wirklich krass . Aber Conversion from String... bedeutet eigenlich ein Problem bei der Typumwandlung. Das können leere DB-Felder sein, Umlautprobleme oder sonstwas.
Ich hab bis jetzt die Erfahrung gemacht, dass es wesentlich schneller geht ein simples Programm zu schreiben, das die Daten einliest, konvertiert und dann in die neue Datenbank schreibt, als bei IBConsole und ISQL Nerven zu lassen.

Gruss Lothar

Hi,

Zitat:

Ich hab bis jetzt die Erfahrung gemacht, dass es wesentlich schneller geht ein simples Programm zu schreiben, das die Daten einliest, konvertiert und dann in die neue Datenbank schreibt, als bei IBConsole und ISQL Nerven zu lassen.

Wie meinst Du das ? Welches Programm soll die Daten einlesen und konvertieren ? Letztenendes muß das doch IB schaffen. Ob ich jetzt eine Textdatei habe oder eine Datendatei, die ich später in einen Text konvertiere. Wo ist da der Unterschied ?

Gruß
Hansa

hansa hat folgendes geschrieben:

Wo ist da der Unterschied ?

Der Unterschied ist einfach der, dass du dich nicht mit den Unzulänglichkeiten und Fehlern von IBConsole rumärgern musst.