Viewing 15 posts - 57,481 through 57,495 (of 59,067 total)
Storing anything of that nature in tables is generally a bad idea... instead, store just the UNC (\\machinename\path\filename.ext) and pass that to the app... then let your app go get...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 4, 2006 at 6:31 am
You'll need to use UNC's instead of file/path. Example... \\Machinename\path
--Jeff Moden
Change is inevitable... Change for the better is not.
October 4, 2006 at 6:27 am
Didn't know that and you are correct... usually an ALTER TABLE ALTER COLUMN doesn't require that very long method the EM builds... it is, however, crash proof. So there's a...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 4, 2006 at 6:25 am
Not sure why you don't just let the tools do it for you... if you use EM to make the change, it will do everything for you... no fuss, no...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 4, 2006 at 5:08 am
You had an Assembler? Lucky you... Much of the code I wrote in the "good old days" was hand-assembled machine language... now THAT was fun ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
October 4, 2006 at 5:02 am
Looks like I'm not the only one that can't sleep... thanks, Prasad. ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
October 4, 2006 at 12:31 am
And they say understanding underlying data structures is no longer important... the '00' unicode country code in these examples sticks out like a sore thumb to anyone who has seen...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 3, 2006 at 10:04 pm
Conversions are a bit costly performance wise... the following works approximately 45% faster on a million row test...
SELECT DATEADD(dd,DATEDIFF(dd,0,GETDATE()),0)
--Jeff Moden
Change is inevitable... Change for the better is not.
October 3, 2006 at 9:57 pm
S'ok... I've been with SQL Server since it was 6.5 and I keep wondering when the next fault will occur ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
October 3, 2006 at 9:38 pm
I have got null values in the ' Practitioner_Enddate' column in my table and it is a datetime... |
--Jeff Moden
Change is inevitable... Change for the better is not.
October 3, 2006 at 8:52 pm
Outstanding... Thanks for the feedback, Michael. ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
October 3, 2006 at 8:15 pm
Then I think you need to take Serqiy's advice... he wasn't talking "Trojan Horse" as in "Virus"... he was talking about taking the easy way out with NVARCHAR(MAX) which is...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 3, 2006 at 8:10 pm
Sounds like you did your homework... glad it worked out.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 3, 2006 at 7:59 pm
Here's a simple one... the only problem with it is if a table name straddles an 8 k boundry... then it will miss the table name...
--Find name of...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 3, 2006 at 7:33 am
What do you mean when you say it "timed out"? What app are you in?
--Jeff Moden
Change is inevitable... Change for the better is not.
October 3, 2006 at 6:12 am
Viewing 15 posts - 57,481 through 57,495 (of 59,067 total)