As I see it... and I'm no expert...
qry files are simple selects only.
For updates, inserts and deletes, those are act files.
Each select query goes in a separate fuse (qry), as does each individual
insert, delete and update (act). You call them through separate fuseactions.
The idea is that each fuse would contain as little code as possible (or as
granualr as you want it) to allow maximum reuse of fuses. But if you find
that combining all query calls into one fuse (like a stored Proc with its
triggers, et al) go for it.
Bob Krieger
www.FBTutor.com
The FuseBox Tutor
----- Original Message -----
From: "Barney Boisvert" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 22, 2002 11:57 AM
Subject: qry_ files
> I was discussing the use of qry_ files with a friend, and we ran into a
> difference of opinion regarding their use (or perhaps structure). This
> stemmed from a problem where I had a situation like this:
>
> -------------------------------
> <cfquery ... name="get">
> SELECT ...
> </cfquery>
>
> <cfif get.recordcount>
> <cfquery ... >
> UPDATE ...
> </cfquery>
> <cfelse
> <cfquery ... >
> INSERT ...
> </cfquery>
> </cfif>
> -------------------------------
>
> His opinion is that I should have three files (all qry_ files), and then
> put the conditional logic in my switch. The goal is code reuse, because
> each piece can be reused separate from the rest.
>
> My opinion is that qry_ files should be basically equivalent to STORED
> PROCs, for when your database doesn't let you do them natively (I'm using
> MySQL). The goal is encapsulation of functionality. If/when the RDBMS
> is upgraded, you can switch to real STORED PROCs by merely changing the
> qry_ file, and not have to go in and fudge around with the code in the
> switch.
>
> A third option that kind of melds the two together, would be to have
> another file (act_) that hold the conditional logic, and CFINCLUDES the
> relevant qry_ files. This lets you reuse the code, but keeps things in a
> functionally separate space. I see that as analogous to nested stored
> procs.
>
> I'm going with the second approach, but I (and my friend) was wondering
> what people have used in the past and what's ended up working best for
> them.
>
> cheers,
> barneyb
>
> ---
> Barney Boisvert beb-web design
> [EMAIL PROTECTED] PO Box 1366
> (503) 267-2200 Portland, OR 97207
>
> http://www.beb-web.com
>
>
>
==^================================================================
This email was sent to: [email protected]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
