Viewing 15 posts - 20,791 through 20,805 (of 22,226 total)
See the post above by Julius. That shows how to unpack the XML files.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 26, 2008 at 10:28 am
Can you edit the sample XML to remove the angled brackets? I usually use square brackets and comment the code. The angled brackets results in blank data as you see...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 26, 2008 at 6:38 am
And the place you want to go to look at these locks as they occur is sys.dm_tran_locks (p. 346 😛 ).
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 26, 2008 at 5:26 am
The reason you're getting an error saying those objects don't exist is because those objects don't exist in 7.0.
I actually don't have any more copies of 7.0 installed around here...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 25, 2008 at 9:37 am
Also, from the sounds of things, you're doing RBAR (row-by-agonizing-row) processing. Can't you pass the ID's to your query as a set and then do a join against your data...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 25, 2008 at 6:58 am
The order of locking depends on the query being run. That's why two different queries can lock in different order leading to deadlocks. You can usually spec it out in...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 25, 2008 at 6:52 am
One more for it depends. With a very simple comma delimited list, we've found that a UDF can perform well enough to turn that into data within a query. For...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 25, 2008 at 6:43 am
Nice catch Jack. I just hadn't been aware of that. It's good to know because it's the kind of thing that can lead to a lot of confusion. Just to...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 25, 2008 at 5:36 am
No, you can't pass the table name as a variable. You're close though. Instead of this:
UPDATE @TableName
SET @ColumnName = NEWID()
Create a variable of type nvarchar(max) and try this:
SET @sql =...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 24, 2008 at 4:13 am
Nice job Scott. I'm looking forward to seeing the code coming out of this effort.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 24, 2008 at 4:05 am
I'm just unsure at this point. I tried with a larger query, 178 lines, not insane or stupid, but surely not trivial. The first time I ran it, I got...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 21, 2008 at 12:46 pm
We're using DB Pro for all our new development and quite a few of our older systems. This is in SQL Server 2005 and 2000. We use the tool to...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 21, 2008 at 7:05 am
The only way I know to do something like this is with a table that contains key values. You can then use IDENTITY. But, short some pretty intense triggers or...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 21, 2008 at 6:52 am
I'm sure it has been mentioned before, but be sure you're qualifying the procedure name and using proper case on the schema, proc, and all parameters.
That said. I'm running tests...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 21, 2008 at 6:16 am
The added value of having the perfmon files is that you can then link them up with Profiler files for some serious troubleshooting & tuning fun.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 20, 2008 at 1:43 pm
Viewing 15 posts - 20,791 through 20,805 (of 22,226 total)