Ich hab jetzt ein Problem, das beim einfügen einer Exceltabelle in meiner Datenbank aufgetreten ist.
Die Exceltabelle füge ich mit DoCmd.TransferSpreadsheet ein. Ich erstelle damit eine Tabelle und baue das ganze etwas um.
So weit kein Problem.
Als ich dann aber probieren wollte ob ich einzelne Teile in meine Haupttabelle einfügen kann macht Access nichst, und erstellt mir eine Tabelle wie zB 'Planung-Bau$'_Importfehler.
Planung-Bau und Bestell-Nr sind aber kein Teil der Haupttabelle. Und auch in der Zeile 193 finde ich nichst. Weder in der Exceltabelle noch in meiner Datenbank.
Inhalt der Fehlertabelle:
Fehler Typ Zeile
Fehler bei Typumwandlung Bestell-Nr 193
Kann mir jemand erklären was das zu bedeuten hat?
Hallo,
vielleicht soll von "Bestell" "Nr" subtrahiert werden ...
Tja...
Hat sich erledígt. Hab gerade rausgefunden das er mir die Fehlertabelle jedesmal rausgibt wenn ich DoCmd.TransferSpreadsheet anwende.
Grüße
T.
Hallo,
naja, das ist wohl der Anlass, aber nicht der Grund. Der Grund liegt am Minus-Zeichen im Feld/Spaltenname, was mein vorheriger Kommentar aussagen sollte....
Wie schon mehr als 1000 mal gesagt:
Auf Sonder- und Leerzeichen in Objektnamen dringend verzichten! auch, wenn es Excel-Spaltennamen sind, die für den Import herhalten sollen..
Nein.
Der Grund liegt daran das beim Import von Exceltabellen von Access immer die erste Zeile genommen wird um den Datentyp für die Spalten festzulegen.
Das heißt:
Wenn ich in der Spalte Datum in der ersten Zeile den Wert 2010 stehen hat, dann bekomme ich für die gesamte Spalte den Datentyp "Zahl".
Wenn ich in der Spalte Planung in der ersten Zeile Bauabschnitt 1 stehen hab, bekomme ich den Typ "Text".
Wenn ich in der Spalte Bestellsumme in der ersten Zeile den Wert 456,89 stehen hab, bekomme ich den Typ "Währung"
usw
Das macht das Einfügen natürlich schwer, denn irgendwo gibt es immer ein falschen Datensatz.
Grüße
T.
Hallo,
ZitatDer Grund liegt daran das beim Import von Exceltabellen von Access immer die erste Zeile genommen wird um den Datentyp für die Spalten festzulegen
Nein.
Wenn du mit einer Importspezifikation arbeitest bestimmst DU den Datentyp und kannst bei der Gelegenheit auch gleich die Empfehlung von Franz umsetzen.
Wobei ich in den von dir genannten Beispielen aber auch absolut keinen Fehler entdecken kann, da die von Access ausgewählten Datentypen zweifelsohne den Gegebenheiten entsprechen.
Das Problem liegt also nicht auf der Access-Seite sondern auf der Seite des Excel-Users, der z.B. in eine numerische Spalte plötzlich Textzeichenfolgen einträgt.
Mittels einer Importspezifikation KÖNNTEST du den Datentyp Text für ALLE Spalten festlegen.
Weiter KÖNNTEST du VOR dem Import alle betroffenen Spalten in Excel den Datentyp TEXT zuweisen, damit entfällt auch die Datentypwahl - es wird TEXT importiert!
Ist die Tabelle dann mal auf der Access-Seite wäre es weiter möglich die Datensätze mittels einer Schleife zu durchlaufen, bei Typfehlern entsprechend zu reagieren
und auf diese Weise fehlerfreie Datensätze in eine vorbereitete Zieltabelle zu verfrachten.
Ist zwar ein wenig aufwändig zu programmieren wenn's aber mal läuft eine recht gute Sache.
Ob sich der Aufwand rechnet ist natürlich abhängig davon wie oft solche Importe zu bewerkstelligen sind und dann auch wieviele Datensätze jedesmal betroffen sind.
Hallo,
eine Tabellenerstellungsabfrage, bzw. Transferspreadsheet benutzt in der Tat die ersten 8 (nicht nur die allererste) Zeile im Sheet, um den möglichst passenden Datentyp einer Spalte zu ermitteln.
Nichtsdestotrotz besteht aus den genannten (von DB-Seite gesehenen) Unzulänglichkeiten einer Definiton des richtigen Datentyps in Excel immer das Risiko, die Daten falsch zu importieren, so dass man um eine wie auch immer geartete "Sicherungsmaßnahme" nicht herumkommt, z. B. die Daten in eine strukturell vordefinierte (Access-) Tabelle mittels Anfügeabfrage hinzuzufügen und auf eine Tabellenerstellungsabfrage zu verzichten.
Fehlermeldung bzgl. falschen Datentyps sind damit natürlich auch nicht ausgeschlossen, wenn man die auftretenden Fehlersituationen nicht explizit behandelt (z. B.Import per Excel-Automation und Recordset, um an die einzelnen "Zellwerte" per Code zu gelangen und die zu manipulieren.)
Statt Transferspreadsheet ist m. E. ein Verknüpfen des Excel-Sheets und anschliessender Datenübertragung in Access-Tabelle mittels Anfügeabfrage ein geeigneter Kompromiss zwischen Aufwand und Fehlertoleranz.
Hallo,
Ich hätte in meinen letzen Beitrag darauf hinweisen können, das ich das Problem bereits gelöst habe, aber ich dachte eigenlich das Häkchen würde als Hinweis reichen:
(Ich hatte alles bereits mit einer vordefinierten Tabelle erledigt)
Grüße
Einige Anmerkungen:
Importspezifikation betrifft Textdateien, nicht Excel-Arbeitsblätter. Das hieße also: Exceltabelle -> CSV -> Datenbanktabelle
Zitatein Verknüpfen des Excel-Sheets
... könnte auch mit TransferSpreadsheet acLink erfolgen, was aber die gleichen Probleme wie beim Import per TransferSpreadsheet mit sich bringt.
Persönlich mache ich gute Erfahrungen mit folgender Gestaltung:
INSERT INTO Zieltabelle (Feld1, Feld2)
SELECT T.Feld1, T.Feld2
FROM [excel 8.0;hdr=yes;imex=1;DATABASE=D:\eine\Exeldatei.xls].[Tabelle1$] AS T"IMEX=1;" tells the driver to always read "intermixed" (numbers, dates, strings etc) data columns as text.
In jedem Fall hat eine Zieltabelle, die man per Anfügeabfrage füllt, festgelegte definierte Datentypen in den Feldern. Falsche Werte ergeben dann einen Fehler - besser an der Schnittstelle Import als irgendwann später im Betrieb.
Zitatdenn irgendwo gibt es immer ein falschen Datensatz
Gegen Datenmüll in der Tabelle hat man nur begrenzte Möglichkeiten. Bei bekannten Problemen könnte man Umformungen/Konvertierungen anwenden, bei spontaner "Kreativität" ist man bzgl. Automatisierung etwas hilflos - bei allen genannten Verfahren.
MfGA
ebs
Ich habe umgebaut und lasse den Nutzer jetzt über die Standartimportierung gehen. (Datei->Externe Daten->Importierung)
Aufgerufen über:CommandBars("Menu Bar").Controls("Datei").Controls("Externe Daten").Controls("Importieren...").accDoDefaultAction
Das ist den Nutzer noch zuzutrauen das er das hinbekommt.
Und mit einem Standardmenü-Import kommen keine Fehler, die bei TransferSpreadsheet kommen?
ZitatDas ist den Nutzer noch zuzutrauen ...
Benutzeraktivitäten sind eigentlich die größten Fehlerquellen. Wenn Du diese höher anstellst als eine von einem Entwickler durchdachte Routine, dann passt etwas nicht ...
MfGA
ebs
In diesen Falle kann man es dem Nutzer wirklich zutrauen. ;)
(Natürlich ist das nur ein Teil einer Routine, da natürlich nicht alles vom Nutzer bearbeitet werden kann.)
Fehler können zwar vorkommen, aber daran arbeite ich gerade.
(vordefinierte Tabelle)