Office: (Office 2010) Access kürzt Memo Datenfelder bei TransferSpreadSheet nach 255 Zeichen

Hallo zusammen,

mich beschäftigt seit zwei Tagen ein Problem für das ich keine richtige Lösung finde. Vielleicht hat einer von euch gleiche Probleme oder sogar eine Lösung.

Ich möchte über den VBA-Befehl Code:

den Inhalt einer Excel-Tabelle in eine Tabelle in meiner Access-DB einzufügen. Soweit funktioniert das auch. Das Problem ist, dass in einigen Zellen der Excel-Tabelle Zeichenketten stehen, die bis zu 7000 Zeichen lang sind. Diese werden immer nach 255 Zeichen in Access abgeschnitten. Die Zielfelder in Access sind jedoch alle als "memo" definert.

Bisher habe ich gelesen, dass Access die ersten 8 - 25 Zeilen der Excel-Tabelle analysiert und dann den Datentyp "rät". Eine Sortierung in Excel einzubauen, dass die langen Daten in Excel oben stehen, kommt aber leider für mich nicht in Frage.

Hat jemand von euch noch Ideen, wie man dieses Problem lösen könnte?

Greetz
rodgerwilco

:)

 

Hi,
hast Du schon versucht die Exceltabelle nur zu verknüpfen? Wenn ja ist dann das entsprechende Feld auch abgeschnitten?

Als alternative würde ich den Import der Exceltabelle über das Excel-Object versuchen. Macht zwar mehr Arbeit als mit einem Befehl "TransferSpreadsheet", hat aber den Vorteil, dass man den Inhalt der einzelnen Zellen gezielt behandeln kann.

Servus
Peter

 

Hi Peterffw,

in der verknüpften Tabelle sind die Werte ebenfalls abgeschnitten. Ich werde es mal als Excel-Objekt versuchen und danach wieder berichten.

Greetz

 

Hallo rodgerwilco!

Eine weitere Möglichkeit besteht darin, die Excel Tabelle als Textdatei zu ex- und so in Access zu importieren.

Wolfgang

 

Also der Umweg über ein Excel-Objekt funktioniert, ist aber recht umständlich.
Das bringt mich aber gleich zum nächsten Problem. Die Daten, welche jetzt in eine Access-Tabelle kopiert wurden, möchte ich über ein SELECT wieder auslesen. Sogar beidem einfachsten Code:

werden die Strings abgeschnitten.
Hat wer dafür eine Lösung?

 

Hi,
in der Tabelle selbst hat das entsprechende Feld aber noch einen Inhalt grösser 255 und ist vom Typ "MEMO"?

Servus
Peter

 

Hallo,

und eine weitere Möglichkeit, diese Excel-Tabelle in der Access-DB zu verknüpfen
und dann mit einer Anfügeabfrage die Daten in eine Tabelle einfügen.
Die Excel kannst ja immer ändern, der Name der Datei muss gleich bleiben.
Eine Abfrage zeigt den gesamten Text eines Memos an, gruppieren kannst ein Memofeld nicht!
Dann muss es gekürzt werden wie Left(xMemo,256).

 

Vielen Dank erstmal an alle, die sich hier gemeldet haben. Das Handling von Zeichenketten mit mehr als 256 Zeichen ist echt schwierig unter Access.

Daher mal um die Ecke gedacht:
Kennt jemand eine Kompressionsmethode, die Zeichenketten mit maximal 256 Zeichen aus Text erstellt. Dann würde ich diese speichern und verarbeiten und nur beim Anzeigen für den Nutzer die Kompression wieder rückgängig machen.

Greetz

 

...was ist daran so schwer?

Dein Vorhaben (Kompressionsmethode / für den Nutzer die Kompression wieder rückgängig) ist eventuell schwer *Smilie
Aber, sonst wüsste ich nicht. Außerdem habe ich es ja schon geschrieben... Left...

Habe aber keine Ahnung, für was du das wirklich benötigst.
Ich habe ein Memofeld in meiner DB und das kann ich komplett in einer Abfrage anzeigen.

Vermutlich verstehe ich dich nicht!

 

Hallo Alfred,

das Einlesen der Excel-Tabelle in eine Access-Tabelle funktioniert mittels Excel-Objekt. Hier benötige ich somit keine verlinkte Excel-Tabelle.

Mein grober Verarbeitungsprozess sieht wie folgt aus:

1. Excel-Tabelle einlesen
2. eingelesene Daten automatisiert verarbeiten
3. auf SQL-Server persistieren

Für Schritt 3 wird ein Code:

durchgeführt, welches wieder dafür sorgt, dass die Felder gekürzt werden.

 

Hallo,
also nmM läuft hier irgendwas falsch.

Mein Access (2010) verknüpft eine Exceltabelle (xls) ohne Zeichen abzuschneiden (304 Zeichen getestet).

Auch sollte es intern in Access keine Probleme mit Memo-Feldern geben.

Wird bei der Anfügeabfrage abgeschnitten liegt es wohl eher an der Tabelle "tblPersistent".

 

...hmmm

von dem war aber bis jetzt nichts zu lesen...oder?