RBarryYoung

1,559 reputation

215

bio	website	movingsql.com
	location	New Jersey
	age	55
visits	member for	1 year, 2 months
	seen	Jun 9 at 18:36
stats	profile views	61

coder & programmer of many defunct languages...

	1,559 reputation	bio	website	movingsql.com	visits	member for	1 year, 2 months
215 badges		location	New Jersey		seen	Jun 9 at 18:36

summary answers questions tags badges favorites bounties reputation activity

156 Actions

suggestions reviews revisions comments badges posts accepts all

Oct 4	suggested	suggested edit on SSMS Tools Pack Alternative
Oct 4	answered	Visio 2010 and SQL 2012 - Reverse Enginnering
Aug 31	comment	Is it possible to increase query performance on a narrow table with millions of rows? Again, the index already existed. I just added three BIT columns to its leaf-level. That, I submit, is "not really significant".
Aug 31	revised	Is it possible to increase query performance on a narrow table with millions of rows? added 156 characters in body
Aug 31	comment	Is it possible to increase query performance on a narrow table with millions of rows? The overhead head for the covering index isn't really significant given that it's a narrow table and the "covering" is just an addition to the pre-existing index that already included most of the row.
Aug 31	comment	Is it possible to increase query performance on a narrow table with millions of rows? Yep, that's because it realizes that it can use the covering index to skip having to do the sorting for the ORDER BY.
Aug 31	comment	SQL Server 2008 merge statement deadlocking itself Maybe. Or it may turn the deadlock exceptions into concurrency exceptions.
Aug 30	answered	SQL Server 2008 merge statement deadlocking itself
Aug 30	comment	SQL Server 2008 merge statement deadlocking itself Oh, last question, is the Foreign Key setup to Cascade on Insert?
Aug 30	comment	SQL Server 2008 merge statement deadlocking itself Possibly. A really slow server can generate false deadlock warnings, but performance would be seriously bad (5-10 response times).
Aug 30	comment	Is it possible to increase query performance on a narrow table with millions of rows? the scan threshold is normally much lower than that (10% or even lower), however since the range is a single day from over a year ago it should not make even that threshold. And a Clustered Index Scan is not a given, since a covering index was added. Since that index makes the WHERE clause SARG-able, it should be preferred.
Aug 30	comment	Is it possible to increase query performance on a narrow table with millions of rows? @Max Vernon: Maybe, but that should have been flagged on the query plan.
Aug 30	comment	SQL Server 2008 merge statement deadlocking itself I really suspect that there must be a larger/containing transaction.
Aug 30	comment	SQL Server 2008 merge statement deadlocking itself Can you make the query plan available?
Aug 30	comment	Is it possible to increase query performance on a narrow table with millions of rows? Yeah, that's not right, somethings throwing the stats/optimizer off. Add a hint to force it to use the new index.
Aug 30	comment	SQL Server 2008 merge statement deadlocking itself Also, how many rows are in the @datatable parameter?
Aug 30	comment	Is it possible to increase query performance on a narrow table with millions of rows? Post the query plan.
Aug 30	comment	SQL Server 2008 merge statement deadlocking itself I honestly cannot understand how you can be getting deadlocks with this statement when HOLDLOCK has been specified, unless there is something else going on. Are there any triggers? Is this proc part of a larger transaction? Are there any Indexed Views that are based on this table? ...?
Aug 30	comment	SQL Server 2008 merge statement deadlocking itself Do you mean "Blocking"? Or are you really getting "deadlock" exceptions in the SQL Server Error Log? (and/or in the app clients)
Aug 30	comment	SELECT value from database over ODBC wont reach the software This is almost certainly a problem with the code not fully consuming and releasing a dataset before trying to process another one. It has probably started now because one of your tables has recently gotten large enough that the number of returned rows for some query no longer fits into the default number of rows returned (which may be 20, but is settable in the code).