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]

Reply via email to