Mark does make a valid point here, since the Application.cfm file will be
processed within the context of each and every call to a .cfm file in your
application. But what if one wanted to do this AND minimize performance
hits, though? Why not use the following check:
<cfif Not(IsDefined("application.globalRecordset"))>
<!--- call code to define application.globalRecordset, properly
scoped of course --->
<!--- we know that application.globalRecordset is defined and
available for use otherwise... --->
</cfif>
assuming the above recordset's contents don't change much from request to
request, you should be able to pull this out of the application "cache".
hope this helps,
Terry.
----- Original Message -----
From: "Mark J. Handy" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 30, 2002 2:14 PM
Subject: RE: [CFTALKTor] SQL - Returning Column Names/ Application/
StoredProc
> Don't mean to butt in here, but the last thing I'd do is run my querries
> in the application.cfm page. Think of the server load when there's many
> sites all running queries every time a cfm page is hit. While I see the
> logic behind it, but the extra load on the server doesn't justify having
> that info available to every cfm page, especaily if it's not needed.
>
> Mark.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
> Behalf Of Nolan J. Dubeau
> Sent: Wednesday, January 30, 2002 2:00 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [CFTALKTor] SQL - Returning Column Names/ Application/
> StoredProc
>
> >My understanding from what we talked about last night Nolan is that you
> >want to do as Marc suggested and separate the SQL from the CFML to
> further
> >simplfy the CFML. This would be a reason for doing this.
>
>
> Hey Rick,
>
> Last night we spoke about running all queries in the application file as
> opposed to a per request basis. This way the queries are always
> available to be referenced. I realize that using stored procedures only
> increases the server performance with certain scenarios.
>
> In the same way that all queries are run in the application file, could
> you 'run' all your <cfstoredproc> statements in the application file as
> well, and reference the results throughout the site?
>
> Maybe I'm just thinking up crazy things. Does this even make sense?
>
>
>
> > > Would there be any
> > > benefit to setting the application var (myList) based on the stored
> > > procedure (the query in SQL)? Is this even possible? Would you
> notice
> > > a performance difference? Or.. would it be best to just run query in
> the
> > > application file?
> >
> > I don't really understand that statement. What do you want to achieve
> with
> > that list? Why set it as an App variable?
>
>
>
> I guess I sort of got off topic Marc. Sorry. The reason I wanted to
> set the list in the application file is that it is referenced site-wide
> in the app (which is built in Fusebox). If I make a change to the
> database (i.e. add a new column), the application file will catch update
> and pass the proper variables to the fusebox statement.
>
>
> Much thanks.
>
> Nolan
>
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
> Behalf Of Rick Mason
> Sent: January 30, 2001 1:11 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [CFTALKTor] SQL - Returning Column Names
>
> > DISCLAIMER ;)
> > I'm not a SQL Server guru, soemone please correct/complete me if my
> > understanding is wrong/unclear.
>
> Neither am I but....
>
> My understanding from what we talked about last night Nolan is that you
> want
> to do as Marc suggested and separate the SQL from the CFML to further
> simplfy the CFML. This would be a reason for doing this.
>
> As for performance increases, on a query that only returns a small
> result
> set the performance increase would be insignificant. In my experience
> the
> performance differences are only noticable when doing something that
> involves a great deal of processing such as multiple inserts into
> mulitple
> tables.
>
>
> Rick Mason
> Pangaea NewMedia, Inc.
> http://www.pangaeanewmedia.ca
> 416-922-1600
>
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 30, 2002 12:43 PM
> Subject: RE: [CFTALKTor] SQL - Returning Column Names
>
>
> > > I've just started to
> > > learn about Stored Procedures, and benefits of running/referring to
> > > queries on the SQL server level (cfstoredproc) as opposed to CF
> level
> > > (referring to the query, not the stored proc)
> >
> > I'm not sure what you mean by "running/referring to queries on the SQL
> > server level (cfstoredproc)".
> >
> > DISCLAIMER ;)
> > I'm not a SQL Server guru, soemone please correct/complete me if my
> > understanding is wrong/unclear.
> >
> > Basically, a Stored Procedure is a piece of SQL code that resides in
> the
> > RDBMS and as already been checked for syntax errors and been
> precompiled
> > where as when you submit a query through ODBC it has to be parsed for
> syntax
> > errors, then compiled and run, thus a stored procedure would return
> results
> > faster since it is already parsed and compiled.
> >
> > > Would there be any
> > > benefit to setting the application var (myList) based on the stored
> > > procedure (the query in SQL)? Is this even possible? Would you
> notice
> > > a performance difference? Or.. would it be best to just run query in
> the
> > > application file?
> >
> > I don't really understand that statement. What do you want to achieve
> with
> > that list? Why set it as an App variable?
> >
> > From what I get, it doesn't make a huge difference in performance
> whether
> > you use a stored procedure or a CFQuery to return a one row recordset.
> It
> > might be good if you plan on putting ALL your apps SQL code in stored
> > procedures, just for the sake of separting the SQL code from the CFM
> code
> or
> > whatever logic is behind that. Some DBA's prefer it that way since
> they
> > don't have to bother with CFM code. For simplicity, maybe a bit of
> lazyness,
> > I would just use a CFQUERY from what I understand.
> >
> > If you could give more details maybe I, or someone else, could advise
> you
> > better..
> >
> > Marc
> >
> > -
> > You are subscribed to the CFUGToronto CFTALK ListSRV.
> > This message has been posted by: "Marc Campeau"
> <[EMAIL PROTECTED]>
> > To Unsubscribe, Please Visit and Login to http://www.CFUGToronto.org/
> > Manager: Kevin Towes ([EMAIL PROTECTED])
> http://www.CFUGToronto.org/
> > This System has been donated by Infopreneur, Inc.
> > (http://www.infopreneur.net)
> >
> >
>
>
> -
> You are subscribed to the CFUGToronto CFTALK ListSRV.
> This message has been posted by: "Rick Mason"
> <[EMAIL PROTECTED]>
> To Unsubscribe, Please Visit and Login to http://www.CFUGToronto.org/
> Manager: Kevin Towes ([EMAIL PROTECTED])
> http://www.CFUGToronto.org/
> This System has been donated by Infopreneur, Inc.
> (http://www.infopreneur.net)
>
> -
> You are subscribed to the CFUGToronto CFTALK ListSRV.
> This message has been posted by: "Nolan J. Dubeau" <[EMAIL PROTECTED]>
> To Unsubscribe, Please Visit and Login to http://www.CFUGToronto.org/
> Manager: Kevin Towes ([EMAIL PROTECTED])
> http://www.CFUGToronto.org/
> This System has been donated by Infopreneur, Inc.
> (http://www.infopreneur.net)
>
> -
> You are subscribed to the CFUGToronto CFTALK ListSRV.
> This message has been posted by: "Mark J. Handy" <[EMAIL PROTECTED]>
> To Unsubscribe, Please Visit and Login to http://www.CFUGToronto.org/
> Manager: Kevin Towes ([EMAIL PROTECTED])
http://www.CFUGToronto.org/
> This System has been donated by Infopreneur, Inc.
> (http://www.infopreneur.net)
-
You are subscribed to the CFUGToronto CFTALK ListSRV.
This message has been posted by: "Terry Kozar" <[EMAIL PROTECTED]>
To Unsubscribe, Please Visit and Login to http://www.CFUGToronto.org/
Manager: Kevin Towes ([EMAIL PROTECTED]) http://www.CFUGToronto.org/
This System has been donated by Infopreneur, Inc.
(http://www.infopreneur.net)
