WinFuture-Forum.de: Access: führende Nullen bei CSV-Export fehlen - WinFuture-Forum.de

Zum Inhalt wechseln

  • 3 Seiten +
  • 1
  • 2
  • 3

Access: führende Nullen bei CSV-Export fehlen

#1 Mitglied ist offline   SuperWolf 

  • Gruppe: aktive Mitglieder
  • Beiträge: 455
  • Beigetreten: 11. September 06
  • Reputation: 0

geschrieben 16. November 2016 - 09:07

Hallo,

ich habe eine Access-Datenbank und habe eine Tabelle bearbeitet.
Spalte GUID wird mit einem Autowert befüllt. Der Autowert muss 8-stellig sein, wobei durch die Formatierung führende Nullen entstehen.
Das ist so gewünscht.

Aufgrund der Systemlandschaft müssen die Daten ins CSV-Format exportiert werden.
Beim Export fallen die Nullen weg, da Formatierungen nicht übernommen werden.

Hat jemand eine Idee wie ich die Werte wie gewünscht als CSV exportieren kann?


DANKE vorab!
In der Zeitung von heute werden morgen Fische eingepackt!
0

Anzeige

#2 Mitglied ist offline   Gispelmob 

  • Gruppe: aktive Mitglieder
  • Beiträge: 1.132
  • Beigetreten: 14. August 15
  • Reputation: 95

geschrieben 16. November 2016 - 09:35

die ID mit einer 1 beginnen lassen wäre eine Möglichkeit^^
0

#3 Mitglied ist offline   Holger_N 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.213
  • Beigetreten: 11. September 10
  • Reputation: 199

geschrieben 16. November 2016 - 10:42

Sind die führenden Nullen nicht ohnehin nur eine Formatierung, auf die man bei Import/Weiterverarbeitung usw. nur immer wieder achten muß? Also eine 83 bleibt für das System doch eine 83 und es wird nur für die Ausgabe eine 00000083 daraus gemacht. Also was ich damit sagen will ist, dass man dann einfach nur darauf achten muß, wenn man die CSV importiert, dass (je nach Art und Weise)die Felder der Exceltabelle entsprechend formatiert sein müssen oder in PHP bzw. sonstigen Sprache der Parser beim Import die Nullen wieder auffüllt. Man könnte auch für den »Transport« die Zahl in einen String umwandeln und wieder zurück, wobei das vielleicht keinen Sinn macht, wenn nach dem zurückwandeln die Nullen weg sind und so oder so wieder aufgefüllt werden müssen.
Ich bin ein sehr ordentlicher, fleißiger und reinlicher Mensch, nur leider gefangen im Körper eines schmuddeligen Faulpelzes … tja, kann man nix machen …
0

#4 Mitglied ist offline   Stefan_der_held 

  • Gruppe: Offizieller Support
  • Beiträge: 12.715
  • Beigetreten: 08. April 06
  • Reputation: 399

geschrieben 16. November 2016 - 15:00

[quote name='Holger_N' timestamp='1479289371' post='1973817']
Sind die führenden Nullen nicht ohnehin nur eine Formatierung, auf die man bei Import/Weiterverarbeitung usw. nur immer wieder achten muß? Also eine 83 bleibt für das System doch eine 83 und es wird nur für die Ausgabe eine 00000083 daraus gemacht.
[/Code]

naja kommt drauf an was mit gemacht wird... Bankleitahlen sollte man bspw. immer als Text-Feld hinterlegen da sich ein Unterschied zwischen bspw.

000000230



und
230



ergibt.

@TE: Evtl. zeigt sich da jetzt ein Designfehler der Datenbank? Wie ist denn real die Ausgabe dieses Feldes? sind die "Nullen" vorhanden? Oder fehlen die dort auch?
Eingefügtes Bild
0

#5 Mitglied ist offline   Gispelmob 

  • Gruppe: aktive Mitglieder
  • Beiträge: 1.132
  • Beigetreten: 14. August 15
  • Reputation: 95

geschrieben 16. November 2016 - 15:42

Wenn führende Nullen bei CSV Export wegfallen, dann gibt es in Access sicher eine Option beim CSV Export die das Abschneiden der führenden Nullen abschaltet. Im Zweifelsfall hilft noch VBA.

Beitrag anzeigenZitat (Stefan_der_held: 16. November 2016 - 15:00)

naja kommt drauf an was mit gemacht wird... Bankleitahlen sollte man bspw. immer als Text-Feld hinterlegen da sich ein Unterschied zwischen bspw.

000000230



und
230



ergibt.

Ich hoffe du meinst den TEXT Datatype von Access, der eigentlich ein VARCHAR ist. Denn Bankleitzahlen als Text speichern ist ein Designfehler. Wenn dann werden die als CHAR bzw VARCHAR gespeichert. Es gibt keinen Grund unnötigt Speicherplatz zu verschwenden. Außerdem sollte man jetzt die IBAN verwenden. Die Länge ist international standardisiert (34 Zeichen). Somit kann man eine feste CHAR Länge nutzen und die IBAN lasst sich auch gut validieren. Da braucht es kein Text-Feld.

Dieser Beitrag wurde von Gispelmob bearbeitet: 16. November 2016 - 15:45

0

#6 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.768
  • Beigetreten: 20. Juli 07
  • Reputation: 860

geschrieben 16. November 2016 - 18:12

Ich hoffe Du hast nach dem Schreiben gemerkt, daß kein formaler Datentyp gemeint war, sondern einfach "nicht als Zahl ablegen". :)

Fehler im Datenbankentwurf hin oder her, jetzt isses eh zu spät, und womöglich (vermutlich) auch nicht im Verantwortungsbereich des TO.

-- Die führenden Nullen gibts daher dummerweise tatsächlich nur durchs Postprocessing, wenn Access nicht formatiert exportieren will.

Also müßtest Du, wie ja schon angeführt, beim Import dafür sorgen, daß die Werte richtig dastehen oder zumindest richtig angezeigt werden.

Beides läßt sich über Formatstrings regeln. Mit *printf und Kompatiblen wäre das dann sowas wie %08d. MSIL(.NET kompatible Sprachen) machen das auch mit String.Format("{<position:<format>}", variable).

Ansonsten - allerdings kenn ich mich dazu mit MS's Möchtegerndatenbanksystem nicht gut genug aus -- besteht zumindest potentiell die Möglichkeit, die GUID in ein Zeichenformat umzubauen (CHAR(8) oder wie immer Access das nennt) und dann bei der Konvertierung drauf zu achten, daß die führenden Nullen mitgenommen werden. Aufpassen - VORHER sicherstellen, daß das mit Primärschlüsseln bei Access auch nicht-numerisch tut, vor allem, wenn diese SERIAL sind, oder AUTO_INCREMENT, oder "AutoWert"; Strings hochzählen kann nicht jeder.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
0

#7 Mitglied ist offline   Holger_N 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.213
  • Beigetreten: 11. September 10
  • Reputation: 199

geschrieben 16. November 2016 - 18:45

Beitrag anzeigenZitat (Gispelmob: 16. November 2016 - 15:42)


…Denn Bankleitzahlen als Text speichern ist ein Designfehler. Wenn dann werden die als CHAR bzw VARCHAR gespeichert. Es gibt keinen Grund unnötigt Speicherplatz zu verschwenden. Außerdem sollte man jetzt die IBAN verwenden.



Es geht ja nicht um Überweisungen, sondern um das Speichern in Datenbanken und wenn da zu einem Kunden/Konto, beispielsweise in einem Archiv, die alten Kontodaten gespeichert werden sollen, dann muß da ja die Bankleitzahl rein.
Ich bin ein sehr ordentlicher, fleißiger und reinlicher Mensch, nur leider gefangen im Körper eines schmuddeligen Faulpelzes … tja, kann man nix machen …
0

#8 Mitglied ist offline   Gispelmob 

  • Gruppe: aktive Mitglieder
  • Beiträge: 1.132
  • Beigetreten: 14. August 15
  • Reputation: 95

geschrieben 17. November 2016 - 04:13

Beitrag anzeigenZitat (Holger_N: 16. November 2016 - 18:45)

Es geht ja nicht um Überweisungen, sondern um das Speichern in Datenbanken und wenn da zu einem Kunden/Konto, beispielsweise in einem Archiv, die alten Kontodaten gespeichert werden sollen, dann muß da ja die Bankleitzahl rein.
Hilfe! Dafür nimmt man aber kein Texfeld und knallt dort sämliche Daten rein. Wenn man auch alte Daten speichern will, dann erstellt man dafür eine neue Tabelle mit den benötigten Feldern und Feldgrößen und verknüft diese per ID. Der Vorteil ist hier, dass diese dann nur abgefragt werden müssen wenn man die Daten braucht und sonst nie. Mal davon abgesehen, dass man kein Text-Feld für Kontonummern oder BLZ braucht wenn man ordentlich mit Normalformen arbeitet.

Dieser Beitrag wurde von Gispelmob bearbeitet: 17. November 2016 - 04:18

0

#9 Mitglied ist offline   SuperWolf 

  • Gruppe: aktive Mitglieder
  • Beiträge: 455
  • Beigetreten: 11. September 06
  • Reputation: 0

geschrieben 17. November 2016 - 09:00

Danke für die rege Diskussion, das Problem ist aber glaube einfacher wie man denkt.

Die führenden Nullen werden als Export benötigt, um im separaten System, die Daten korrekt hochzuladen.
Via Import werden keine führenden Nullen importiert. Das Feld soll mittels Access erstellt werden und auch genauso ausgegeben werden.

Mein Problem ist es, dass es an der Ausgabe (Export) scheitert.

Access dient nur als Mittel zum Zweck (Datenaufbereitung) und nicht als direkte Datenbank.
In der Zeitung von heute werden morgen Fische eingepackt!
0

#10 Mitglied ist offline   Holger_N 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.213
  • Beigetreten: 11. September 10
  • Reputation: 199

geschrieben 17. November 2016 - 09:30

Kann man dem zweiten System, also wo die CSV-Datei importiert wird nicht »sagen« dass es beim Import aus dem entsprechenden Wert eine 8-stellige Zahl mit führenden Nullen machen soll? Es würde ja so oder so nichts helfen, wenn man Access dazu bringt, die führenden Nullen mit in die CSV zu schreiben, wenn die mangels Formatierung in der CSV-Datei beim Import dann doch wieder wegfallen.
Ich bin ein sehr ordentlicher, fleißiger und reinlicher Mensch, nur leider gefangen im Körper eines schmuddeligen Faulpelzes … tja, kann man nix machen …
0

#11 Mitglied ist offline   SuperWolf 

  • Gruppe: aktive Mitglieder
  • Beiträge: 455
  • Beigetreten: 11. September 06
  • Reputation: 0

geschrieben 17. November 2016 - 09:36

Leider nein.

Mein Wunsch wäre es einen Autowert zu generieren der ungefähr so aussieht.

TARG2017-00000001
TARG2017-00000002
TARG2017-00000003
usw.

Und genauso sollten die Werte auch im CSV-Export enthalten sein. Teil 1 bekomme ich problemlos hin, via Formatierung im Export sieht es dann aber so aus:
1
2
3
usw.
In der Zeitung von heute werden morgen Fische eingepackt!
0

#12 Mitglied ist offline   Gispelmob 

  • Gruppe: aktive Mitglieder
  • Beiträge: 1.132
  • Beigetreten: 14. August 15
  • Reputation: 95

geschrieben 17. November 2016 - 11:04

Ich hatte dazu bereits eine Lösung vorgeschlagen und zwar die Zahl mit einer 1 beginnen zu lassen.

TARG2017-10000000
TARG2017-10000001
TARG2017-10000002
TARG2017-10000003

dabei kann man auch gleich die erste Zahl mit einer 0 an der letzten Stellen mitnutzen.
0

#13 Mitglied ist offline   Holger_N 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.213
  • Beigetreten: 11. September 10
  • Reputation: 199

geschrieben 17. November 2016 - 11:26

Ich verstehe jetzt aber wieder nicht, wie es bei einer Zeichenkette, die mit »TARG…« beginnt, Probleme mit führenden Nullen geben kann.
Ich bin ein sehr ordentlicher, fleißiger und reinlicher Mensch, nur leider gefangen im Körper eines schmuddeligen Faulpelzes … tja, kann man nix machen …
0

#14 Mitglied ist offline   Gispelmob 

  • Gruppe: aktive Mitglieder
  • Beiträge: 1.132
  • Beigetreten: 14. August 15
  • Reputation: 95

geschrieben 17. November 2016 - 12:21

Vermutlich wird nur die Zahl gespeichert und der Prefix per Script oder Format davor gesetzt.
0

#15 Mitglied ist offline   SuperWolf 

  • Gruppe: aktive Mitglieder
  • Beiträge: 455
  • Beigetreten: 11. September 06
  • Reputation: 0

geschrieben 17. November 2016 - 12:37

Genau der Prefix wurde per Format davor gesetzt, ebenso wie die führenden Nullen.
Bei der Ausgabe wird das aber alles ignoriert und dafür suche ich eine Lösung!

Beitrag anzeigenZitat (Gispelmob: 17. November 2016 - 11:04)

Ich hatte dazu bereits eine Lösung vorgeschlagen und zwar die Zahl mit einer 1 beginnen zu lassen.

TARG2017-10000000
TARG2017-10000001
TARG2017-10000002
TARG2017-10000003

dabei kann man auch gleich die erste Zahl mit einer 0 an der letzten Stellen mitnutzen.


Mit 1 beginnend habe ich beim Export das selbe Ergebnis.
In der Zeitung von heute werden morgen Fische eingepackt!
0

Thema verteilen:


  • 3 Seiten +
  • 1
  • 2
  • 3

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0