You may be ok (if not better off) with just sticking with(nolock) in there (and using proper prefixing and/or aliasing to help with caching of execution plans).
select schema.table.column from schema.table with(nolock) or select t.column from schema.table t with(nolock) .:.:.:.:.:.:.:.:.:.:.:.:. Bobby Hartsfield http://acoderslife.com http://cf4em.com -----Original Message----- From: John M Bliss [mailto:bliss.j...@gmail.com] Sent: Friday, September 30, 2011 5:45 PM To: cf-talk Subject: SOT: READ UNCOMMITTED We have a fairly high-traffic ACF 8 site where SQL Server database gets hit with two types of queries: type 1 - about 1-5 SELECTS per second that have to run as fast as possible *always* (< 1 second) type 2 - about 100-500 "other" queries per day that are allowed to run "slower" (5-20 seconds). (These are reports, automated processes, etc.) I know I can declare "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED" on some of those type 2 queries so that they do not issue locks on tables that type 1 requires to do its thing. My question is: if the goal is to make sure type 1 remains as fast as possible, will it help/hurt to also declare "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED" on type 1 queries? -- John Bliss - http://about.me/jbliss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:347866 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
