Viewing 15 posts - 55,111 through 55,125 (of 59,098 total)
Thanks Remi!
--Jeff Moden
Change is inevitable... Change for the better is not.
September 11, 2007 at 5:51 pm
Lookup "IF" in Books Online ("Transact-SQL HELP" in Query Analyzer) to find more about the following example (also from Books Online)...
IF (@ErrorSaveVariable <> 0)BEGIN PRINT 'Errors encountered, rolling...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 11, 2007 at 7:27 am
No, I understood that... but typically there is some unique key (column or combination of columns) other than the GUID that would identify the unique row. Need that info to do...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 11, 2007 at 7:20 am
Heh... if that's what he meant by decimal... Me? Guess it's obvious that I don't normally do those kinds of conversions, huh? ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2007 at 9:36 pm
But, doing it that way, it can't be turned back into an IP address, can it? And, theoretically, couldn't there be dupes that way? After all, the OP did say...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2007 at 9:34 pm
Ah... got it... had to go back and look... Serqiy is correct and I'll throw in that you may not ever want to pass date serial numbers between products... Best...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2007 at 9:29 pm
Yep... accidental cross join... tell me where the join criteria is for the "sy" table alias...
SELECT D1.stu_sid, D1.stu_id, Min(D1.Entry_Date) as Entry_Date, Case MAX(D2.Exit_Date) When '01/01/2900' then null Else MAX(D2.Exit_Date) end ...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2007 at 6:15 pm
Ummm... I gotta agree with that... tampering with server settings without knowing the full ramifications of each setting is nearly certain death for the server. I'd get some qualified help...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2007 at 6:03 pm
It was a spoof, David...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2007 at 5:56 pm
Cool Kurt... wanna share your SQL code on this? ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2007 at 5:37 pm
You really need to look at a good calendar for the year 2002...
2002-05-03 is a Friday... count 1 day
There are 4 full weeks after that up to 2005-05-31... count...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2007 at 5:36 pm
My pleasure... thank you for the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2007 at 5:10 pm
I think you're asking for trouble by converting to decimal... but it's your data...
You can build a couple of functions from the following example...
DECLARE @IPAddress VARCHAR(15) SET @IPAddress = '5.152.61.94' DECLARE...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2007 at 4:59 pm
Ummm.... you need to identify to us what makes a "duplicate" and, perhaps, post the DDL for the table where the dupes exist. Elimination of duplicates is not difficult but...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2007 at 4:34 pm
Wow... been there and done that... Glad to see you got a got DBA for a change. ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 10, 2007 at 2:43 pm
Viewing 15 posts - 55,111 through 55,125 (of 59,098 total)