Viewing 15 posts - 50,401 through 50,415 (of 59,099 total)
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
CTE is nothing more than a "derived table"... try this...
--===== Do the update using the new "start date" and add 1 to that for new "end date"
UPDATE s
...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 7:31 pm
Heh... shouldn't have posted in the SQL Server 2005 forum then... 😉
Lemme see what I can do...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 7:28 pm
The following is from Books Online and should help you...
Logged and Minimally Logged Bulk Copy Operations
When using the full recovery model, all row-insert operations performed by bcp are logged in...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 7:22 pm
So, what was the problem?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 7:07 pm
Either you're not using SQL Server 2005 or your compatibility mode is set to "8.0".
Please check.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 6:56 pm
2k5 has Synonyms... much faster to flop a synonym between two tables.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 6:54 pm
You really shouldn't use ISQL.exe... use OSQL.exe instead. Also, as suggested, BCP is likely the way to go here.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 6:45 pm
Viewing 15 posts - 50,401 through 50,415 (of 59,099 total)