on a crash course in production sybase support. can you say fun? I knew you could.

Anyone think DECLARE @d DATE; SELECT ISDATE(@d); should just return 1 instead of an error?

(Well, I guess if it's NULL, return 0, and if not null, since it has to be a date by definition, return 1)

@AaronBertrand I suppose so. Does it return error?

> Argument data type date is invalid for argument 1 of isdate function.

I get why it isn't necessary but it also isn't necessary to support DATETIME - which works without error. (And when NULL, that returns 0.)

This inconsistency makes it harder for people to fix columns from string to new types, or from old date types to new ones

The msdn page has this line somewhere: The following table summarizes input expression formats that are not valid and that return 0 or an error.

and then a table with 5 cases, and all them supposed to return 0. No other mention of why and where an error should be thrown ...

Most unhelpful.

Would also be curious about the logic behind this:

> Date and time data types, except datetime and smalldatetime, are not allowed as the argument for ISDATE.

Date is bad, datetime is good? Nonsensical.

Turns out ISDATE doesn't recognise dates before 1753-01-01. So, there you are.

Well, they could fix ISDATE, too

I'm more troubled that the documentation doesn't really tell you which types will yield an error - that table makes it seem like it will just always return 0.