6
Microsoft Excel neue Abfrage ODBC Julianisch Datum umwandeln in DD.MM.JJJJ
Hallo,
ich stehe vor folgendem Problem, wie kann ich aus Excel und einer ODBC Abfrage als SQL-Anweisung ein Julianische DAtum in dass Datumformat tt.mm.jjjj ändern.
In Excel als Formel geht es JulianischeDAtum - 2415019 anschließend Zellen formatieren Datum tt.mm.jjjj
So sieht momentan die SQL-Anweisung im Microsoft Query aus mit Ergebnis Julianische Datum:
SELECT AUFTRAGSKOPF.TOURGEBIETID, AUFTRAGSKOPF.NUMMERAUFT, AUFTRAGSKOPF.NUMMERAUFTFO, AUFTRAGSKOPF.KUNDENNUMMER, KUNDEN.NAME1, KUNDEN.NAME2, KUNDEN.STRASSE, KUNDEN.PLZ, KUNDEN.ORT, AUFTRAGSKOPF.DATUMAUSLIEF, AUFTPOSITIONEN.NUMMERAUFTFO, AUFTPOSITIONEN.ARTIKELNUMMER, AUFTPOSITIONEN.BEZEICHNUNG1, AUFTPOSITIONEN.BEZEICHNUNG2, AUFTPOSITIONEN.BEZEICHNUNG3, AUFTPOSITIONEN.MENGEGELIEF
FROM diacom.AUFTPOSITIONEN AUFTPOSITIONEN, diacom.AUFTRAGSKOPF AUFTRAGSKOPF, diacom.KUNDEN KUNDEN
WHERE AUFTPOSITIONEN.NUMMERAUFTFO = AUFTRAGSKOPF.NUMMERAUFTFO AND AUFTPOSITIONEN.NUMMERAUFT = AUFTRAGSKOPF.NUMMERAUFT AND AUFTPOSITIONEN.KUNDENNUMMER = KUNDEN.KUNDENNUMMER AND AUFTRAGSKOPF.KUNDENNUMMER = KUNDEN.KUNDENNUMMER AND ((AUFTRAGSKOPF.NUMMERAUFT='766782'))
Das Entscheidende Feld ist "AUFTRAGSKOPF.DATUMAUSLIEF" hier muss das Julianische Datum umgewandelt werden
ich stehe vor folgendem Problem, wie kann ich aus Excel und einer ODBC Abfrage als SQL-Anweisung ein Julianische DAtum in dass Datumformat tt.mm.jjjj ändern.
In Excel als Formel geht es JulianischeDAtum - 2415019 anschließend Zellen formatieren Datum tt.mm.jjjj
So sieht momentan die SQL-Anweisung im Microsoft Query aus mit Ergebnis Julianische Datum:
SELECT AUFTRAGSKOPF.TOURGEBIETID, AUFTRAGSKOPF.NUMMERAUFT, AUFTRAGSKOPF.NUMMERAUFTFO, AUFTRAGSKOPF.KUNDENNUMMER, KUNDEN.NAME1, KUNDEN.NAME2, KUNDEN.STRASSE, KUNDEN.PLZ, KUNDEN.ORT, AUFTRAGSKOPF.DATUMAUSLIEF, AUFTPOSITIONEN.NUMMERAUFTFO, AUFTPOSITIONEN.ARTIKELNUMMER, AUFTPOSITIONEN.BEZEICHNUNG1, AUFTPOSITIONEN.BEZEICHNUNG2, AUFTPOSITIONEN.BEZEICHNUNG3, AUFTPOSITIONEN.MENGEGELIEF
FROM diacom.AUFTPOSITIONEN AUFTPOSITIONEN, diacom.AUFTRAGSKOPF AUFTRAGSKOPF, diacom.KUNDEN KUNDEN
WHERE AUFTPOSITIONEN.NUMMERAUFTFO = AUFTRAGSKOPF.NUMMERAUFTFO AND AUFTPOSITIONEN.NUMMERAUFT = AUFTRAGSKOPF.NUMMERAUFT AND AUFTPOSITIONEN.KUNDENNUMMER = KUNDEN.KUNDENNUMMER AND AUFTRAGSKOPF.KUNDENNUMMER = KUNDEN.KUNDENNUMMER AND ((AUFTRAGSKOPF.NUMMERAUFT='766782'))
Das Entscheidende Feld ist "AUFTRAGSKOPF.DATUMAUSLIEF" hier muss das Julianische Datum umgewandelt werden
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 103252
Url: https://administrator.de/contentid/103252
Printed on: April 19, 2024 at 21:04 o'clock
6 Comments
Latest comment
Moin Moelle,
ich versuche es noch mal... schrittweise.
Bitte verwende auch Du für < Code > die gleichnamigen Code-Tags (siehe in unseren FAQ unter Formatierungen).
Das Statement oben ist vielleicht für irgendein Query-Tool "lesbar", aber für die altmodische bio-optische Abtastung, der hier viele Member anhängen, schlichtweg unzumutbar.
Nach dem ersten Schritt - lesbar machen für uns MitleserInnen und nach wie vor für dieses ###-Query-Tool dieser Redmonder ### sieht dat Dingen so aus:
-- Nix verändert außer Umformulierung auf mein absolutes Minimum von Ästhetik und Wartbarkeit --
--> hier ist zu sehen, dass die Where-Clause redundant die Bedingung
Die Auftragspositions-Tabelle kann nicht auch noch im PK die Kundennummer haben - hat doch die Auftragskopf -Tabelle schon.
Es sei denn, dieses Datenmodell stammt vom Trio Stevie Wonder, Ray Charles und Johnnie Walker.
Anyhow... ändert ja nix an der eigentlichen Frage.
Ich habe es im letzten Thread schon geschrieben.
Das doofe M$-Query-Tool könnte doch auch auf eine Access-Abfrage zugreifen.
Mach das doch bitte, dann stehen Dir Dutzende von JET-SQL- und Access-Funktionen zur Verfügung.
Beim Zugriff über ODBC hast Du nur die paar Funktiönchen, die im ODBC-Treiber selbst hinterlegt sind.
Und das ist selbst nach meinen Toleranzmaßstäben unverschämt wenig.
Du hast im Querytool keine DateAdd(), DateDiff() oder auch nur Format() oder Convert()-Funktion... das ist richtig grottig.
Das Einzige, was implementiert und dokumentiert zu sein scheint, sind ein paar Aggregatsfunktionen für Summe, Mittelwert und ähnliches.
Aber okay, MacGuywer hat ja auch damals mit einer Büroklammer und einem Kaugummi diesen Tschernobyl-Reaktor geflickt, oder war das Vattenfall....?
uups, ich schweife ab. Sorry.
Für folgendes Statement werden mich alle hassen, die je versucht haben, mir SQL beizubringen und erst recht die Redmonder Bagage:
Anm.: 2415019 ist wieder die berühmte Moelle-Konstante,
die auf das Datum der großen Fusspilz-Epidemie in Vorderasien verweist... diesen 1.Jan 4732 v.Chr)
Egal, so versteht es jedenfalls auch das ver###te M$-Query-###-Tool.
Und ich werde vehement abstreiten, dass ich jemals diesen Workaround gepostet habe.
Grüße & viel Glück.
Biber
P.S. Es ist der falsche Ansatz --
das Geradebiegen des Datumswertes muss in der Datenbank erfolgen, nicht beim ODBC-Zugriff.
ich versuche es noch mal... schrittweise.
Bitte verwende auch Du für < Code > die gleichnamigen Code-Tags (siehe in unseren FAQ unter Formatierungen).
Das Statement oben ist vielleicht für irgendein Query-Tool "lesbar", aber für die altmodische bio-optische Abtastung, der hier viele Member anhängen, schlichtweg unzumutbar.
Nach dem ersten Schritt - lesbar machen für uns MitleserInnen und nach wie vor für dieses ###-Query-Tool dieser Redmonder ### sieht dat Dingen so aus:
SELECT ak.TOURGEBIETID,
ak.NUMMERAUFT,
ak.NUMMERAUFTFO,
ak.KUNDENNUMMER,
ku.NAME1, ku.NAME2, ku.STRASSE, ku.PLZ, ku.ORT,
ak.DATUMAUSLIEF,
apos.NUMMERAUFTFO,
apos.ARTIKELNUMMER,
apos.BEZEICHNUNG1,
apos.BEZEICHNUNG2, AUFTPOSITIONEN.BEZEICHNUNG3,
apos.MENGEGELIEF
FROM diacom.AUFTPOSITIONEN apos,
diacom.AUFTRAGSKOPF Ak,
diacom.KUNDEN KU
WHERE
apos.NUMMERAUFTFO = ak.NUMMERAUFTFO
AND apos.NUMMERAUFT = ak.NUMMERAUFT
AND apos.KUNDENNUMMER = ku.KUNDENNUMMER
AND ak.KUNDENNUMMER = ku.KUNDENNUMMER
AND ((ako.NUMMERAUFT='766782')) --> hier ist zu sehen, dass die Where-Clause redundant die Bedingung
AND apos.KUNDENNUMMER = ku.KUNDENNUMMER
enthält. Kann nich' angehn.Die Auftragspositions-Tabelle kann nicht auch noch im PK die Kundennummer haben - hat doch die Auftragskopf -Tabelle schon.
Es sei denn, dieses Datenmodell stammt vom Trio Stevie Wonder, Ray Charles und Johnnie Walker.
Anyhow... ändert ja nix an der eigentlichen Frage.
Ich habe es im letzten Thread schon geschrieben.
Das doofe M$-Query-Tool könnte doch auch auf eine Access-Abfrage zugreifen.
Mach das doch bitte, dann stehen Dir Dutzende von JET-SQL- und Access-Funktionen zur Verfügung.
Beim Zugriff über ODBC hast Du nur die paar Funktiönchen, die im ODBC-Treiber selbst hinterlegt sind.
Und das ist selbst nach meinen Toleranzmaßstäben unverschämt wenig.
Du hast im Querytool keine DateAdd(), DateDiff() oder auch nur Format() oder Convert()-Funktion... das ist richtig grottig.
Das Einzige, was implementiert und dokumentiert zu sein scheint, sind ein paar Aggregatsfunktionen für Summe, Mittelwert und ähnliches.
Aber okay, MacGuywer hat ja auch damals mit einer Büroklammer und einem Kaugummi diesen Tschernobyl-Reaktor geflickt, oder war das Vattenfall....?
uups, ich schweife ab. Sorry.
Für folgendes Statement werden mich alle hassen, die je versucht haben, mir SQL beizubringen und erst recht die Redmonder Bagage:
SELECT ak.TOURGEBIETID,
ak.NUMMERAUFT,
ak.NUMMERAUFTFO,
ak.KUNDENNUMMER,
ku.NAME1, ku.NAME2, ku.STRASSE, ku.PLZ, ku.ORT,
ak.DATUMAUSLIEF,
(date()-(date()*1.0)+(ak.DATUMAUSLIEF-2415019)) AS 'LIEFDAT',
apos.NUMMERAUFTFO,
apos.ARTIKELNUMMER,
apos.BEZEICHNUNG1,
apos.BEZEICHNUNG2, AUFTPOSITIONEN.BEZEICHNUNG3,
apos.MENGEGELIEF
FROM diacom.AUFTPOSITIONEN apos,
diacom.AUFTRAGSKOPF Ak,
diacom.KUNDEN KU
WHERE
apos.NUMMERAUFTFO = ak.NUMMERAUFTFO
AND apos.NUMMERAUFT = ak.NUMMERAUFT
AND apos.KUNDENNUMMER = ku.KUNDENNUMMER
AND ak.KUNDENNUMMER = ku.KUNDENNUMMER
AND ((ako.NUMMERAUFT='766782')) die auf das Datum der großen Fusspilz-Epidemie in Vorderasien verweist... diesen 1.Jan 4732 v.Chr)
Egal, so versteht es jedenfalls auch das ver###te M$-Query-###-Tool.
Und ich werde vehement abstreiten, dass ich jemals diesen Workaround gepostet habe.
Grüße & viel Glück.
Biber
P.S. Es ist der falsche Ansatz --
das Geradebiegen des Datumswertes muss in der Datenbank erfolgen, nicht beim ODBC-Zugriff.
Hallo Biber ich verspreche dir ich werde mich bessern in Sachen Layout und Fragestellung. Leider lief es im Query auf einem Fehler INCORRECT NUMBER OF ARGUMENTS (0): DATE(N|D)or DATE(N|D,C|N)or DATE(N|D,C|N,C|N)
So sieht die SQL-Anweisung im Query aus.
So das ist ein etwas anderer Versuch Ziel ist es nachher zu sagen, zeige alle die Datum x enthalten. Vorher war es nur ein Beispiel mit einem Auftrag.
Hier fehlt natürlich wieder das umgewandelte Datum.
So sieht die SQL-Anweisung im Query aus.
SELECT AUFTRAGSKOPF.TOURGEBIETID, AUFTRAGSKOPF.NUMMERAUFT, AUFTRAGSKOPF.NUMMERAUFTFO, AUFTRAGSKOPF.KUNDENNUMMER, KUNDEN.NAME1, KUNDEN.NAME2, KUNDEN.STRASSE, KUNDEN.PLZ, KUNDEN.ORT, AUFTRAGSKOPF.DATUMAUSLIEF, (date()-(date()*1.0)+(AUFTRAGSKOPF.DATUMAUSLIEF-2415019)) AS 'LIEFDAT', AUFTPOSITIONEN.NUMMERAUFTFO,
AUFTPOSITIONEN.ARTIKELNUMMER, AUFTPOSITIONEN.BEZEICHNUNG1,
AUFTPOSITIONEN.BEZEICHNUNG2, AUFTPOSITIONEN.BEZEICHNUNG3,
AUFTPOSITIONEN.MENGEGELIEF FROM diacom.AUFTPOSITIONEN AUFTPOSITIONEN,
diacom.AUFTRAGSKOPF AUFTRAGSKOPF, diacom.KUNDEN KUNDEN
WHERE AUFTPOSITIONEN.NUMMERAUFTFO = AUFTRAGSKOPF.NUMMERAUFTFO
AND AUFTPOSITIONEN.NUMMERAUFT = AUFTRAGSKOPF.NUMMERAUFT
AND AUFTPOSITIONEN.KUNDENNUMMER = KUNDEN.KUNDENNUMMER
AND AUFTRAGSKOPF.KUNDENNUMMER = KUNDEN.KUNDENNUMMER
AND ((ako.NUMMERAUFT='766782')) So das ist ein etwas anderer Versuch Ziel ist es nachher zu sagen, zeige alle die Datum x enthalten. Vorher war es nur ein Beispiel mit einem Auftrag.
Hier fehlt natürlich wieder das umgewandelte Datum.
SELECT AUFTRAGSKOPF.NUMMERAUFT,
AUFTRAGSKOPF.NUMMERAUFTFO,
AUFTRAGSKOPF.TOURGEBIETID,
AUFTRAGSKOPF.DATUMAUSLIEF,
AUFTRAGSKOPF.KUNDENNUMMER,
KUNDEN.NAME1,
KUNDEN.NAME2,
KUNDEN.STRASSE,
KUNDEN.PLZ,
KUNDEN.ORT,
AUFTPOSITIONEN.ARTIKELNUMMER,
AUFTPOSITIONEN.BEZEICHNUNG1,
AUFTPOSITIONEN.BEZEICHNUNG2,
AUFTPOSITIONEN.BEZEICHNUNG3,
AUFTPOSITIONEN.MENGEGELIEF
FROM diacom.AUFTPOSITIONEN AUFTPOSITIONEN,
diacom.AUFTRAGSKOPF AUFTRAGSKOPF,
diacom.KUNDEN KUNDEN
WHERE AUFTPOSITIONEN.NUMMERAUFT = AUFTRAGSKOPF.NUMMERAUFT AND AUFTPOSITIONEN.NUMMERAUFTFO = AUFTRAGSKOPF.NUMMERAUFTFO AND AUFTPOSITIONEN.KUNDENNUMMER = KUNDEN.KUNDENNUMMER AND AUFTRAGSKOPF.KUNDENNUMMER = KUNDEN.KUNDENNUMMER
Moin Moelle,
die Umrechnungssyntax (Berechnung Datumswert aus "Julianischem Datumswert 2Mio-Irgendwas) lief bei mir gestern wie gepostet durch.
Testrechner -> XP Pro deu, Office 2002/2003 (Excel 2003 und Access 2003), Querytool habe ich nicht nachgeschaut-halt wie von Excel angezogen.
Nach Deiner Fehlermeldung wird bei Dir eine Date()-funktion erwartet, die mindestens einen Parameter (num./Date/Char) hat.
Probiere doch erstmal mit dem Querytool und einer Abfrage auf ein Datumsfeld der Access-MDB aus, welche Date()-Syntax er mag.
Welche Versionen hast Du denn im Test?
Grüße
Biber
die Umrechnungssyntax (Berechnung Datumswert aus "Julianischem Datumswert 2Mio-Irgendwas) lief bei mir gestern wie gepostet durch.
Testrechner -> XP Pro deu, Office 2002/2003 (Excel 2003 und Access 2003), Querytool habe ich nicht nachgeschaut-halt wie von Excel angezogen.
Nach Deiner Fehlermeldung wird bei Dir eine Date()-funktion erwartet, die mindestens einen Parameter (num./Date/Char) hat.
Probiere doch erstmal mit dem Querytool und einer Abfrage auf ein Datumsfeld der Access-MDB aus, welche Date()-Syntax er mag.
Welche Versionen hast Du denn im Test?
Grüße
Biber
Ich arbeite mit Office 2003. Im beiden Verfahren arbeite ich mit ODBC-Datenbanken die aus externen System (Warenwirtschaft) herangezogen werden. Der Nachteil beim Querytool aus Excel ist dir ja bekannt das einfach zu wenig Operaten zur Verfügung stehen.
Nochmal ne andere Frage an den Meister. Ist es möglich die ODBC Abfrage so zu lassen das er mir das FEld DATUMAUFLIEF als Julianisch zurückgibt und über ein Makro das in das Datumsformat dd.mm.yyyy darstellt ?????
Nochmal ne andere Frage an den Meister. Ist es möglich die ODBC Abfrage so zu lassen das er mir das FEld DATUMAUFLIEF als Julianisch zurückgibt und über ein Makro das in das Datumsformat dd.mm.yyyy darstellt ?????
Moin Moelle,
zu Deiner Zusatzfrage: ja, natürlich, wenn wir gar nichts Besseres gebacken bekommem, dann können wir natürlich die Access-Daten "as is" einlesen.
Und dann irgendwie per Makro oder Formel, aber eben in einem zusätzlichen Arbeitsschritt nachbereiten.
Das nimmt uns bloß den ganzen Charme der Flexibilität einer Ad-hoc-Abfrage über eine dieses Query-Tool.
Lass uns mal versuchen zu knacken, was "Dein" Access-ODBC-Treiber für eine DATE()-Funktion implementiert hat.
Das kann doch nicht ewig dauern oder unendliche Variationsmöglichkeiten beinhalten, mal eine Query gegen eine beliebige Access-MDB bzw. Tabelle mit einem Datumsfeld abzufeuern
Dort die naheliegenden Varianten "Select date("01.01.2008") as test1, date(4711) as test2, date(#01/01/2007#) as test3 FROM testmdb" durchnudeln und schauen, bei welchem Date()-Aufruf etwas sinnhaftes zurückkommt..
Wie heißt es in diesen typischen American Dream-Sprüchen immer: "Du bist näher dran als Du denkst."
Zurück auf Plan B oder Plan C können wir ja immer noch.
Grüße
Biber
zu Deiner Zusatzfrage: ja, natürlich, wenn wir gar nichts Besseres gebacken bekommem, dann können wir natürlich die Access-Daten "as is" einlesen.
Und dann irgendwie per Makro oder Formel, aber eben in einem zusätzlichen Arbeitsschritt nachbereiten.
Das nimmt uns bloß den ganzen Charme der Flexibilität einer Ad-hoc-Abfrage über eine dieses Query-Tool.
Lass uns mal versuchen zu knacken, was "Dein" Access-ODBC-Treiber für eine DATE()-Funktion implementiert hat.
Das kann doch nicht ewig dauern oder unendliche Variationsmöglichkeiten beinhalten, mal eine Query gegen eine beliebige Access-MDB bzw. Tabelle mit einem Datumsfeld abzufeuern
Dort die naheliegenden Varianten "Select date("01.01.2008") as test1, date(4711) as test2, date(#01/01/2007#) as test3 FROM testmdb" durchnudeln und schauen, bei welchem Date()-Aufruf etwas sinnhaftes zurückkommt..
Wie heißt es in diesen typischen American Dream-Sprüchen immer: "Du bist näher dran als Du denkst."
Zurück auf Plan B oder Plan C können wir ja immer noch.
Grüße
Biber
Vielleicht hilt dieses schon. Ich verwende den BASIS BBJ ODBC Treiber Version 6.2.1. Den Rest probiere ich gleich aus
