11
Zahlen in Datum umwandeln in Tabelle
Hallo zusammen,
ich lasse eine Tabelle über eine TXT-Datei befüllen, in der es zwei Datumsfelder gibt. Leider hat das Datum in der TXT-Datei folgendes Format: 771203.
Mit welchem Statement kann ich den Zahlenwert in der Tabelle wie folgt umwandeln?
771203 --> 03.12.1977
Ich verwenden einen SQL2005 Standard Server. Ich kann auf dem System leider nicht mit anderen Mitteln als mit SQL-Statements arbeiten.
Kennt jemand eine Lösung?
ich lasse eine Tabelle über eine TXT-Datei befüllen, in der es zwei Datumsfelder gibt. Leider hat das Datum in der TXT-Datei folgendes Format: 771203.
Mit welchem Statement kann ich den Zahlenwert in der Tabelle wie folgt umwandeln?
771203 --> 03.12.1977
Ich verwenden einen SQL2005 Standard Server. Ich kann auf dem System leider nicht mit anderen Mitteln als mit SQL-Statements arbeiten.
Kennt jemand eine Lösung?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Kommentar vom Moderator Biber am Mar 19, 2010 um 12:33:31 Uhr
Auf "Erledigt" gesetzt.
Content-Key: 138465
Url: https://administrator.de/contentid/138465
Printed on: April 23, 2024 at 07:04 o'clock
11 Comments
Latest comment
Moin dondy,
habe deine Anforderung nur teilweise verstanden.
Deshalb die Nachfragen:
Grüße
Biber
habe deine Anforderung nur teilweise verstanden.
Deshalb die Nachfragen:
- ich gehe hoffentlich fehl in der Annahme, dass du die Übernahme der beiden YYMMDD-Zeichenfelder aus der Textdatei in die DB-Tabelle beibehalten willst und redundant die Werte nochmals in derselben Tabelle alls Datumswert speichern willst?
- deshalb die Anschlussfrage: willst du also das Ganze beim Import glattziehen - if so, wie heißen Quelle, Zieltabelle, Felder, Import-Statement...?
- Wenn aber Import-Mimik unangetastet bleiben soll/muss, also nur ein View zusammengeschrotet werden soll: wie heißen Tabelle, Felder...?
Grüße
Biber
Hi Biber,
die TXT-Datei wird so wie sie ist in eine Tabelle gepackt, ohne Umwandlung. Von dieser Tabelle soll es dann in eine weitere Tabelle gehen. Die Umwandlung soll beim Import in die zweite Tabelle erfolgen.
Der Grund für die erste Tabelle ist, dass ein anderes Programm genau diese Tabelle benötigt und deshalb die Daten "redundant" vorliegen.
Ich stelle mir irgendwie sowas vor:
select datum from tabelle1
into tabelle2
convert datum 771203 --> 03.12.1977
die TXT-Datei wird so wie sie ist in eine Tabelle gepackt, ohne Umwandlung. Von dieser Tabelle soll es dann in eine weitere Tabelle gehen. Die Umwandlung soll beim Import in die zweite Tabelle erfolgen.
Der Grund für die erste Tabelle ist, dass ein anderes Programm genau diese Tabelle benötigt und deshalb die Daten "redundant" vorliegen.
Ich stelle mir irgendwie sowas vor:
select datum from tabelle1
into tabelle2
convert datum 771203 --> 03.12.1977
Hallo dondy,
Du musst die Idee aber noch in die richtige Syntax umbauen.
| "." | links(datum,5,2) | ".19" |
Du musst die Idee aber noch in die richtige Syntax umbauen.
Hallo,
ja genau sowas habe ich gesucht, es funktioniert auch, fast.
Wie kann ich den funktionen right und left sage, dass sie nicht die zeichen 0 bis 6 nehmen sollen, sondern zum beispiel die zahlen an stelle 5 UND 6?
ja genau sowas habe ich gesucht, es funktioniert auch, fast.
Wie kann ich den funktionen right und left sage, dass sie nicht die zeichen 0 bis 6 nehmen sollen, sondern zum beispiel die zahlen an stelle 5 UND 6?
Moin dondy,
Eigentlich SUBSTRING(ausgangs_string [FROM start_position] [FOR laenge])
aber im täglichen Gebrauch meist angedeutet als SUBSTRING( ausgangs_string, start_position, laenge)
--> in deinem Fall also SUBSTRING(datum, 5, 2).
Grüße
Biber
Zitat von @dondy:
Wie kann ich den funktionen right und left sage, dass sie nicht die zeichen 0 bis 6 nehmen sollen, sondern zum beispiel die zahlen an stelle 5 UND 6?
Dafür wiederum wäre die skalare Funktion SUBSTRING bei M$-SQL zuständig.Wie kann ich den funktionen right und left sage, dass sie nicht die zeichen 0 bis 6 nehmen sollen, sondern zum beispiel die zahlen an stelle 5 UND 6?
Eigentlich SUBSTRING(ausgangs_string [FROM start_position] [FOR laenge])
aber im täglichen Gebrauch meist angedeutet als SUBSTRING( ausgangs_string, start_position, laenge)
--> in deinem Fall also SUBSTRING(datum, 5, 2).
Grüße
Biber
Moin,
machen wir es doch nicht so kompliziert und nehmen einfach Datumskonvertierungen:
Kleiner Nachtrag: läßt man das äußere convert weg, hat man auch das Format, in dem man sowas normal ablegt, datetime
Gruß, Mad Max
machen wir es doch nicht so kompliziert und nehmen einfach Datumskonvertierungen:
select convert (varchar, convert (datetime, '771203', 12), 104) Kleiner Nachtrag: läßt man das äußere convert weg, hat man auch das Format, in dem man sowas normal ablegt, datetime
Gruß, Mad Max
Na ja, Mad Max,
schon richtig, aber...
zwei Unwägbarkeiten dabei.
Erstens hast du bzw. dondy ja noch eine Konvertierung mehr - denn dieses Drexdatum liegt ja als "Zahl" vor, nicht als varchar().
Zweitens (aus meiner Sicht versteckter und deshalb gefährlicher).
Dieses verbotenerweise mit 2stelligen Jahreszahlen gespeicherte Datum hat eventuell ja irgendwelche internen Regeln und Konventionen, ab wann denn eine Jahreszahl wie in dem Beispiel "77" als "Jahr 1977" oder "Jahr 2077" interpretiert werden soll.
Mit einer Substring/Concat-Mimik kannst du das abbilden.... jeweils an der gleichen Sollbruchstelle eben eine "19" oder "20" als Jahrhundertwert davorschreiben.
Wenn du Convert(..6stelligeDatumsentsprechung...zu Datum TT.MM.JJJJ) aufrufst, dann wird die Sollbruchstelle von MSSQL genommen.
Sollte dondy wenigstens vorher wissen... der sucht sich sonst albern bei Dateninkonsistenzen.
@dondy
Ich bin immer wieder aufs Neue verblüfft, dass heute, Anno 2010, immer noch datenliefernde Systemchen unterwegs sind, die Datumswerte ohne Jahrhundertangaben exportieren.
Gab es nicht damals, vor 11 Jahren, diese Y2K-Zertifierung unter gar keinen Umständen für solchen Pfusch?
Grüße
Biber
schon richtig, aber...
zwei Unwägbarkeiten dabei.
Erstens hast du bzw. dondy ja noch eine Konvertierung mehr - denn dieses Drexdatum liegt ja als "Zahl" vor, nicht als varchar().
Zweitens (aus meiner Sicht versteckter und deshalb gefährlicher).
Dieses verbotenerweise mit 2stelligen Jahreszahlen gespeicherte Datum hat eventuell ja irgendwelche internen Regeln und Konventionen, ab wann denn eine Jahreszahl wie in dem Beispiel "77" als "Jahr 1977" oder "Jahr 2077" interpretiert werden soll.
Mit einer Substring/Concat-Mimik kannst du das abbilden.... jeweils an der gleichen Sollbruchstelle eben eine "19" oder "20" als Jahrhundertwert davorschreiben.
Wenn du Convert(..6stelligeDatumsentsprechung...zu Datum TT.MM.JJJJ) aufrufst, dann wird die Sollbruchstelle von MSSQL genommen.
Sollte dondy wenigstens vorher wissen... der sucht sich sonst albern bei Dateninkonsistenzen.
@dondy
Ich bin immer wieder aufs Neue verblüfft, dass heute, Anno 2010, immer noch datenliefernde Systemchen unterwegs sind, die Datumswerte ohne Jahrhundertangaben exportieren.
Gab es nicht damals, vor 11 Jahren, diese Y2K-Zertifierung unter gar keinen Umständen für solchen Pfusch?
Grüße
Biber
Moinmoin,
Aber da sich dondy ja nicht mehr rührt, scheint sein Problem wohl eh erledigt zu sein.
Gruß, Mad Max
Zitat von @Biber:
Erstens hast du bzw. dondy ja noch eine Konvertierung mehr - denn dieses Drexdatum liegt ja als "Zahl" vor, nicht als
varchar().
Wenn ich das richtig gelesen habe, kommt das Ganze aus einer Textdatei, müßte deshalb erstmal als Text vorliegen. Wenn nicht, wird '771203' (bzw. die Variable/Spalte) einfach durch convert (varchar, 771203) ersetzt.Erstens hast du bzw. dondy ja noch eine Konvertierung mehr - denn dieses Drexdatum liegt ja als "Zahl" vor, nicht als
varchar().
Zitat von @Biber:
Zweitens (aus meiner Sicht versteckter und deshalb gefährlicher).
Dieses verbotenerweise mit 2stelligen Jahreszahlen gespeicherte Datum hat eventuell ja irgendwelche internen Regeln und
Konventionen, ab wann denn eine Jahreszahl wie in dem Beispiel "77" als "Jahr 1977" oder "Jahr 2077"
interpretiert werden soll.
Da hast Du natürlich recht, aber das ist ja erstmal ein Problem der zweistelligen Jahreszahlen. Bei SQL Server geht der Bereich standardmäßig von 1950 - 2049. Das kann man ggf. mit dateadd (yy, 100, <Datum>) bzw. dateadd (yy, -100, <Datum>) korrigieren. Oder noch geschickter, man ändert diesen Bereich durch:Zweitens (aus meiner Sicht versteckter und deshalb gefährlicher).
Dieses verbotenerweise mit 2stelligen Jahreszahlen gespeicherte Datum hat eventuell ja irgendwelche internen Regeln und
Konventionen, ab wann denn eine Jahreszahl wie in dem Beispiel "77" als "Jahr 1977" oder "Jahr 2077"
interpretiert werden soll.
exec sp_configure 'show advanced options', 1
reconfigure
exec sp_configure 'two digit year cutoff', <Jahr> -- <Jahr> = letztes Jahr des 100-Jahres-Bereichs, also z.B. 2029 fuer 1930 - 2029
exec sp_configure 'show advanced options', 0
reconfigureAber da sich dondy ja nicht mehr rührt, scheint sein Problem wohl eh erledigt zu sein.
Gruß, Mad Max
Moin Mad Max,
Wenn ich es richtig gelesen haben, dreht er noch eine Extra-Schleife "die TXT-Datei wird so wie sie ist in eine Tabelle gepackt, ohne Umwandlung".
Wobei dieses "ohne Umwandlung" aber im weiteren Beitragsverlauf zu bedeuten scheint, dass dieses 6stellige Datumskrams als Zahl vorliegt.
Andererseits fände ich es viel zu schade, diesen Beitrag wegen fehlender Rückmeldung in die Tonne zu kloppen.
Soll ich mal einfach einen Erledigt-Haken dransetzen? *grübel* [Edit] nach kurzer Bedenkzeit getan. [/Edit]
Biber
Zitat von @MadMax:
Moinmoin,
> Zitat von @Biber:
> ----
> Erstens hast du bzw. dondy ja noch eine Konvertierung mehr - denn dieses Drexdatum liegt ja als "Zahl" vor, nicht als varchar().
Wenn ich das richtig gelesen habe, kommt das Ganze aus einer Textdatei, müßte deshalb erstmal als Text vorliegen.
Sagen wir so - vielleicht ist es besser, lieber gar nicht so genau den ganzen Ablauf zu hinterfragen... Moinmoin,
> Zitat von @Biber:
> ----
> Erstens hast du bzw. dondy ja noch eine Konvertierung mehr - denn dieses Drexdatum liegt ja als "Zahl" vor, nicht als varchar().
Wenn ich das richtig gelesen habe, kommt das Ganze aus einer Textdatei, müßte deshalb erstmal als Text vorliegen.
Wenn ich es richtig gelesen haben, dreht er noch eine Extra-Schleife "die TXT-Datei wird so wie sie ist in eine Tabelle gepackt, ohne Umwandlung".
Wobei dieses "ohne Umwandlung" aber im weiteren Beitragsverlauf zu bedeuten scheint, dass dieses 6stellige Datumskrams als Zahl vorliegt.
Aber da sich dondy ja nicht mehr rührt, scheint sein Problem wohl eh erledigt zu sein.
Hmmja, ist mir auch nicht entgangen, dass er ein wenig stiller geworden ist in letzter Zeit.Andererseits fände ich es viel zu schade, diesen Beitrag wegen fehlender Rückmeldung in die Tonne zu kloppen.
Soll ich mal einfach einen Erledigt-Haken dransetzen? *grübel* [Edit] nach kurzer Bedenkzeit getan. [/Edit]
Gruß, Mad Max
Grüße zurückBiber
Keine Rückmeldung ist ja auch eine Art Rückmeldung. Insofern wäre das Problem wohl gelöst. Anregungen bzw. Anleitungen, wie es geht, stehen jedenfalls gleich mehrere hier.
Schönes Wochenende,
Mad Max
Schönes Wochenende,
Mad Max
@Biber
@mad Max
danke euch beiden für die schönen Anregungen zu dem Thema.
Genau deshalb lese ich hier.
Schönes WE noch.
@mad Max
danke euch beiden für die schönen Anregungen zu dem Thema.
Genau deshalb lese ich hier.
Schönes WE noch.
