Viewing 15 posts - 19,771 through 19,785 (of 59,072 total)
GilaMonster (8/24/2015)
James_R_Alves (8/24/2015)
There may be a performance benefit to using table vars over # temp tables as well.A negative one usually, due to the lack of statistics.
...and execution plan estimates...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 24, 2015 at 1:03 pm
You might also try using ALTER INDEX instead of DBCC DBREINDEX, which has been deprecated.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 24, 2015 at 12:48 pm
Steve Jones - SSC Editor (8/24/2015)
Jeff Moden (8/21/2015)
Heh... who tests the unit test code to make sure that's right? 😉
The developer, other developers, whoever. If it's not, change it. Tests...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 24, 2015 at 11:58 am
Heh... perhaps a better question would be, "Are any of you good folks doing penetration testing of your apps and/or your database servers"?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 24, 2015 at 11:34 am
To be honest, your questions reflect a fairly large project. My recommendation is that you and your team get started on these things and if you run into a...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 24, 2015 at 11:31 am
Josh Leane-155117 (8/24/2015)
1) clustered index on tally table didn't make any difference, still 120 secs on test data
2) using LEN(@vstrText) < N made huge...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 24, 2015 at 11:26 am
Eric M Russell (8/24/2015)
--Jeff Moden
Change is inevitable... Change for the better is not.
August 24, 2015 at 9:56 am
Grant Fritchey (8/24/2015)
Threadizens, please don't skip posting your top scripts. I need help on this article.
I thought you just wanted commands. As for "top scripts", I'm not using anyone...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 24, 2015 at 9:54 am
shamshad.ali (8/23/2015)
--Jeff Moden
Change is inevitable... Change for the better is not.
August 23, 2015 at 11:46 pm
Ok. Glad you sussed it. I hope it doesn't come back as a problem in the future because it sounds like (and I could be wrong) a temporary...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 23, 2015 at 10:49 pm
mar.ko (8/19/2015)
Thanks Gila and Scott.....good stuff.Interestingly - by using a temp table instead of a declared table variable, the @@FETCH_STATUS initializes to -1 versus zero.
@@FETCH_STATUS??? Correct me if I'm...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 23, 2015 at 5:14 pm
rightontarget (7/21/2015)
In ssms I right-click on database, go to properties and it shows size = 380G (data file), but I know that...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 23, 2015 at 5:08 pm
ganesh_trichy (8/22/2015)
I am a .net guy, don't have deep knowledge on DB side. I am trying to implement solution for below requirement.
The application is passing a user id and department...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 23, 2015 at 4:41 pm
So, Abhijit More. Did any of this work for you or not? This IS a two way street here. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 23, 2015 at 12:48 pm
jessica.green2312 (8/21/2015)
--Jeff Moden
Change is inevitable... Change for the better is not.
August 23, 2015 at 12:46 pm
Viewing 15 posts - 19,771 through 19,785 (of 59,072 total)