Viewing 15 posts - 50,386 through 50,400 (of 59,091 total)
Don't need Q1 ... nothing to join it to Q2 with.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 4:13 pm
Properly done, written enforced standards won't prevent someone from trying something new, but a process outside the standards should be approved for use. For example, we have a standard...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 9:10 am
While researching this, I found out that the default replication process is to split it up into multiple single-row inserts. This behavior is a problem for us. Instead...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 8:38 am
Heh... see what I mean? Couple hours went by for the original post... 10 minutes after the working table and data was posted in executable form, WHAM! Two...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 8:22 am
Not a problem... but you really have to get in the habit of making things easy on me... post the Create Table statement and the Insert/Select/Union All's that are requried...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 8:18 am
Nice and simple, pleasure to read. Well done, John! 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 8:07 am
I'd bust up the query and store interim answers in a Temp Table instead of doing such a large group by... especially since the GROUP BY is to support 1...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 10:28 pm
You bet... the columnname > '' keeps out Nulls and Blanks and still allows an index to be used.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 10:24 pm
Is the handheld VARCHAR(MAX) capable or VARCHAR(8000) capable? Will the "commands" fit all in a VARCHAR(8000)? Might be able to plow up an old trick or two in...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 10:21 pm
By "Yes", I meant yes, I know a good reference... it starts with your code... I wanted to see your trigger to see if I could help.
The trigger you posted...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 10:10 pm
Heh... guess that's what they call it now... we used to call it a "software training aid". 😀 The bat I kept at my desk was the "hardware...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 9:59 pm
If I remember correctly, NOT EXISTS can actually be a bit faster in the presence of the correct index. Still, it uses correlation which is hidden RBAR.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 9:54 pm
Correct...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 9:51 pm
It's the alias for the derived table... means "New Start Date"... just a name I gave it.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 9:49 pm
Outstanding question! And, sadly, I have no idea why... but it certainly explains why SELECT/INTO is faster even in the FULL recovery mode.
I did it on a 3 column...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 8:16 pm
Viewing 15 posts - 50,386 through 50,400 (of 59,091 total)