Welchen Datentyp für #

[marc75]

Hallo Leute,

welchen Datentyp würdet Ihr für eine Spalte wählen, wenn das Sonderzeichen # bei den Einträgen (Import aus Excel) vorkommen könnte?
Ich dachte, wenn ich "Text" (Char - Varchar) wählen würde, sollte es keine Probleme geben, aber Access sagt mir immer, es gibt Probleme mit der Typumwandlung.

[defo]

wenn das Sonderzeichen # bei den Einträgen (Import aus Excel) vorkommen könnte?
aber Access sagt mir immer, es gibt Probleme mit der Typumwandlung.

Bist Du sicher, dass der Fehler durch das Zeichen # hervorgerufen wird?
Text sollte ja eigentlich alles schlucken, was ankommt.
Gegenanzeigen sehe ich nur bei der Textlänge und der Kodierung. Das wäre im ersten Ansatz also bei den Exceldaten zu verifizieren.

[marc75]

naja wenn ich das Zeichen lösche, gibt es keine Fehlermeldung, wenn ich es wieder einfüge ist die Fehlermeldung wieder da.

[Christian Marquardt]

Wie wird importiert? Aus einer CVS-Datei? Ist das # der Delimiter? Fehlt da ev. ein Wert

[marc75]

Import erfolgt per DoCmd.TransferSpreadsheet und Excelliste (xls)
# wird wahrscheinlich als Platzhalter genutzt. Es ist überall da vorhanden, wo kein Wert vorhanden ist. Hab da auch kein Einfluß drauf, das Format wird so geliefert.

[Christian Marquardt]

Dann wird es wohl an einer Stelle kommen (Datum, Zahl) wo eben wohl kein Text/Char als Tabellentyp vorhanden ist (Datum, nummerisch). Es erscheint sinnvoll, in der Excel-Datei vor dem Inmport alle # durch "nichts" zu ersetzen. Was sollte so ein Platzhalter in der DB? Bei zukünftigen Abfragen müsste man ja berücksichtigen, dass da ein # stehen könnte

[tinof]

Ist das ein "#" oder steht die ganze Zelle voll "#######"? Letzteres macht Excel, wenn der Zelleninhalt zu lang wird, praktisch zu "viel" Text zum Anzeigen in der Zelle steht. Dann ist der Wert vielleicht auch zu lang für das Ziel - Datenbankfeld?

[defo]

Ist das ein "#" oder steht die ganze Zelle voll "#######"? Letzteres macht Excel, wenn der Zelleninhalt zu lang wird, praktisch zu "viel" Text zum Anzeigen in der Zelle steht. Dann ist der Wert vielleicht auch zu lang für das Ziel - Datenbankfeld?

Diese # werden doch auch angezeigt, wenn die Formatmasken nicht passen bzw. fehlerhaft sind oder? Oder nur, wenn die maskierte Ausgabe nicht vollständig in die Zelle passt (Zellenbreite)?

[Bernhard Geyer]

Ich Tipp mal darauf das Accesss versucht Werte mit # als Datum/Uhrzeit zu interpretieren (ist ne bescheuerte Eigenheit von Access # als Separator/Kennzeichner von Datum/Uhrzeitwerten zu verwenden)
probiert doch mal eine Beispieldatei mit einem gültigen Datumswert #5/18/1999 14:00:00# in deiner Datei

[marc75]

# scheint ein Platzhalter für leere Zellen zu sein, warum auch immer. Im Ursprungssystem sind die entprechenden Felder jedenfalls leer. In der DB (Oracle) wird es eventuell NULL sein. Da hab ich kein Zugriff drauf.

In der Spalte können auch Datumswerte vorkommen.

Um das # vor dem Upload zu entfernen, müsste ich erst eine Routine bauen, die beim Upload die Datei öffnet und alle Zellen durchläuft. Schleifen sind allerdings langsam und bei 20 Tsd und mehr einträgen könnte es eine Weile dauern. Dem jeweiligen MA kann ich es leider nicht auferlegen, die entsprechende Liste erst zu bearbeiten, das wären zu Viele, die dann eine Einweisung bräuchten bzw. die Fehlerquelle wäre dann immer noch zu hoch.

@bernhard geyer
was könnte ich machen, um Access von diesem Vorhaben abzubringen. Wenn ich die Spalte als Datum deklariere, ändert es ja auch nichts an der Fehlermeldung, da es ja bei den # kein Datum gibt.

[Christian Marquardt]

Kann es sein, dass im ersten Datensatz in der Exceldatei an der Stelle mit den Rauten auch nummerische Werte stehen?

Microsoft ACCESS entscheidet beim Importieren von Microsoft EXCEL-Tabellen, anhand des ersten Datensatzes, welchen Typ das Datenfeld annimmt.

Wenn also beispielsweise im ersten Feld des ersten Datensatzes "1234" steht wird Access von einem nummerischen Datentyp ausgehen. Steht nun im ersten Feld des zweiten Datensatzes ein"#" gibt es den Fehler

http://support.microsoft.com/kb/500789/de

[Bernhard Geyer]

was könnte ich machen, um Access von diesem Vorhaben abzubringen. Wenn ich die Spalte als Datum deklariere, ändert es ja auch nichts an der Fehlermeldung, da es ja bei den # kein Datum gibt.

Einen eigenen Importer schrieben. Sich auf Standard-Routinen verlassen die nur 95% aller Fälle abdecken ist in 5% der Fälle schlecht gewählt.

20k Datensätze ist nicht die Welt. Vernünftig implementiert ist das in < 1 Minute Importiert.

[tinof]

GGf. Suchen und Ersetzen über Excel.Find, das ist viel schneller als eine Schleife - erwischt möglicherweise aber auch zu viel.

Viel Erfolg!

[marc75]

20k Datensätze ist nicht die Welt.

ich weiß, dennoch hab ich da irgendwo den Wurm drin.

Vernünftig implementiert ist das in < 1 Minute Importiert

So war es auch mal bei der ersten Version, nach X Änderungswünschen scheine ich da eine Bremse eingebaut zu haben.
Allein ein Import/Abgleich ohne # in den Datensätzen braucht aktuell 5-10 Minuten.

Microsoft ACCESS entscheidet beim Importieren von Microsoft EXCEL-Tabellen, anhand des ersten Datensatzes, welchen Typ das Datenfeld annimmt.

Aber doch nur, wenn beim Import die Tabelle erst erzeugt wird, oder? Die Importtabelle ist ja in meinem Fall schon vorhanden, mit all seinen Datenfeldbezeichnungen und Verknüpfungen etc.

Sich auf Standard-Routinen verlassen die nur 95% aller Fälle abdecken ist in 5% der Fälle schlecht gewählt.

Ich dachte mir, warum das Rad neu erfinden, hatte halt bis jetzt auch so funktioniert.

GGf. Suchen und Ersetzen über Excel.Find, das ist viel schneller als eine Schleife - erwischt möglicherweise aber auch zu viel.

Das muß ich erst prüfen, nicht das die Raute # noch in irgenwelchen Kryptischen Zeichenketten vorhanden ist und dann im Zielprogramm benötigt wird.