also, it doesn't look to me like this is the sort of query that really needs caching. i'd guess the query is reasonably fast. i don't cache many queries, but those that i do would tend to be things with complicated joins, or returning 000's of rows, or using lots of LIKE 'name%' clauses etc etc.
but if you do want to improve (slightly) the performance of this query, replace SELECT * with SELECT ID, Name, Address, .... ad infinitum. [anyone got any metrics on how much this does actually improve performance of a query?] Duncan Cumming IT Manager http://www.alienationdesign.co.uk mailto:[EMAIL PROTECTED] Tel: 0141 575 9700 Fax: 0141 575 9600 Creative solutions in a technical world ---------------------------------------------------------------------- Get your domain names online from: http://www.alienationdomains.co.uk Reseller options available! ---------------------------------------------------------------------- ---------------------------------------------------------------------- "Lovelock, Richard J" To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> <richard.lovelock cc: @cgey.com> Subject: RE: [ cf-dev ] Performance 23/10/2003 13:39 Please respond to dev yes I was thinking about that latter solution of having a page to run when the updated DB is loaded - which runs all of the queries with a "0,0,0,0" timespan think that is the way i will go... thing is, with the dynamic queries (e.g. SELECT *, FROM Emp, WHERE empid = #form.empid#) would I need to run the query with "0,0,0,0" for every id - i assume there is a cahed query for every outcome of this query which has been run (i.e. if there are 1000 employees it would be 1000 cached queries not 1 query)??? _______________________________________________________ * Regards, Richard Lovelock Westminster City Council - Web Support Cap Gemini Ernst & Young Southbank 95 Wandsworth Road London SW8 2HG ( 0870 906 7482 _______________________________________________________ -----Original Message----- From: Snake Hollywood [mailto:[EMAIL PROTECTED] Sent: 23 October 2003 13:26 To: [EMAIL PROTECTED] Subject: RE: [ cf-dev ] Performance This is what I do. I have my queries in a module, the cachedwithin is passed as an attribute. So the main site would include the modules like this. <cfmodule template="MOD_NewsQuery" cachedwithin="#application.cachevariable#"> And you setup a variable in your application.cfm for all the various caching periods you want. Now you can call this same module from your admin whenever you update a query and pass a cachedwithin value of "0,0,0,0" so the queries automatically get un-cached. Alternately if you are manually uplaoding a new database rather than using an ADMIN, you can have a single page that CFMODULES all of your queries passing a "0,0,0,0" cachedwithin attribute, and will uncache the whole lot in one go, so u just run this page when u upload a new database. HTH Russ Michaels Macromedia/Allaire Certified ColdFusion Developer CFMX Hosting Phone: 0845 456 3487 Tech Support: 0906 9607800 FAX: 0709 2212 636 WEB: cfmxhosting.co.uk >Please use the support helpdesk on our web site to submit support tickets.< Join our ColdFusion Developer discussion lists. Send an e-mail to [EMAIL PROTECTED] > -----Original Message----- > From: Lovelock, Richard J [mailto:[EMAIL PROTECTED] > Sent: 23 October 2003 08:47 > To: '[EMAIL PROTECTED]' > Subject: RE: [ cf-dev ] Performance > > > I have some cached queries - some using url/form variables in > Where clause etc > > After updating DB (usually once a week in a big way) the > changes aren't appearing > > The way I am getting around this is to change the > cachedwithin="#CreateTimeSpan(5, 0, 0, 0)#" in my pages to > cachedwithin="#CreateTimeSpan(0, 0, 0, 0)#" then uploading > them and surfing to each to fetch new results from DB. Then > changing back to cachedwithin="#CreateTimeSpan(5, 0, 0, 0)#", > then uploading again. > > This achieves the results I want in terms of getting the new > data DB but is there a more efficient way of doing this other > than changing code/uploading/surfing to pages/changing code > again/uploading again? > > _______________________________________________________ > * Regards, > Richard Lovelock > Westminster City Council - Web Support > Cap Gemini Ernst & Young > Southbank > 95 Wandsworth Road > London > SW8 2HG > ( 0870 906 7482 > > _______________________________________________________ > > > -----Original Message----- > From: Ellwood [mailto:[EMAIL PROTECTED] > Sent: 22 October 2003 19:47 > To: [EMAIL PROTECTED] > Subject: RE: [ cf-dev ] Performance > > > Allan, > > Stored procedures don't improve speed that much unless you > are doing multiple queries in one page. This is then a better > example for using stored procs because of the lack of client > server handshaking needed after each query. > > Cached queries however are much faster but beware that you > don't get confused about updates not appearing straight away. > The way around this is run the query straight after updating > with a timespan of less than 0 for example CreateTimeSpan(0,0,0,-1) > > Sorry if I have repeated what everyone else has said but my > computer has been out of action for most of the day due to my > antivirus picking up a bug and eliminating it rather radically. > > -----Original Message----- > From: Allan Cliff [mailto:[EMAIL PROTECTED] > Sent: 22 October 2003 10:33 > To: CF - List > > Anyone like to share their opinion on improving coldfusion > speed either by using stored procedures or caching queries? > > Which one is better? Or does it depend on the query. > > At the moment I have a mixture of them both with dynamic > queries as SP and basic queries q_GetCountries and > q_GetStates as CachedWithin. > > Any comments? > > Thanks > > Allan > > > -- > ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] For human help, e-mail: > [EMAIL PROTECTED] > > > ======================================================= > This message contains information that may be privileged or > confidential and is the property of the Cap Gemini Ernst & > Young Group. It is intended only for the person to whom it is > addressed. If you are not the intended recipient, youare not > authorized to read, print, retain, copy, disseminate, > distribute, or use this message or any part thereof. If you > receive this message in error, please notify the sender > immediately and delete all copies of this message. > ======================================================= > > > -- > ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] For human help, e-mail: > [EMAIL PROTECTED] > -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED] ======================================================= This message contains information that may be privileged or confidential and is the property of the Cap Gemini Ernst & Young Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, youare not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ======================================================= -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED] -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED]
