Hej!
Jag har problem med datum och tidshantering. Om jag bara vill visa ÅR eller ÅR/DATUM eller TIM/MIN osv. Hur hanterar jag detta?
Kan jag lägga in en CONSTRAIN som ger mig rätt formatering?

Tackar på förhand.

Fredrik

Det finns en funktion som heter DATEPART.

Ex. DATEPART(year, GETDATE()) - plockar ut år.
DATEPART(mi, GETDATE()) - plockar ut minut.


// Jarle

Hej,

och vill du veta mer om DATEPART leta upp sqlbol.chm som alltid medföljer vid
installtion. De gör iofs ingen direkt reklam för den, utan tror du får gå in i det
bibliotek där du installerat SQL Server och söka.

Finns även några andra bra datumkommandon... =)

/Emma

Det finns även YEAR(), MONTH() och DAY()-funktioner. Alternativt kan man använda CONVERT.

Tror dock han skulle använda det för att plocka ut en del av datum i ett datumfält i en tabell (eller jag går utifrån det :))

Ex. DATEPART(year, dateInserted), där dateInserted är en kolumn av typ datetime i tabellen.


// Jarle

Absolut, men lika bra fungerar YEAR(dateInserted) eller CONVERT(char(4), dateInserted, 120). Men visst, DATEPART är förmodligen det jag skulle använt med, bara visade några andra exempel.

Hejsan

Om du använder SQL Server 2000 kan du använda dig av följande user-defined function..

------
CREATE FUNCTION dbo.Dateformat
(
@Date datetime,
@Dateformat varchar(100)
)

RETURNS varchar(100)

AS

BEGIN
SET @Dateformat = REPLACE(@Dateformat, 'yyyy', DATEPART(yy, @Date))
SET @Dateformat = REPLACE(@Dateformat, 'yy', RIGHT(CONVERT(varchar(4), DATEPART(yy, @Date)),2))
SET @Dateformat = REPLACE(@Dateformat, 'mm', RIGHT(100 + DATEPART(mm, @Date), 2))
SET @Dateformat = REPLACE(@Dateformat, 'dd', RIGHT(100 + DATEPART(dd, @Date), 2))
SET @Dateformat = REPLACE(@Dateformat, 'hh', RIGHT(100 + DATEPART(hh, @Date), 2))
SET @Dateformat = REPLACE(@Dateformat, 'mi', RIGHT(100 + DATEPART(mi, @Date), 2))
SET @Dateformat = REPLACE(@Dateformat, 'ss', RIGHT(100 + DATEPART(ss, @Date), 2))

RETURN @Dateformat
END
------


Denna funktion byter ut dina datumdelar (yy, mm, mi osv) i strängen mot motsvarande värde från datumvaribeln..

Din SELECT-sats kan se ut på följande sätt..

SELECT dbo.Dateformat(getdate(), 'yyyy-mm-dd')

Fördelen är att den är väldigt lätt att få till datumformat för olika länder..
Nackdelen med denna funktion är att om du använder ADO och väljer att kör recRecordset.sort på datumkolumnen så kan den sortera fel genom att kolumnen är en sträng.. Då kan du, istället för att formatera datumet i SELECT-satsen, göra det vid presentationen med en motsvarande funktion i vb-script eller vb-kod..

Micke

Oj,oj,oj!
Tack för alla ideer och snabba svar.

Häsningar

Fredrik

<i></i>

Ojoj, så där ska man absolut _inte_ göra! Den funktion som presenteras i inlägget tar långt mycket mer prestanda än följande, vilket ger exakt samma resultat:

SELECT CONVERT(varchar(10), getdate(), 120)

Visst, funktionen stödjer lite andra saker också, men det kan åstadkommas med andra medel om så behövs.

Visst håller jag med om att den är prestanda krävande, men det är ju i relation hur många poster som ska presenteras.. När man börjar närmar sig tusentalet kan man börja diskutera om det är vettigt att loopa upp det tex websida eller listviewkontroll..

Just i det exempel som jag visade fanns det ett motsvarande för CONVERT men den räcker inte långt om man vill programmera multinationella siter där användarna själva kan bestämma om de vill visa sekunder när något är skapat (beroende på om det är relevant eller inte), visa endast datum/tid mm, utan att koda ihjäl sig..

Micke

Det handlar inte om hur många rader det påverkar, det är grundläggande fel att i det mängdbaserade 'språket' SQL hantera saker procedurellt eller rad-för-rad. För det första ville den som frågar här inte alls åstadkomma det man kan göra med funktionen du visade och därför är det enligt mig fel att visa honom en 'dålig' lösning. Dessutom kan man göra allt funktionen gör med standardfunktioner som CONVERT i SQL. Slutligen, om vad du vill göra är att låta användare på en website själv välja hur datum ska visas tycker jag man ska returnera dem som datum från databasen, och därefter i webbapplikationen formatera dem som man vill när mn skriver ut dem.

UDFer är något man ska vara mycket försiktig med i SQL, framförallt inline UDFer som returnerar ett skalärt värde. Dels är de nya i SQL Server och säkert inte fullt optimerade än, men framförallt så är de inte mängdbaserade och därmed kan en udf som gör precis samma sak som en vanlig systemfunktion (t ex convert) se ut att fungera bra när man testar den med ett enskilt värde, men när man använder den i en fråga som returnerar potentiellt massor av rader så kan det bli förödande konsekvenser för prestandan.

Håller inte riktigt med dig.. Att använda sig av subselecter eller udf:er i SELECT-satsen (rad för rad) är inte fel, det kan vara enda sättet att lösa ett problem. Sedan har det naturligtvis en stor inverkan på prestandan beroende hur många poster som returneras.. Några problem har jag aldrig haft med udf:er däremot har dom löst en massa problem.. Däremot håller jag med dig att det kanske inte var den bästa exemplet att använda för att lösa ursprungsproblemet i tråden.. Av erfarenhet försöker jag alltid att lägga logiken så långt bak som möjligt i lagren(db-vbcom-asp-xsl), dels för man vet aldrig vem eller vad som kommer att använda sig av systemet dels för att jag 'litar' mer på db och com miljö än script.. Ibland går inte det och du får man knuffa fram den ett steg..

Sedan skulle det vara kul om du kunde visa hur CONVERT funktionen skulle lösa samma funktionalitet som exemplet..

Micke

> Att använda sig av subselecter eller udf:er i SELECT-satsen (rad för rad) är inte fel, det kan vara enda sättet att lösa ett problem. Sedan har det naturligtvis en stor inverkan på prestandan beroende hur många poster som returneras.

Återigen, det har inget med hur många rader som returneras att göra, det handlar om att skriva kod på ett mängdbaserat (eng. set based) sätt. Subselects och udf-er har inget med varandra att göra (mer än att de kan användas till samma sak, nämligen att returnera ett skalärt värde eller ett rowset som kan användas som table source). Subselects är naturligtvis inget fel att använda.

> Några problem har jag aldrig haft med udf:er däremot har dom löst en massa problem.

Se ovan.

> Av erfarenhet försöker jag alltid att lägga logiken så långt bak som möjligt i lagren(db-vbcom-asp-xsl), dels för man vet aldrig vem eller vad som kommer att använda sig av systemet dels för att jag 'litar' mer på db och com miljö än script.

Visst, men man behöver inte använda saker till annat än vad de är till för. Presentation av data anser jag att man gör i presentationsskiktet, men visst, jag förstår tanken. Fortfarande anser jag dock att man bör försöka skriva det mängdbaserat.

> Sedan skulle det vara kul om du kunde visa hur CONVERT funktionen skulle lösa samma funktionalitet som exemplet.

Till att börja med så kan du ju med CONVERT ange flera olika stilar av datum, och i princip få ut alla varianter av datumformat man kan tänkas behöva. Visst, man kan inte få det i vilket oändligt format som helst, men jag har aldrig sett ett behov av något annat format än de man får med CONVERT. Sen skrev jag inte att CONVERT kunde göra allt funktionen kan, jag skrev att man kan göra det med bl a CONVERT, tillsammans med andra funktioner (t ex replace som du använder). Det viktiga i sammanhanget är återigen att jag inte använder kod som utförs rad-för-rad.