|
|
Posted by Tony Rogerson on 05/06/06 01:29
Make sure @x is nvarchar then, because thats what ISDATE takes.
> But integer data for dates is so much messier to deal with, not the
> least for the client.
I totally agree, but its more messy have the time component on queries in my
experience.
Having said that i always convert the integer to a smalldatetime when
creating a fact table purely because its easier for the time dimension on my
dimensional model.....
--
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials
"Erland Sommarskog" <esquel@sommarskog.se> wrote in message
news:Xns97BAED6B51AAAYazorman@127.0.0.1...
> Tony Rogerson (tonyrogerson@sqlserverfaq.com) writes:
>> I've not mentioned the space issue - 4 bytes ve 8 bytes which can amount
>> to a lot more IO for larger trading systems.....
>
> So that is an argument that carries some weight.
>
> But integer data for dates is so much messier to deal with, not the
> least for the client.
>
>> check( ISDATE( 20060230 ) = 1 ) which is simpler then the check
>> constraint needed for slicing off / checking for the time component!
>
> Nah, I would write it as
>
> CREATE RULE aba_date_rule (isdate(ltrim(str(@x))) = 1
>
> I hate to rely on implicit conversions from integer to string.
>
> (And it is a rule, as I only want it one place.)
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
>
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Navigation:
[Reply to this message]
|