Viewing 15 posts - 52,966 through 52,980 (of 59,072 total)
You CANNOT rely on the "% of Batch" listed in estimated or actual execution plans to determine which query is best... it can "lie" because it can't always see everything......
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 9:01 pm
Doesn't even need to be SSIS... can be some decent stored procs. But the point is an excellent one...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 8:36 pm
UDF's are typically RBAR...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 8:32 pm
Heh... It's amazing to me how many undocumented databases there are in the world. It also amazes me how many there are with no DRI... no DRI means no...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 8:29 pm
Step 1 should be to nomalize the table so things like this become much easier.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 8:17 pm
The real culprit is likely going to turn out to be a deadlock. You need to read "Deadlocks, detecting and ending" in Books Online. Pay particular attention to...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 8:03 pm
SQLElhassan (1/11/2008)
The Numbers table worked perfectly for me but I want to have my leading zero back in the PK field. Like I explained above, I'm...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 8:00 pm
aliciakw123 (1/10/2008)
I am trying to set up permissions in SQL 2005 to give a user Read Only rights to the table, but he needs to be able to create views.
As...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 7:55 pm
Would you please post the data in a code window so it doesn't wrap?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 7:51 pm
Exactly...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 7:48 pm
You should probably check which columns are in the index vs what you update in the tables... if you're modifying those columns, that'll certainly cause the index to jump about....
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 7:47 pm
First, it's not likely that we'll actually be able to see the document on your "C:" drive.
Second, you haven't explained what you want the proc to do.
Third, if you want...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 7:41 pm
Even in SQL Server 2000, there is no need to engage any systems tables to figure out if an object exists...
IF OBJECT_ID('someobjectname','xtype') IS NOT NULL
... object exists ...
ELSE
... object does...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 7:36 pm
Careful... that's only guaranteed to work correctly if one of two things happen...
1. You have a rock solid clustered index on the correct columns and you have an "anchor"...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 10:24 am
Including name in the sub-query will not guarantee unique SSN's. 😉
Still, I'd like to know... not that I'd do it with a Temp Table, but what's so important about avoiding...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2008 at 7:31 am
Viewing 15 posts - 52,966 through 52,980 (of 59,072 total)