[SQL server/SQL]Tijd van DATETIME afhalen

[TheNameless]

IK heb hier een query:

code:

SELECT ScanEnd, Sum(TotalImages) AS Totaal 
FROM tblBatches 
WHERE Status = 7 
AND ScanEnd > CONVERT(DATETIME,'08-25-2003',101) 
AND ScanEnd < CONVERT(DATETIME,'10-16-2003',101) 
AND ProjectID <>'' 
GROUP BY ScanEnd

Deze levert dus DATETIME objecten af met de aanwezige tijd. Maar ik wil dat query alleen de datum ervan afgeeft. Ook is het de bedoeling dat hij hierop groepeerd.

Ik heb al de DATEPART functie geprobeerd maar dat werkt ook niet. Hier op GoT heb ik ook niets kunnen vinden.

Iemand een id?

[whoami]

Misschien heb je hier wat aan.

Ik zit een beetje met hetzelfde probleem, maar ik hoop toch om een mooiere oplossing te vinden. Een DateTime wordt in SQL Server opgeslagen als 2 integers: 1 voor het datum-gedeelte en 1 voor het tijd-gedeelte. Daarom denk ik toch dat er op 1 of andere manier een andere (mooiere) oplossing moet zijn.

[whoami]

Ik geloof dat dit artikel ook wel eens best interessant zou kunnen zijn.

[kenneth]

Ik doe het meestal zo:

SQL:

SELECT ScanEnd, Sum(TotalImages) AS Totaal 
FROM tblBatches 
WHERE Status = 7 
AND CONVERT(varchar, ScanEnd, 112) BETWEEN '20030825' AND '20031015'
AND ProjectID <>'' 
GROUP BY ScanEnd

Daarbij is BETWEEN natuurlijk erg handig

[ Voor 10% gewijzigd door kenneth op 30-10-2003 15:54 ]

[TheNameless]

Ok het is al opgelost. Bedankt whoami voor de links. Alle dingen die daar stonden werkte.

Ik heb het nu zo:

code:

SELECT CAST(FLOOR(CAST(ScanEnd AS FLOAT))AS DATETIME), Sum(TotalImages) AS Totaal 
FROM tblBatches 
WHERE Status = 7 
AND ScanEnd > CONVERT(DATETIME,'08-25-2003',101) 
AND ScanEnd < CONVERT(DATETIME,'10-16-2003',101) 
AND ProjectID <>'' 
GROUP BY CAST(FLOOR(CAST(ScanEnd AS FLOAT))AS DATETIME)

@kenneth je oplossing werkte niet. Ik kreeg nog steeds alle tijden mee. Zowel:

code:

SELECT CONVERT(varchar, ScanEnd, 112), Sum(TotalImages) AS Totaal 
FROM tblBatches 
WHERE Status = 7 
AND CONVERT(varchar, ScanEnd, 112) BETWEEN '20030825' AND '20031015'
AND ProjectID <>'' 
GROUP BY CONVERT(varchar, ScanEnd, 112)

[ Voor 25% gewijzigd door TheNameless op 30-10-2003 16:01 . Reden: toevoeging ]

[kenneth]

Oh, het ging om de recordset, ik dacht om de vergelijking. Niet goed gelezen

Edit:
Je kan idd ook gewoon naar varchar converteren. Mocht je het dan alsnog als een echte datum willen hebben, dan doe ik altijd:

code:

CAST(CONVERT(varchar, jeDatumVeld, 102) AS DATETIME)

[ Voor 55% gewijzigd door kenneth op 30-10-2003 16:06 ]

[whoami]

Misschien toch nog iets dat het vermelden waard is, bij het gebruiken van convert/cast/floor functies in de where clausule:

f you are searching large tables with lots of records, you will most likely index some of the date columns that are commonly used to constrain queries. When a date column is used in a where clause, the query optimizer will not use an index if the date column is wrapped in a function. In addition, using the LIKE clause to search for particular records will keep the query optimizer from using an index thus slowing down how long it takes SQL Server to complete your query.

[SuperRembo]

kenneth schreef op 30 oktober 2003 @ 16:05:
Je kan idd ook gewoon naar varchar converteren. Mocht je het dan alsnog als een echte datum willen hebben, dan doe ik altijd:

Naar int converteren en dan weer terug naar datetime werkt ook. Misschien dat dat qua performance nog wat uit maakt, maar dat heb ik (nog) niet uitgeprobeerd.

[EfBe]

al gekeken naar YEAR(), MONTH() en DAY() ?

[whoami]

EfBe schreef op 30 oktober 2003 @ 21:28:
al gekeken naar YEAR(), MONTH() en DAY() ?

't Lijkt me dat dat ook niet echt een goeie optie is als je wilt selecteren op een bepaalde datum.
Als je YEAR(), MONTH() en DAY() gaat gaan gebruiken in je WHERE clause, dan zal de database de indexen die je op de datum-column gelegd hebt, niet gaan gebruiken.

[EfBe]

Het lijkt me dat de indexen op een datum met tijd te maken hebben ook en daarmee kansloos zijn. (speculatie).

Niet voor niets heeft Yukon een nieuw type 'date', met alleen datum, geen tijd.

[whoami]

EfBe schreef op 30 oktober 2003 @ 22:24:
Het lijkt me dat de indexen op een datum met tijd te maken hebben ook en daarmee kansloos zijn. (speculatie).

Dat denk ik niet.
Door het opnemen van de tijd zal de index zowiezo uniek genoeg zijn om gebruikt te worden.
Daarnaast zal er toch wel een index gebruikt worden als je zoekt mbhv < , > en = operatoren. Een datum-veld is eigenlijk een goeie kandidaat om een clustered index op te leggen.

Niet voor niets heeft Yukon een nieuw type 'date', met alleen datum, geen tijd.

Interessant, dat zal al heel wat gekloot verhelpen.