Viewing 15 posts - 23,491 through 23,505 (of 59,099 total)
andycadley (6/3/2014)
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 7:26 am
Eirikur Eiriksson (6/3/2014)
Jeff Moden (6/2/2014)
Unless this was an accidental duplication of data, there's no way that I'd do this. You're destroying historical data.
Second that but then again that's pondering...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 7:12 am
Interesting... this is the second time in a week that someone has asked this very rare question. I'm just curious... is this a school assignment or are you working...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 6:58 am
It's not the export that's slow. It's the select. Please post it and the DDL (CREATE TABLE) for the two tables along with the CREATEs for the indexes...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 6:54 am
Eirikur Eiriksson (6/3/2014)
tlrsekar 23727 (6/3/2014)
As of now order is not my concern, it can be of any orderYou could use modulus/remainder of the number
Eirikur... it's a self-reseting running total. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 6:33 am
Just do the DATEADD to the Transaction date without all the individual Year, Month, and Day stuff. If the final result needs a particular format and can't be done...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 1:17 am
Tania Mofflin (6/3/2014)
Msg 8114, Level 16, State 5, Line 1
Error converting data type varchar to numeric.
Seems to be an issue with how...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 1:11 am
My question would be, why does this require a RBAR process? What is it that you're doing to "each row" that requires single row processing?
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 1:07 am
To be honest, there are a whole lot of facets to consider for SQL Server AND Windows security. If you don't actually know what they are or your Yabigooglehoo...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 1:05 am
On the subject of "overkill"... I won't dumb down code just because someone might not understand it. When I was a contractor, I considered it to be very important...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 12:53 am
ChrisM@Work (6/2/2014)
ScottPletcher (5/30/2014)
I think the overhead of XML is unwarranted here...Yes you're right, with a fixed number of rows, FOR XML PATH is probably overkill.
I agree that explicit solutions like...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 12:51 am
ChrisM@Work (6/2/2014)
Jeff Moden (5/30/2014)
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 12:44 am
My suggestion would be to find out what actually made it grow so quickly. If someone did something in coded that's getting ready to go to prod, you could...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 12:25 am
sgmunson (5/30/2014)
Jeff Moden (5/30/2014)
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 12:21 am
Try it without the quotes around the numeric constants.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 3, 2014 at 12:14 am
Viewing 15 posts - 23,491 through 23,505 (of 59,099 total)