12
SQL-Server 2008 R2 FORMAT-Funktion : Fehler bei Erstellen einer Sicht im MS SQL-Server Management Studio
Hallo zusammen,
eigentlich sieht der Befehl
SELECT format(KalDat, yyyy) AS dat, KalDat_Kat, KalDat_KatDescript
FROM dbo.T_KALDAT
oder
SELECT format(KalDat, "yyyy") AS dat, KalDat_Kat, KalDat_KatDescript
FROM dbo.T_KALDAT
doch richtig aus. Egal wie ich es mache, erhalte ich stets die Fehlermeldung
" 'format' wird nicht als Name einer integrierten Funktion erkannt."
Ich versuche, eine Sicht in MS SQL-Server Management Studio zu erstellen. Statt "yyyy" kann ich natürlich auch "Short Date" oder so etwas setzen. Das ist ja alles dokumentiert. Bloss: es funktioniert -zumindest auf diesem Server- nicht.
Hat jemand einen Tipp ?
eigentlich sieht der Befehl
SELECT format(KalDat, yyyy) AS dat, KalDat_Kat, KalDat_KatDescript
FROM dbo.T_KALDAT
oder
SELECT format(KalDat, "yyyy") AS dat, KalDat_Kat, KalDat_KatDescript
FROM dbo.T_KALDAT
doch richtig aus. Egal wie ich es mache, erhalte ich stets die Fehlermeldung
" 'format' wird nicht als Name einer integrierten Funktion erkannt."
Ich versuche, eine Sicht in MS SQL-Server Management Studio zu erstellen. Statt "yyyy" kann ich natürlich auch "Short Date" oder so etwas setzen. Das ist ja alles dokumentiert. Bloss: es funktioniert -zumindest auf diesem Server- nicht.
Hat jemand einen Tipp ?
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: 337060
Url: https://administrator.de/contentid/337060
Printed on: April 25, 2024 at 13:04 o'clock
12 Comments
Latest comment
Guten Morgen,
laut der Beschreibung aus der MSDN gibt es die Funktion "Format()" erst ab SQL Server 2012.
Mit SQL Server 2008 kannst du die Funktion "Year()" nutzen:
laut der Beschreibung aus der MSDN gibt es die Funktion "Format()" erst ab SQL Server 2012.
Mit SQL Server 2008 kannst du die Funktion "Year()" nutzen:
select year(KalDat) as dat ... 
Moin ! Vielen Dank. Das ist natürlich etwas mistig. Aber tatsächlich ist natürlich immer die Frage, welche im Grunde existenten SQL-Statements auf den verschiedenen Systemen implementiert bzw. zulässig sind.
Seither haben wir inhouse meist unter ACCESS Frontend auf den SQL-Server zugegriffen und ACCESS kennt den format und $format natürlich schon seit mindestens ACCESS 97.
Jetzt aber hatte ich den Versuch unternommen, einmal den Kalender via aspx-Website darzustellen und habe als Darstellungsergebnis
2000-07-01 00:00:00.000
erhalten und möchte das natürlich als ordentliches Datum darstellen:
2000-07-01 oder besser 01.07.2017, aber natürlich sortierfähig. Das kann man natürlich auf der zugreifenden Seite machen, aber da wird es kompliziert. So dachte ich, die Umwandlung auf dem Server per view vorzunehmen. Das Statement
SELECT TOP (100) PERCENT KalDat AS dat, KalDat_Kat AS kat, KalDat_KatDescript AS descr, YEAR(KalDat) AS jahr, MONTH(KalDat) AS mon, DAY(KalDat) AS tag
FROM dbo.T_KALDAT
WHERE (KalDat < GETDATE())
ORDER BY dat DESC
führt immerhin zu
yyyy mm dd
2017-05-07 00:00:00.000 S Sonntag 2017 5 7
aber eben in getrennten Spalten und es gelang zumindest nicht auf Anhieb, das irgendwie zusammen zu bauen nach dem Muster
YEAR(KalDat) & "-" & MONTH(KalDat) & "-" & DAY(KalDat)
Dennoch: Lösung besser als vorher.
Zu einem Termin gehört allerdings neben dem Datum eben auch die Uhrzeit = Stunden : Minuten. Historisch sind in unseren Datenbanken Termine immer in zwei Spalten abgelegt; eine für's Datum und die zweite für die Uhrzeit des Termins. Die Darstellung ist inhouse via ACCESS, EXCEL etc. mit den dortigen Formatierungsmöglichkeiten ja nie ein Problem.
Bloss die Darstellung in der aspx-Seite mit ListView etwa macht aus der Uhrzeit 18:00 den ListWert
30.12.1899 18:00:00 .... was natürlich wenig hübsch ist, wobei strenggenommen 00.00.0000 18:00:00 korrekter wäre, denn wir haben in der Uhrzeit ja kein Datum hinterlegt.
Dennoch: die Funktion "Stunde" und "Minute" scheint zu fehlen und so habe ich es mit DatePart versucht. Das läuft aber gar nicht. Laut MSDN wäre die allgemeine Syntax DATEPART ( datepart , date ), was mich etwas verwundert, weil date hinten steht. Aber gut: bezogen auf das Beispiel liefern Versuche mit
DATEPART ( yyyy , kaldat ) AS val1 (testweise noch mal mit dem Jahr versucht)
DATEPART (yyyy , kaldat)
DATEPART ("yyyy" , kaldat)
oder
DATEPART (hh , kaldat) (mit der Stunde probiert)
DATEPART ("hh" , kaldat)
jedenfalls nur Fehler.
Eine Idee ? Mein Job ist zwar die Modellierung von DB's und nicht die Ausprogrammierung, aber so ein bisschen "Keep in touch" mit der Programmierung sollte schon sein und so etwas ärgert mich. Zudem: wenn sich -mit Blick auf vielleicht kommende WEB-Programmierung- herausstellt, dass solche Probleme schon beim Anzeigen von Daten bestehen -ans Schreiben noch gar nicht zu denken- muß man in diesem Zusammenhang schon auch die Modellierung bzw. Festlegung der Datentypen auf den Prüfstand stellen.
Gruss !
Seither haben wir inhouse meist unter ACCESS Frontend auf den SQL-Server zugegriffen und ACCESS kennt den format und $format natürlich schon seit mindestens ACCESS 97.
Jetzt aber hatte ich den Versuch unternommen, einmal den Kalender via aspx-Website darzustellen und habe als Darstellungsergebnis
2000-07-01 00:00:00.000
erhalten und möchte das natürlich als ordentliches Datum darstellen:
2000-07-01 oder besser 01.07.2017, aber natürlich sortierfähig. Das kann man natürlich auf der zugreifenden Seite machen, aber da wird es kompliziert. So dachte ich, die Umwandlung auf dem Server per view vorzunehmen. Das Statement
SELECT TOP (100) PERCENT KalDat AS dat, KalDat_Kat AS kat, KalDat_KatDescript AS descr, YEAR(KalDat) AS jahr, MONTH(KalDat) AS mon, DAY(KalDat) AS tag
FROM dbo.T_KALDAT
WHERE (KalDat < GETDATE())
ORDER BY dat DESC
führt immerhin zu
yyyy mm dd
2017-05-07 00:00:00.000 S Sonntag 2017 5 7
aber eben in getrennten Spalten und es gelang zumindest nicht auf Anhieb, das irgendwie zusammen zu bauen nach dem Muster
YEAR(KalDat) & "-" & MONTH(KalDat) & "-" & DAY(KalDat)
Dennoch: Lösung besser als vorher.
Zu einem Termin gehört allerdings neben dem Datum eben auch die Uhrzeit = Stunden : Minuten. Historisch sind in unseren Datenbanken Termine immer in zwei Spalten abgelegt; eine für's Datum und die zweite für die Uhrzeit des Termins. Die Darstellung ist inhouse via ACCESS, EXCEL etc. mit den dortigen Formatierungsmöglichkeiten ja nie ein Problem.
Bloss die Darstellung in der aspx-Seite mit ListView etwa macht aus der Uhrzeit 18:00 den ListWert
30.12.1899 18:00:00 .... was natürlich wenig hübsch ist, wobei strenggenommen 00.00.0000 18:00:00 korrekter wäre, denn wir haben in der Uhrzeit ja kein Datum hinterlegt.
Dennoch: die Funktion "Stunde" und "Minute" scheint zu fehlen und so habe ich es mit DatePart versucht. Das läuft aber gar nicht. Laut MSDN wäre die allgemeine Syntax DATEPART ( datepart , date ), was mich etwas verwundert, weil date hinten steht. Aber gut: bezogen auf das Beispiel liefern Versuche mit
DATEPART ( yyyy , kaldat ) AS val1 (testweise noch mal mit dem Jahr versucht)
DATEPART (yyyy , kaldat)
DATEPART ("yyyy" , kaldat)
oder
DATEPART (hh , kaldat) (mit der Stunde probiert)
DATEPART ("hh" , kaldat)
jedenfalls nur Fehler.
Eine Idee ? Mein Job ist zwar die Modellierung von DB's und nicht die Ausprogrammierung, aber so ein bisschen "Keep in touch" mit der Programmierung sollte schon sein und so etwas ärgert mich. Zudem: wenn sich -mit Blick auf vielleicht kommende WEB-Programmierung- herausstellt, dass solche Probleme schon beim Anzeigen von Daten bestehen -ans Schreiben noch gar nicht zu denken- muß man in diesem Zusammenhang schon auch die Modellierung bzw. Festlegung der Datentypen auf den Prüfstand stellen.
Gruss !
Nachtrag: auf
https://technet.microsoft.com/de-de/library/ee634813(v=sql.105).aspx
ist allerdings explizit die FORMAT-Funktion für den SQL-Server 2008 R2 ausgewiesen; (nicht erst am 2012). Danach hatte ich mich gerichtet.
Gruss!
https://technet.microsoft.com/de-de/library/ee634813(v=sql.105).aspx
ist allerdings explizit die FORMAT-Funktion für den SQL-Server 2008 R2 ausgewiesen; (nicht erst am 2012). Danach hatte ich mich gerichtet.
Gruss!
In der Doku geht es im PowerPivot bzw. DAX. Die stehen dir u.a. in den Analysis Services des MS SQL Servers (SSAS) zur Verfügung, aber nicht im Umfeld der "normalen" SQL-Abfragen.
Moin,
hast du es mal mit dem CONVERT-Statement versucht?
Edit:
so sähe es aus (getestet mit MS SQL 2008R2 Express)
Ergbnis sieht dann vom Format TT.MM.YYYY aus
somit würdest du allerdings ein vollständiges Datumsfeld erhalten, wenn du nur einzelne Bestandteile haben willst, wurde oben ja bereits DATEPART genannt.
Gruß
em-pie
hast du es mal mit dem CONVERT-Statement versucht?
Edit:
so sähe es aus (getestet mit MS SQL 2008R2 Express)
CONVERT(VARCHAR([länge des Date/ timestamp Feldes]),[Feldname],104)Ergbnis sieht dann vom Format TT.MM.YYYY aus
somit würdest du allerdings ein vollständiges Datumsfeld erhalten, wenn du nur einzelne Bestandteile haben willst, wurde oben ja bereits DATEPART genannt.
Gruß
em-pie
Hallo em-pie,
vielen Dank ! Habe eben nochmal getestet nach Deinen Vorgaben. Bezogen auf das Datumsfeld "kaldat"
CONVERT(VARCHAR([länge des Date/ timestamp Feldes]),[Feldname],104)
kaldat = 2017-05-08 00:00:00.000 => Länge = 23
=>
CONVERT(VARCHAR(23),kaldat,104)
==> Fehler: "ungültiger oder fehlender Ausdruck" schon beim Verlassen des Eingabefeldes
Habe Beispiele gefunden auf https://www.w3schools.com/sql/func_convert.asp
Example
The following script uses the CONVERT() function to display different formats. We will use the GETDATE() function to get the current date/time:
CONVERT(VARCHAR(19),GETDATE())
CONVERT(VARCHAR(10),GETDATE(),10)
CONVERT(VARCHAR(10),GETDATE(),110)
CONVERT(VARCHAR(11),GETDATE(),6)
CONVERT(VARCHAR(11),GETDATE(),106)
CONVERT(VARCHAR(24),GETDATE(),113)
The result would look something like this:
Nov 04 2014 11:45 PM
11-04-14
11-04-2014
04 Nov 14
04 Nov 2014
04 Nov 2014 11:45:34:243
(die Länge bezieht sich demnach eher auf das, was man erhalten möchte statt auf die Länge des Feldes ?
Wenn man Zeichen mit Leerstellen zählt, stimt da irgendwie gar nichts. (?))
=> Die Beispiele sollten aber direkt laufen, denke ich.
=> Aber Fehlanzeige: Fehler: siehe oben
Der Server ist wie gesagt ein SQL-Server 2008 R2 Enterprise
Bin jetzt etwas ratlos.
Hübsches Bild übrigens, sieht man hier eher selten. Kommt "em-pie" von "empirisch" oder von E * m * pi (statt E * m * c^2) ?
Gruss
(ne, ich heiße nicht Walter. .-)
vielen Dank ! Habe eben nochmal getestet nach Deinen Vorgaben. Bezogen auf das Datumsfeld "kaldat"
CONVERT(VARCHAR([länge des Date/ timestamp Feldes]),[Feldname],104)
kaldat = 2017-05-08 00:00:00.000 => Länge = 23
=>
CONVERT(VARCHAR(23),kaldat,104)
==> Fehler: "ungültiger oder fehlender Ausdruck" schon beim Verlassen des Eingabefeldes
Habe Beispiele gefunden auf https://www.w3schools.com/sql/func_convert.asp
Example
The following script uses the CONVERT() function to display different formats. We will use the GETDATE() function to get the current date/time:
CONVERT(VARCHAR(19),GETDATE())
CONVERT(VARCHAR(10),GETDATE(),10)
CONVERT(VARCHAR(10),GETDATE(),110)
CONVERT(VARCHAR(11),GETDATE(),6)
CONVERT(VARCHAR(11),GETDATE(),106)
CONVERT(VARCHAR(24),GETDATE(),113)
The result would look something like this:
Nov 04 2014 11:45 PM
11-04-14
11-04-2014
04 Nov 14
04 Nov 2014
04 Nov 2014 11:45:34:243
(die Länge bezieht sich demnach eher auf das, was man erhalten möchte statt auf die Länge des Feldes ?
Wenn man Zeichen mit Leerstellen zählt, stimt da irgendwie gar nichts. (?))
=> Die Beispiele sollten aber direkt laufen, denke ich.
=> Aber Fehlanzeige: Fehler: siehe oben
Der Server ist wie gesagt ein SQL-Server 2008 R2 Enterprise
Bin jetzt etwas ratlos.
Hübsches Bild übrigens, sieht man hier eher selten. Kommt "em-pie" von "empirisch" oder von E * m * pi (statt E * m * c^2) ?
Gruss
(ne, ich heiße nicht Walter. .-)
Guten Morgen,
ich habe im Moment keinen 2008er Server zur Verfügung, kann es daher nicht direkt testen - aber zur Sicherheit:
Du rufst den Befehlt über das SQL Server Management Studio in einer Abfrage auf?
Diese Abfrage funktioniert bei mir (SQL Server 2014 Express):
Ohne SELECT geht es nicht:
produziert einen Fehler.
ich habe im Moment keinen 2008er Server zur Verfügung, kann es daher nicht direkt testen - aber zur Sicherheit:
Du rufst den Befehlt über das SQL Server Management Studio in einer Abfrage auf?
Diese Abfrage funktioniert bei mir (SQL Server 2014 Express):
select convert(varchar(10), getdate(), 10)Ohne SELECT geht es nicht:
convert(varchar(10), getdate(), 10)
Moin,
wie Tsocin anmerkte, muss es natürlich vollständig wie folgt lauten:
Ich habe es mit einem timestamp-Feld (Länge 23) getestet und es ist wie gewollt angezeigt worden: DD.MM.YYYY
[OT]
em-pie sind die Initialen meines Namens: M. P.
Und das auf dem Foto bin nicht ich, würde sonst geringfügig mein Geschlecht verfehlen
wie Tsocin anmerkte, muss es natürlich vollständig wie folgt lauten:
SELECT
CONVERT(VARCHAR(23),kaldat,104)
FROM
dbo.T_KALDATIch habe es mit einem timestamp-Feld (Länge 23) getestet und es ist wie gewollt angezeigt worden: DD.MM.YYYY
[OT]
Hübsches Bild übrigens, sieht man hier eher selten. Kommt "em-pie" von "empirisch" oder von E * m * pi (statt E * m * c^2) ?
zu kompliziert gedacht em-pie sind die Initialen meines Namens: M. P.
Und das auf dem Foto bin nicht ich, würde sonst geringfügig mein Geschlecht verfehlen
Die Länge bezieht sich auf die Anzahl an Zeichen die man haben will, um also den Zeitanteil weg zu lassen nimmst du nur 10 Zeichen und nicht 23.
Allerdings kann es sein das die Option 104 als Stil unterhalb von SQL 2012 nur tt.mm.jj und nicht tt.mm.jjjj zurück gibt, da bin ich mir nicht sicher.
https://msdn.microsoft.com/de-de/library/ms187928(v=sql.90).aspx
Allerdings kann es sein das die Option 104 als Stil unterhalb von SQL 2012 nur tt.mm.jj und nicht tt.mm.jjjj zurück gibt, da bin ich mir nicht sicher.
https://msdn.microsoft.com/de-de/library/ms187928(v=sql.90).aspx
Die Länge bezieht sich auf die Anzahl an Zeichen die man haben will, um also den Zeitanteil weg zu lassen nimmst du nur 10 Zeichen und nicht 23.
Auch gut ^^Allerdings kann es sein das die Option 104 als Stil unterhalb von SQL 2012 nur tt.mm.jj und nicht tt.mm.jjjj zurück gibt, da bin ich mir nicht sicher.
https://msdn.microsoft.com/de-de/library/ms187928(v=sql.90).aspx
https://msdn.microsoft.com/de-de/library/ms187928(v=sql.90).aspx
Nepp, habe - wie gesagt - obigen Code (mit der 104) an einem SQL 2008R2 Express erfolgreich getestet. Ergebnis ist DD.MM.YYYY gewesen
Moin alle zusammen !
Um das Mißverständnis abzustellen: klar; das Statement muß natürlich mit select beginnen. Ich greife mit SQL Server Management Studio zu und zwar mit der Version, die bei der Vollinstallation des Produkts MSSQL Server 2008 R2 Enterprise automatisch installiert wird; das müsste also passen.
Grundsätzlich funktioniert das Ganze im Editorfenster ja so, dass man (a) entweder im SQL-Bereich das SQL-Statement direkt eingeben kann oder (b) im Entwurfsbereich weiter oben Code für jweils ein auszugebendes Feld in die Spalte ganz links eingeben kann; der Parser übernimmt diese Eingabe dann automatisch in den SQL-Codebereich. Ich habe Methode b verwendet.
-
Und jetzt, Leute, kommt der Hammer: ich habe gerade mit meinem Programmierer gesprochen und folgendes herausgefunden:
Der Parser liefert bzw. versucht eine falsche Übersetzung; er hat Probleme mit KOMMA und SEMIKOLON:
Wenn der korrekte Befehl datepart(year,getdate()) lautet und ich diesen im Entwurfsfenster eingebe, kommt es zu einem Fehler; der Code wird gar nicht erst nicht angenommen bzw. nicht in den SQL-Code übertragen. (Bitte achtet auf das ",".)
Gebe ich jedoch (FALSCH) im Editorbereich datepart(year;getdate()) mit KOMMA ein, dann übersett das der Parser korrekt im SQL-Codefenster mit datepart(year,getdate()); er macht also aus dem falschen ";" ein korrektes ",".
Funktionen wie YEAR benötigen keine Parameter und demzufolge tritt diese KOMMA / SEMIKOLON - Problemaik natürlich nicht auf.
=> In diesem Editor-Fenster mußte also was Falsches eingeben, damit unten im SQL-Codebereich was Richtiges rauskommt und damit vergeudet MS einmal mehr unsere Zeit !! Jetzt läuft natürlich auch datepart usw.
Es hat schon seinen Grund, warum ich den Nic MeinGottWalter gewählt habe.
Gruss an Euch alle.
Um das Mißverständnis abzustellen: klar; das Statement muß natürlich mit select beginnen. Ich greife mit SQL Server Management Studio zu und zwar mit der Version, die bei der Vollinstallation des Produkts MSSQL Server 2008 R2 Enterprise automatisch installiert wird; das müsste also passen.
Grundsätzlich funktioniert das Ganze im Editorfenster ja so, dass man (a) entweder im SQL-Bereich das SQL-Statement direkt eingeben kann oder (b) im Entwurfsbereich weiter oben Code für jweils ein auszugebendes Feld in die Spalte ganz links eingeben kann; der Parser übernimmt diese Eingabe dann automatisch in den SQL-Codebereich. Ich habe Methode b verwendet.
-
Und jetzt, Leute, kommt der Hammer: ich habe gerade mit meinem Programmierer gesprochen und folgendes herausgefunden:
Der Parser liefert bzw. versucht eine falsche Übersetzung; er hat Probleme mit KOMMA und SEMIKOLON:
Wenn der korrekte Befehl datepart(year,getdate()) lautet und ich diesen im Entwurfsfenster eingebe, kommt es zu einem Fehler; der Code wird gar nicht erst nicht angenommen bzw. nicht in den SQL-Code übertragen. (Bitte achtet auf das ",".)
Gebe ich jedoch (FALSCH) im Editorbereich datepart(year;getdate()) mit KOMMA ein, dann übersett das der Parser korrekt im SQL-Codefenster mit datepart(year,getdate()); er macht also aus dem falschen ";" ein korrektes ",".
Funktionen wie YEAR benötigen keine Parameter und demzufolge tritt diese KOMMA / SEMIKOLON - Problemaik natürlich nicht auf.
=> In diesem Editor-Fenster mußte also was Falsches eingeben, damit unten im SQL-Codebereich was Richtiges rauskommt und damit vergeudet MS einmal mehr unsere Zeit !! Jetzt läuft natürlich auch datepart usw.
Es hat schon seinen Grund, warum ich den Nic MeinGottWalter gewählt habe.
Gruss an Euch alle.
Nachtrag: sorry, hatte mich gerade an einer Stelle verschrieben:
Statt "Gebe ich jedoch (FALSCH) im Editorbereich datepart(year;getdate()) mit KOMMA ein, ..." muss es natürlich lauten "Gebe ich jedoch (FALSCH) im Editorbereich datepart(year;getdate()) mit SEMIKOLON ein, ..."
Gruss.
Statt "Gebe ich jedoch (FALSCH) im Editorbereich datepart(year;getdate()) mit KOMMA ein, ..." muss es natürlich lauten "Gebe ich jedoch (FALSCH) im Editorbereich datepart(year;getdate()) mit SEMIKOLON ein, ..."
Gruss.
