Viewing 15 posts - 16 through 30 (of 90 total)
I thought those three utilities were deprecated in SQL 2008. They don't seem to exist in SQL 2012. *confused*
February 22, 2013 at 3:33 am
hehe... Good question. I remember experiencing this one while trying to help someone with the file last summer. 🙂 Good times.
February 8, 2013 at 2:56 am
I kept looking for a trick... something that wouldn't depend on the data itself that wasn't presented.
January 28, 2013 at 5:41 am
Given the data available, I fell back to the ol' standby answer of N'It depends,' and translated that into the available answer. 🙂
January 24, 2013 at 7:56 am
Thank you Hugo.
(At least it wasn't something obvious I just wasn't seeing.)
December 14, 2012 at 8:50 am
Great question.
But, okay... I give up, how does having an indexed view cause a loss of precision?
(I.e. Yep, I see the error. I don't understand WHY. 🙁 )
December 14, 2012 at 6:59 am
*blush* Being wrong is teaching me even more about collations.
I'm also seeing another possible advantage to unicode. Switching to unicode, it looks like NCHAR(198) and NCHAR(230) returns the...
December 3, 2012 at 11:40 am
On my server it returns 0 rows, so it appears like some other things affect this. Maybe default collation. Probably.
I'd suspect a different set of Extended ASCII characters, probably not...
December 3, 2012 at 9:13 am
I got it wrong, but have been playing with the query. If I switch from char(1) values to nchar(1) and search 65535 values, it spits out six values:
Æ198
æ230
?482
?483
?508
?509
---
I don't...
December 3, 2012 at 6:36 am
Brilliant! Thanks for the question! I believe it's a great question that draws out some discussion.
A big thank you to Carlo and Hugo who provided a more succinct...
October 29, 2012 at 5:53 am
And for anyone looking forward to SQL 2012, this is probably a good opportunity to mention that folks might want to look at the SEQUENCE objects.
October 11, 2012 at 12:14 pm
Viewing 15 posts - 16 through 30 (of 90 total)