View Full Version : Batch Import einer tlw. UCS2 Tabelle in Access
Hallo zsammen,
ich habe eine Tabelle, welche tlw. Graphic-Felder (CCSID 13488) hat und tlw. Standard Alpha Felder mit CCSID 273. Die KeyFelder und die Protokollfelder sind mit der CCSID 273 codiert.
Nun muss ich diese per Batch in eine MS-ACCESS DB importieren --> Nein es kann keine andere DB sein.
Bisher war die Tabelle volsltändig mit der CCSID 273 codiert und der Import lief per TXT-Datei die über FTP übertragen worden ist.
Wie kann ich den import am elegantesten Erledigen.
1. Per ODBC einen Import definieren. Allerdings erstellt ACCESS dann immre eine neue Tabelle und überschreibt die bisherige Tabelle nicht. Desweitern kann ich den Namen der Tabelle nicht ändern/angeben.
Zusätzlich käme noch die Anmeldeproblematik dazu.
2. Per FTP und Textdatei? Fällt doch weg wegen den GRAPHIC Feldern!
Bin für Tipps und Tricks wie immer dankbar.
Als Textdatei (CSV) kann man auch eine UTF8-Ausgabe (CCSID 1208) erstellen und diese dann in Access importieren.
Wie hast du denn den aktuellen Import überhaupt durchgeführt?
Ich denke, du verwendest dann eben ein VBA-Macro innerhalb Access.
In diesem Fall würde ich die Tabelle per ODBC verknüpfen und als Makro sowohl eine Lösch- als auch eine Anfügeabfrage erstellen und diese dann nacheinander durchführen.
Automatisieren lässt sich das auch, wenn man eben beim Öffnen das Makro dann ausführt.
Hallo Fuerchau,
hast Recht da ist noch ein keines VB-Progrämmchen im Hintergrund.
Habe jetzt extra die CCSID 13488 UCS2 (angeblich bessere kompatibilität mit MS und JAVA?!?!) genommen um meine kyrislischen Schriftzeichen - älterer Post - speichern zu können.
Wenn eine Konvertierung auf UTF8 läuft, dann gehen diese doch verloren? UTF8 kann das zwar auch kyrillische Zeichen, aber diese werden dort as 3 oder 4-Byte Zeichen gespeichert.
Beim ODBC Import bleibt doch eigentlich alles erhalten?
Ja und Nein.
Der ODBC-Treiber von CA kann beim Umweg über ADODB leider kein UCS2!
Dies liegt leider daran, dass der MSDASQL-OLEDB-Treiber ein ODBC-2x-Treiber ist und CA dann davon ausgeht, dass der kein UCS2 (adWChar, adVarWChar) kann.
Was aber funktioniert, ist der OLEDB-Treiber IBMDA400.
Der kann dann auch UCS2, die Daten kommen dann also als wChar an.
MS-Access (also MS-Office) direkt verwendet kein ADODB!
Die verwenden die "klassische" DAO-Welt, die aber wiederum ODBC-3.5-Kompatibel ist, und somit auch wChar unterstützt.
Du kannst also entweder dein VB'chen auf DAO umstellen oder den OLEDB-Treiber IBMDA400 verwenden.
Alternative:
Wie importierst du denn nun zur Zeit?
Wenn du per VB eine Datei direkt öffnest, kannst du natürlich kein UTF-8 verarbeiten.
Allerdings gibt es bei ADODB noch das Objekt Stream.
Mit diesem kannst du Daten als UTF8 lesen und erhältst dann einen String beim Lesen der automatisch in UCS2 ist, da VB-Strings dies ja grundsätzlich sind.
Also zur Zeit läuft ein kleines Macro im hintergrund welches die Tabelle cleart und die Textdatei im "RAW-Import" (gespeicherte Importanweisung) einliest.
Ich wollte daher entweder diesen Vorgang gleich lassen und ggf. den FTP nicht aus der DB Herraus
get FILE.PF TEXT.TXT
sondern die Textdatei vorher wie folgt
===> CPYTOIMPF FROMFILE(LIB/FILE) TOSTMF('/HOME/VRZ/TEXT_UTF.txt') M
BROPT(*REPLACE) STMFCCSID(1208) RCDDLM(*CRLF) DTAFMT(*DLM) STRDLM(*NONE) FLDDLM(';') DATFMT(*EUR) TIMFMT(*JIS) ADDCOLNAM(*SYS)
erstellen als Import-Grundlage nehmen.
Alternativ über eine ODBC-Verbindung (Akt. Client Access Treiber) den Import direkt aus der DB herraus vornehmen; allerdings auch über ein kleines VB-Progrämmchen.
Also RAW_Import sagt mir jetzt nichts.
Wer oder was führt das Makro denn aus?
Wird irgendeine Access-Funktion angestoßen?
Ich denke, dein Text-Import geht nicht von UTF-8 aus.
RAW_Import bedeutet (für mich) nimm die Textdatei und schiebe diese in die Tabelle (Importfunktion von ACCESS mit Textdatei).
Ähnlich wie eine Textdatei per FTP in eine PF zu schieben :)
Werde mich mal mit dem ODBC-Import auseinander setzen.
Danke aber erstmal.