Viewing 15 posts - 56,611 through 56,625 (of 59,086 total)
Yes like bnordberg said this is from a system generated log file. |
Then, the bottom line is, you probably...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2007 at 4:57 pm
High praise coming from the likes of you, Peter! Thank you and I know which "Script Library" you're talking about... I'll throw it in in the next day or two. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2007 at 4:50 pm
Thanks for the great feedback, David,
Couldn't believe the pickle someone put you into... had to do something to get you out of that mess ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
April 9, 2007 at 4:43 pm
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
Viewing 15 posts - 56,611 through 56,625 (of 59,086 total)