Viewing 15 posts - 35,761 through 35,775 (of 59,102 total)
nigel. (12/7/2010)
Nice Jeff, very nice indeed.Now, all I need is to find somewhere I can use this 🙂
Thanks for the feed. With a bit of extrapolation, you can also...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2010 at 10:00 am
autoexcrement (12/6/2010)
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2010 at 9:58 am
tommyh (12/6/2010)
Nice article as a whole... a bit weak/confusing intro though. But thx to Craigs little comment it became much more clear what/why was being done./T
The folks that know...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2010 at 9:56 am
autoexcrement (12/6/2010)
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2010 at 9:53 am
Craig Farrell (12/7/2010)
You have a contractor who comes by and does work as needed. You're looking for a per...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2010 at 9:46 am
dadam (12/7/2010)
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2010 at 9:43 am
noncentz (12/3/2010)
I have some slightly fragmented indexes that I would like to reorganize but the database is in use most of the day. I know index rebuilds happen...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2010 at 9:52 pm
Lowell (12/3/2010)
however, since a DATE datatype doesn't have the time portion, i think you could...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2010 at 9:39 pm
CELKO (12/6/2010)
A little change in the DDL makes life more relational. Never sue BIT flags in SQL; that is assembley language.
Since SQL Server doesn't actually qualify as a relational database...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2010 at 9:22 pm
mister.magoo (12/6/2010)
select *,
CASE WHEN
...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2010 at 9:18 pm
rocky_498 (12/6/2010)
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2010 at 8:45 pm
thang_ngo_2002 (12/5/2010)
Recently it runs slowly.
If you can figure out what changed (it may just be the size of the data), then you'll know what to do. Credits to Navy-Beans...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2010 at 8:43 pm
JKSQL (12/6/2010)
DECLARE @MappingIds NVarchar(Max)
SET @MappingIds = 'E371F678-45DC-4C83-9D91-286E2BD8ACCF,E371F678-45DC-4C83-9D91-286E2BD8ACCB,E371F678-45DC-4C83-9D91-286E2BD8ACCC'
SET @MappingIds = REPLACE(@MappingIds,'|',',') +','
----Flip csv into a table
;WITH
cteSplit AS
(
SELECT ROW_NUMBER() OVER (ORDER BY N)-1 AS RowNumber,
SUBSTRING(@MappingIds,N+1,CHARINDEX(',',@MappingIds,N+1)-N-1) AS...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2010 at 8:35 pm
pavargasq (12/5/2010)
id appreciate your help
Heh... we'd appreciate a little feedback. 😉 Did that fix it for you or not?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2010 at 8:28 pm
Mike John (12/6/2010)
where .... "whatever determins the masters"
Can you quantify that in code using the example because that is the crux of this problem.
Also... you're using an UPDATE which modifies...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2010 at 8:24 pm
Viewing 15 posts - 35,761 through 35,775 (of 59,102 total)