Viewing 15 posts - 56,626 through 56,640 (of 59,098 total)
You'll need to grant DDL Admin role privs those users.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2007 at 10:08 pm
Heh... of course if a "lossy" number was stored to begin with, the function will return that same "lossy" number which is what the requirement was... its a FLOAT, not...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2007 at 10:00 pm
...And, now that we've done all of that... I'll bet the damned thing will import using BCP with one of the "native" datatype identifiers... I'll have to try that out...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2007 at 5:16 pm
All right... here ya go... as I always say (in a "Yogi" Berra fashion), "Once ya figure it out, it's easy" ![]()
I haven't tried...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2007 at 5:04 pm
'Zactly where I'm headed...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2007 at 2:26 pm
Oh, hell yes! Got the spreadsheet doing it right... trying to convert it to an SQL function...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2007 at 1:26 pm
It does use an 11 bit mantisa... got the .15626 example and the even numbers through 10 (thinking thats a hint!) to work... THIS is a bugger! It would be...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2007 at 10:53 am
Well, for sure, SQL Server isn't following the IEEE-754 standard. If you visit the link David pointed out (nice link, by the way... setup a spreadsheet to do all that),...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 8, 2007 at 9:37 am
Actually, there is an ISNUMERIC function (I think... there was one in 2k... did they get rid of it?)
And, actually, you would never want to use it as an ISALLDIGITS...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2007 at 8:00 pm
Hey, have a Happy Easter. Hope you and yours are doing fine!
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2007 at 11:57 am
Here's the test code I used John... both tables have a composite clustered index on SomeID and SomeNumber...
CREATE VIEW vBIGTEST AS
SELECT *
FROM BigTest
UNION ALL
SELECT *
FROM BigTest2
PRINT REPLICATE('-',78)
SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2007 at 9:14 am
Ah! Sorry and understood... guess that's one of the advantages of partitioned pass through views.
Not sure what the problem with the view is... I just created two small 200k row tables with...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2007 at 9:07 am
Heh... "Employe" is a "short timer"
Had to leave something for him to troubleshoot ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2007 at 8:32 am
Oh yeah... I like the ROW_Number thing, especially. Haven't had the pleasure of using it in 2k5 but have done some cool things with it in (yeech) Oracle.
On the time...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 7, 2007 at 12:00 am
Whew! Thought I had a "senior moment" or something. Thanks for the feed back.
I used the date comparisons I did because I didn't know if times were involved nor whether...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 6, 2007 at 10:27 pm
Viewing 15 posts - 56,626 through 56,640 (of 59,098 total)