Zahlen mit führenden Nullen in Textdatei exportieren
Bjoern
Folgendes Problem:
Ich habe eine Tabelle, in der eine Spalte Textfelder enthält, die nur aus
Zahlen bestehen.
Also z.B. "12345678"
Da die Feldlänge immer 8-stellig sein soll, sind kürzere Einträge einfach
mit Nullen aufgefüllt.
Ein Auszug der Spalte könnte also so aussehen:
00123456
12345678
00012345
01234567
...
Die führenden Nullen werden für die Weiterverarbeitung unbedingt benötigt.
Wie gesagt, das Format der Spalte ist in der Tabelle als Text definiert, die
Nullen sind also "wirklich da".
So, diese Tabelle exportiere ich nun als txt-Datei, dabei gehen aber leider
die führenden nullen verloren.
Den Export der Datei mache ich mit VBA, und zwar so:
DoCmd.TransferText acExportDelim, Spezi, Tabelle, Pfad & Datei, True, ""
Die Variablen werden im Code durch Auslesen von Formularfeldern gesetzt.
Die Spezifikation beinhaltet folgende Einstellungen:
Trennzeichen: TAB
Textbegrenzugn: kein
Sprache: Deutsch
Codepage: Unicode (UTF-8)
Der Rest ist wohl egal, denn die Inhalte der anderen Spalten enthalten keine
Werte, die davon berührt wären
Ich habe mit den Einstellungen herumprobiert, nix zu machen, die führenden
Nullen werden in der resultierenden Textdatei abgeschnitten.
So, dann habe ich mal einfach den Export ohne Spezifikation durchgeführt,
und siehe da, die Nullen sind da. Allerdings dann standardmäßig mit
Textbegrenzern und falschen Trennzeichen. Ich habe dann eine Spezifikation
neu gebaut, und Schritt für Schritt alle Einstellungen nach obigem Muster
eingestellt.
Und was soll ich sagen? Ich hatte alle Einstellungen übernommen, und die
führenden Nullen sind trotzdem da!!
Wie kann das angehen? Ich habe eine neue Spezifikation gebaut, die genauso
aussieht wie die alte, und trotzdem ist das Ergebnis unterschiedlich!
Auch wenn ich jetzt probeweise die alte Spezifikation benutze, werden die
Nullen wieder abgeschnitten.
=> zwei gleiche Spezifikationen => unterschiedliches Ergebnis!
ich kann nur sagen: MAGIC!!!
Das Problem ist zwar gelöst, aber es würde mich echt interessieren, wie
sowas angehen kann.
Vieleicht weiß ja hier jemand Rat.
besten Dank und viele Grüße,
Björn
Peter Doering
Bjoern wrote:
> Ich habe eine Tabelle, in der eine Spalte Textfelder enth�lt, die nur aus
> Zahlen bestehen.
> Also z.B. "12345678"
> Da die Feldl�nge immer 8-stellig sein soll, sind k�rzere Eintr�ge einfach
> mit Nullen aufgef�llt.
>
> Ein Auszug der Spalte k�nnte also so aussehen:
> 00123456
> 12345678
> 00012345
> 01234567
> ...
>
> Die f�hrenden Nullen werden f�r die Weiterverarbeitung unbedingt ben�tigt.
> Wie gesagt, das Format der Spalte ist in der Tabelle als Text definiert, die
> Nullen sind also "wirklich da".
>
> So, diese Tabelle exportiere ich nun als txt-Datei, dabei gehen aber leider
> die f�hrenden nullen verloren.
>
> Den Export der Datei mache ich mit VBA, und zwar so:
>
> DoCmd.TransferText acExportDelim, Spezi, Tabelle, Pfad & Datei, True, ""
>
> Die Variablen werden im Code durch Auslesen von Formularfeldern gesetzt.
> Die Spezifikation beinhaltet folgende Einstellungen:
>
> Trennzeichen: TAB
> Textbegrenzugn: kein
> Sprache: Deutsch
> Codepage: Unicode (UTF-8)
> Der Rest ist wohl egal, denn die Inhalte der anderen Spalten enthalten keine
> Werte, die davon ber�hrt w�ren
>
> Ich habe mit den Einstellungen herumprobiert, nix zu machen, die f�hrenden
> Nullen werden in der resultierenden Textdatei abgeschnitten.
>
> So, dann habe ich mal einfach den Export ohne Spezifikation durchgef�hrt,
> und siehe da, die Nullen sind da. Allerdings dann standardm��ig mit
> Textbegrenzern und falschen Trennzeichen. Ich habe dann eine Spezifikation
> neu gebaut, und Schritt f�r Schritt alle Einstellungen nach obigem Muster
> eingestellt.
> Und was soll ich sagen? Ich hatte alle Einstellungen �bernommen, und die
> f�hrenden Nullen sind trotzdem da!!
> Wie kann das angehen? Ich habe eine neue Spezifikation gebaut, die genauso
> aussieht wie die alte, und trotzdem ist das Ergebnis unterschiedlich!
>
> Auch wenn ich jetzt probeweise die alte Spezifikation benutze, werden die
> Nullen wieder abgeschnitten.
> => zwei gleiche Spezifikationen => unterschiedliches Ergebnis!
> ich kann nur sagen: MAGIC!!!
>
> Das Problem ist zwar gel�st, aber es w�rde mich echt interessieren, wie
> sowas angehen kann.
Vergleiche mal die Eintraege der beiden Spezifikationen auf Tabellenebene.
Dazu musst du die Systemdateien einblenden (Extras - Optionen - Ansicht)
und die Tabellen MSysIMEXSpecs und MSysIMEXColumns am besten per Abfrage
auswerten. SpecID ist der gemeinsame Schluessel.
Gruss - Peter
--
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com
Bjoern
"Peter Doering" wrote:
> Hallo,
>
> Bjoern wrote:
>
> > Ich habe eine Tabelle, in der eine Spalte Textfelder enthält, die nur aus
> > Zahlen bestehen.
> > Also z.B. "12345678"
> > Da die Feldlänge immer 8-stellig sein soll, sind kürzere Einträge einfach
> > mit Nullen aufgefüllt.
> >
> > Ein Auszug der Spalte könnte also so aussehen:
> > 00123456
> > 12345678
> > 00012345
> > 01234567
> > ...
> >
> > Die führenden Nullen werden für die Weiterverarbeitung unbedingt benötigt.
> > Wie gesagt, das Format der Spalte ist in der Tabelle als Text definiert, die
> > Nullen sind also "wirklich da".
> >
> > So, diese Tabelle exportiere ich nun als txt-Datei, dabei gehen aber leider
> > die führenden nullen verloren.
> >
> > Den Export der Datei mache ich mit VBA, und zwar so:
> >
> > DoCmd.TransferText acExportDelim, Spezi, Tabelle, Pfad & Datei, True, ""
> >
> > Die Variablen werden im Code durch Auslesen von Formularfeldern gesetzt.
> > Die Spezifikation beinhaltet folgende Einstellungen:
> >
> > Trennzeichen: TAB
> > Textbegrenzugn: kein
> > Sprache: Deutsch
> > Codepage: Unicode (UTF-8)
> > Der Rest ist wohl egal, denn die Inhalte der anderen Spalten enthalten keine
> > Werte, die davon berührt wären
> >
> > Ich habe mit den Einstellungen herumprobiert, nix zu machen, die führenden
> > Nullen werden in der resultierenden Textdatei abgeschnitten.
> >
> > So, dann habe ich mal einfach den Export ohne Spezifikation durchgeführt,
> > und siehe da, die Nullen sind da. Allerdings dann standardmäßig mit
> > Textbegrenzern und falschen Trennzeichen. Ich habe dann eine Spezifikation
> > neu gebaut, und Schritt für Schritt alle Einstellungen nach obigem Muster
> > eingestellt.
> > Und was soll ich sagen? Ich hatte alle Einstellungen übernommen, und die
> > führenden Nullen sind trotzdem da!!
> > Wie kann das angehen? Ich habe eine neue Spezifikation gebaut, die genauso
> > aussieht wie die alte, und trotzdem ist das Ergebnis unterschiedlich!
> >
> > Auch wenn ich jetzt probeweise die alte Spezifikation benutze, werden die
> > Nullen wieder abgeschnitten.
> > => zwei gleiche Spezifikationen => unterschiedliches Ergebnis!
> > ich kann nur sagen: MAGIC!!!
> >
> > Das Problem ist zwar gelöst, aber es würde mich echt interessieren, wie
> > sowas angehen kann.
>
> Vergleiche mal die Eintraege der beiden Spezifikationen auf Tabellenebene.
> Dazu musst du die Systemdateien einblenden (Extras - Optionen - Ansicht)
> und die Tabellen MSysIMEXSpecs und MSysIMEXColumns am besten per Abfrage
> auswerten. SpecID ist der gemeinsame Schluessel.
>
> Gruss - Peter
>
> --
> Mitglied im http://www.dbdev.org
> FAQ: http://www.donkarl.com
> .
>
Moin Peter!
Besten Dank für Deine sehr Interessanten Hinweise! Ich habe mich schon lange
gefragt, wo die Spezifikationen wohl abgelegt sind, jetzt weiß ich es!
Aber nochmal zur Frage:
Ich habe mir die beiden Tabellen angesehen, und in der Tat Unterschiede
festgestellt.
Und zwar hat die Spalte, die die Nummern mit den führenden Nullen enthält,
einen unterschiedlichen Datentyp (alte Spezi: 16, neue Spezi: 10) und eine
andere Breite (alte Spezi: Width=16, neue Spezi: Width=8)
Das klingt mir sehr nach "Zahl 16bit" [also long integer] und "Text 8
Zeichen lang", und wenn das so ist, dann würde das erklären, warum die Nullen
abgeschnitten werden.
ABER: wo kann ich denn den Datentyp und die Länge innerhalb der
Spezifikation definieren??
Im Dialog "Exportspezifikation" habe ich keine Möglichkeit, da irgendwas
einzustellen, anders bei der Importspezifikation, dort kann ich für jede zu
importierende Spalte festlegen, welchen Datentyp sie hat.
Ich habe folgende Vermutung: Als ich die erste Spezifikation gebaut hatte,
hatte die Spalte mit den Nummern noch keine führenden Nullen und war in der
Tabelle als Zahl definiert. Die Anforderung mit den führenden Nullen kam
später, daraufhin habe ich in der Tabelle den Datentyp auf Text geändert und
die Nullen aufgefüllt.
Dies hat die Spezifikation 'nicht mitbekommen' und erst durch die Erstellung
der neuen Spezifikation wurde erkannt, dass es sich um Text handelt.
Kann das so gewesen sein?
Freue mich auf Deine Einschätzung!
Danke und viele Grüße,
Björn
PS: frohes neues Jahr übrigens!
Karl Donaubauer
> "Peter Doering" wrote:
>> ...
>> Dazu musst du die Systemdateien einblenden (Extras -
>> Optionen - Ansicht)
>> und die Tabellen MSysIMEXSpecs und MSysIMEXColumns am besten per
>> Abfrage auswerten. SpecID ist der gemeinsame Schluessel.
> Ich habe mir die beiden Tabellen angesehen, und in der Tat
> Unterschiede festgestellt.
> enth�lt, einen unterschiedlichen Datentyp (alte Spezi: 16, neue
> Spezi: 10) und eine andere Breite (alte Spezi: Width=16, neue Spezi:
> Width=8)
> Ich habe folgende Vermutung: Als ich die erste Spezifikation gebaut
> und war in der Tabelle als Zahl definiert. Die Anforderung mit den
> Datentyp auf Text ge�ndert und die Nullen aufgef�llt.
> Dies hat die Spezifikation 'nicht mitbekommen' und erst durch die
> Erstellung der neuen Spezifikation wurde erkannt, dass es sich um
> Text handelt.
> Kann das so gewesen sein?
Joo.
--
Servus
Karl
****************
Access-FAQ: http://www.donkarl.com /// http://www.donkarl.com?NEK
.NET-Entwickler-Konferenz f�r Accessler 27./28.2.2010
Peter Doering
Bjoern wrote:
> "Peter Doering" wrote:
>> Bjoern wrote:
>>
>>> [Zahl mit fuehrenden Nullen exportieren]
>>> DoCmd.TransferText acExportDelim, Spezi, Tabelle, Pfad & Datei, True, ""
>>> [...]
>>> => zwei gleiche Spezifikationen => unterschiedliches Ergebnis!
>>
>> Vergleiche mal die Eintraege der beiden Spezifikationen auf Tabellenebene.
>> Dazu musst du die Systemdateien einblenden (Extras - Optionen - Ansicht)
>> und die Tabellen MSysIMEXSpecs und MSysIMEXColumns am besten per Abfrage
>> auswerten. SpecID ist der gemeinsame Schluessel.
>
> Ich habe mir die beiden Tabellen angesehen, und in der Tat Unterschiede
> festgestellt.
> Und zwar hat die Spalte, die die Nummern mit den f�hrenden Nullen enth�lt,
> einen unterschiedlichen Datentyp (alte Spezi: 16, neue Spezi: 10)
Hier liegt der Hund begraben. Welche Access-Version benutzt du eigentlich?
Der Datentyp fuer Text ist 10. 16 kommt bei meinen Versionen nirgens vor.
> Das klingt mir sehr nach "Zahl 16bit" [also long integer]
Long ist Datentyp 4. Der Vollstaendigkeit halber:
1 = Boolean (YesNo)
2 = Byte
3 = Integer
4 = Long
5 = Currency
6 = Single
7 = Double
8 = Date
9 existiert nicht
10 = Text
11 = OLE
12 = Memo / Hyperlink
> ABER: wo kann ich denn den Datentyp und die L�nge innerhalb der
> Spezifikation definieren??
> Im Dialog "Exportspezifikation" habe ich keine M�glichkeit, da irgendwas
> einzustellen, anders bei der Importspezifikation, dort kann ich f�r jede zu
> importierende Spalte festlegen, welchen Datentyp sie hat.
Die Typen festlegen kannst du nur per Importspezifikation, was aber keine
Rolle spielt, denn die Spezifikation kann sowohl fuer Im- als auch Export
verwendet werden.
Bjoern
"Peter Doering" wrote:
> Hallo,
>
> Bjoern wrote:
> > "Peter Doering" wrote:
> >> Bjoern wrote:
> >>
> >>> [Zahl mit fuehrenden Nullen exportieren]
> >>> DoCmd.TransferText acExportDelim, Spezi, Tabelle, Pfad & Datei, True, ""
> >>> [...]
> >>> => zwei gleiche Spezifikationen => unterschiedliches Ergebnis!
> >>
> >> Vergleiche mal die Eintraege der beiden Spezifikationen auf Tabellenebene.
> >> Dazu musst du die Systemdateien einblenden (Extras - Optionen - Ansicht)
> >> und die Tabellen MSysIMEXSpecs und MSysIMEXColumns am besten per Abfrage
> >> auswerten. SpecID ist der gemeinsame Schluessel.
> >
> > Ich habe mir die beiden Tabellen angesehen, und in der Tat Unterschiede
> > festgestellt.
> > Und zwar hat die Spalte, die die Nummern mit den führenden Nullen enthält,
> > einen unterschiedlichen Datentyp (alte Spezi: 16, neue Spezi: 10)
>
> Hier liegt der Hund begraben. Welche Access-Version benutzt du eigentlich?
> Der Datentyp fuer Text ist 10. 16 kommt bei meinen Versionen nirgens vor.
>
> > Das klingt mir sehr nach "Zahl 16bit" [also long integer]
>
> Long ist Datentyp 4. Der Vollstaendigkeit halber:
>
> 1 = Boolean (YesNo)
> 2 = Byte
> 3 = Integer
> 4 = Long
> 5 = Currency
> 6 = Single
> 7 = Double
> 8 = Date
> 9 existiert nicht
> 10 = Text
> 11 = OLE
> 12 = Memo / Hyperlink
>
> > ABER: wo kann ich denn den Datentyp und die Länge innerhalb der
> > Spezifikation definieren??
> > Im Dialog "Exportspezifikation" habe ich keine Möglichkeit, da irgendwas
> > einzustellen, anders bei der Importspezifikation, dort kann ich für jede zu
> > importierende Spalte festlegen, welchen Datentyp sie hat.
>
> Die Typen festlegen kannst du nur per Importspezifikation, was aber keine
> Rolle spielt, denn die Spezifikation kann sowohl fuer Im- als auch Export
> verwendet werden.
>
> Gruss - Peter
>
> --
> Mitglied im http://www.dbdev.org
> FAQ: http://www.donkarl.com
> .
Moin Peter!
Ich verwende Access 2003, und der Datentyp ist definitiv 16, ebenso wie die
Länge (width). Habe gerade nochmal nachgeschaut.
Dass man Importspezifikationen auch zum Exportieren verwenden kann, wusste
ich nicht. Sehr nützliche Information...
Danke und viele Grüße, auch an Dich, Karl,
Björn