Viewing 15 posts - 50,926 through 50,940 (of 59,098 total)
IT salaries are going down for some as Steve mentioned... and for the reasons he mentioned. I'd like to remind all of you managers out there, you get what...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 6:16 pm
Thanks for the feedback... like Gus said, though... leap years can wreak a bit of havoc if they're important.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 6:10 pm
hb21l6 (4/29/2008)
this is the solution i came up with in the end, some borrorwed some new.
SELECT * tbl_locations
WHERE CompanyName = 'someCompanyName'
ORDER BY CONVERT(int, REPLACE(CONVERT(nvarchar, SUBSTRING(IP,...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 6:04 pm
Would you rather have a slightly more complicated database maintenance program or an impossible security situation? 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 5:48 pm
Thanks for the plug, Gus... the article may be found at the following URL...
http://www.sqlservercentral.com/articles/Advanced+Querying/61716/
... and Gus is right... it's nasty fast.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 5:45 pm
Can't do a whole lot for you if you don't post the "simple structure" of the data you're talking about... please click on, read, and provide the information from the...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 9:04 am
In the meantime, please try to figure out what dateformat you'd like for startdate and enddate... I recommend not using one at all.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 8:58 am
karthikeyan (4/29/2008)
Thanks a lot for your help!
I have purified one more time.
DECLARE @DateStart DATETIME
DECLARE @DateEnd DATETIME
SELECT @DateStart = '07/Apr/2008', @DateEnd = '29/Dec/2008'
SELECT Month = convert(varchar,DatePart(MM,DATEADD(mm,N-1,@DateStart))),
...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 8:57 am
If the data is all in one table, there's no need to make it in two separate tables... you can make it appear as if you did that with table...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 8:43 am
You both really need to make a trip to Books Online... and, just to be sure, you can do INSERTs, UPDATEs, and DELETEs on Table Variables in a UDF... just...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 8:26 am
In this case, I'd say no indexes are necessary on the source table and for speed, the fewer indexes on the target table, the better. If the target table...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 8:21 am
This will do it...
--===== Create a table to demo with
DECLARE @DemoTable TABLE (IPAddr VARCHAR(15))
INSERT INTO @DemoTable (IPAddr)
SELECT '192.168.215.1' UNION ALL
SELECT '192.168.23.1' UNION ALL
SELECT '192.168.5.1' UNION ALL
...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 8:17 am
Heh... skip the "trees"... try this...
SELECT ABS(YEAR(DATEADD(dd,DATEDIFF(dd,@BirthDate,@ReferenceDate),0)-1)-1900)
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 8:08 am
So, which columns constitute a dupe? Just the first two or all of them?
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 8:01 am
GSquared (4/28/2008)
create table dbo.Numbers (
Number int identity (0, 1) primary key,
Junk bit)
go
insert into dbo.Numbers (junk)
select top 10000 0
from sys.all_objects s1
cross join sys.all_objects s2
go
alter table dbo.Numbers
drop column junk
go
select dateadd(day, number, '1/1/1900')
from...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 29, 2008 at 7:54 am
Viewing 15 posts - 50,926 through 50,940 (of 59,098 total)