Viewing 15 posts - 58,111 through 58,125 (of 59,067 total)
I absolutely agree with Richard and Tim... if you have dupes in a table, something is usually wrong. However, it might not be your fault because of data you receive...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2006 at 9:29 pm
It really depends on the sproc you build... if it returns a scalar value, as does a function, then there's no advantage to a sproc and it's easier to use...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2006 at 7:48 am
BigInt should do just about anything you need. BigInt holds a huge number ((2^63) -1) and much less behind the scenes processing is done by SQL Server on the Int and...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2006 at 7:33 am
SOMETIMES the performance is similar... SOMETIMES a table variable will absolutely kill performance... read the following to find out why... pay particular attention to "Q3" and "Q4"...
http://support.microsoft.com/default.aspx?scid=kb;en-us;305977&Product=sql2k
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2006 at 7:16 am
I'd recommend that, whatever you do, you do NOT use "Set Transaction Isolation Level" in updatable views... don't know when it will happen but you will eventually run across an...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2006 at 7:09 am
I'm pretty sure that you cannot pass an array... guess that leaves a CSV parameter...
If you don't have very many parameters in the "list", why not pass them as individual...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 16, 2006 at 6:00 pm
Unless it is a homework problem, I see no practical reason to index the view... the underlying indexes of the tables will inherently be used during normal view resolution.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 15, 2006 at 11:31 pm
Strangely enough, you'll usually find a direct correlation between poor performance code and deadlocks and, with the exception of not allocating enough memory, hardware is not usually the problem nor...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 15, 2006 at 11:20 pm
It's apparent, now, the interviewer was asking the interviewee to think outside the box. The original poster didn't explain it was an interview question until after I asked "why". For...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 15, 2006 at 11:11 pm
I have an SQL Server based IVR at work (actually, 400 miles away from the main DB)... it uses a linked server connection with multiple pass through views as you...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 14, 2006 at 5:09 pm
Got it! Thanks for the feedback, Susan.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 14, 2006 at 5:01 pm
You bet, Kevin. Thank you and Niles for the feedback...
Kevin, could you tell us the actions you took? Bet, lot's of folks would like to hear what the lickiest guy...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 14, 2006 at 4:48 pm
Thanks for looking, John. If I find anything from Microsoft, I'll be sure to post it.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 14, 2006 at 7:51 am
One other BIG thing to consider before you delete anything... do you have a permanent backup of the data you are about to delete? One of the 10 commandments for...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 14, 2006 at 7:45 am
Sorry about the confusion on the owners... I'm used to folks putting everything into production as "dbo". Yes, the views you speak of would certainly and easily solve that problem...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 14, 2006 at 7:36 am
Viewing 15 posts - 58,111 through 58,125 (of 59,067 total)