Viewing 15 posts - 46,186 through 46,200 (of 59,095 total)
robert.letts (1/2/2009)
Here is a weird problem that made me choose a cursor. The incoming data was in a header / detail format. The header had 5...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 2:01 pm
Linson.Daniel (1/2/2009)
...nevertheless worth a look and definitely an alternate solution to cursors.....
No! It's NOT! It still uses a declared loop and it's still just as bad as...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 1:56 pm
wagner crivelini (1/2/2009)
This works when you have one scalar value to return, instead of a whole table.
But there are workarounds, of...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 1:54 pm
sudhanvag (1/2/2009)
I have added an extra table for UserListing.
CREATE TABLE dbo.tblUser ( codUser INT, codName VARCHAR(20),PRIMARY KEY (codUser));
insert into dbo.tblUser values (1, 'abc');
insert...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 1:50 pm
slippers (1/1/2009)
One question: if considering whether to use Cursors or alternatives, how does trigger firing influence the decision?
I mean, when using a cursor to perform an insert statement with...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 1:43 pm
battelofhalfwits (1/1/2009)
Two things
1) Never use Cursors! Looping through a temp table takes less overhead than a Cursor; especially when you are working on a 24/7/365 server where you really...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 1:40 pm
JRoughgarden (1/1/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 1:37 pm
Ok... from JacRobert's description, Create Table statement, and a couple of good guesses like the fact that since all the columns are nullable, there's no primary key, here's a chunk...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 1:26 pm
Heh... an I'll maintain that what he said is nutty for mor than 1 reason. Consider the title and the first sentence...
[font="Arial Black"]Let's deprecate UPDATE FROM! [/font]
I guess that...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 1:08 pm
Cool... that 1899-12-30 thingy about the time also explains why you add 2 days to the combination of date and time. Thanks, Jac.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 11:51 am
And, just to be 100% clear... would you give a couple of actual examples of the various cookie formats you're expecting so I can make a good cross section of...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 10:52 am
Matt Whitfield (1/2/2009)
Jeff Moden (1/2/2009)
jacroberts (1/2/2009)
TheSQLGuru (1/2/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 10:46 am
Phil Factor (1/2/2009)
Jeff
I'll take that challenge and I'll take all comers.
[p]I've got a 'quirky' Update solution that motors. I'd love some real data to run comparative timings on.[/p]
Heh... not fair,...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 10:17 am
TheSQLGuru (1/2/2009)
Jeff Moden (1/2/2009)
Alexander Kuznetsov (12/24/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 10:11 am
jacroberts (1/2/2009)
TheSQLGuru (1/2/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 2, 2009 at 10:04 am
Viewing 15 posts - 46,186 through 46,200 (of 59,095 total)