It's worth mentioning that there is some overhead for calling a stored
proc that isn't involved with straight queries, though it should be
minimal. Where stored procs REALLY shine is when you've got a query
whose result is only used for some logic driving another query. Using
a stored proc in tha
> Well, OK, not that dramatic, but every DBA I have ever known
> has told me that if you want performance, you use stored
> procedures. My quick test this evening has me rethinking that.
Just a warning - quick tests are often worth about the time you put into
them.
> The straight query using CF
On 5/20/06, Pete Ruckelshaus <[EMAIL PROTECTED]> wrote:
> Has anyone else found this to be the case? I'm really thinking about
> ripping out all of my SP's and just using queries, it would make my
> life easier on a number of levels. I have all of my queries as
> methods in a CFC, so code re
here's what i have found...
i agree. when it comes to small queries like that with NOT MUCH LOGIC involved.
When it comes to a larger Stored Proc with LOTS of gobbledeegoop, i
think it changes
then.
but yeah, for the most part, i refactored most if not all of my
smaller queries into straight
sq
Well, OK, not that dramatic, but every DBA I have ever known has told
me that if you want performance, you use stored procedures. My quick
test this evening has me rethinking that.
Using essentially the same query (basically a login query against a
single table, pass in username and password, ret
I was doing some performance testing using JRun 4. I have a stateless
session bean deployed on a server running JRun 4. The session bean does a
simple insert into an Oracle DB. I have a CF page talking to the session
bean remotely. It appears that it takes 9 seconds to insert a row into the
6 matches
Mail list logo
