Re: RETURN_VALUES ??? done... What have I gained?

ok... we have a yeah and a neah!

Who is Doctor Codd?

I don't think that taking this approach is so complex that the person coming
behind me would have any difficulty interpretting it. I'm all for the 'keep
it simple stupid' rule and have an overwhelming desire, even need, to keep
it thus so that 'I' can understand it.

How would I be 'thrashing the db' ?

Explain 'tuned' to me. If I have a 'normalized' - 'well formed'
datastructure and my sql statements are 'clean/well structured', then I'm
tuned... right? (with no angst, por favor!)

I used the TADOCommand component as Brian suggested... seems clean enough.
Doesn't seem to really be less code... other then I will be asking numerous
similar questions via stored proc and can set up a function to do the work
with a proc name and return the value. I'm 'guessing' that if I need a
value vs a dataset that somehow it would be more efficient to retreive the
value... but it's just a guess... I'm thinking that regardless of 1 row or
100 rows and 1 or numerous columns that there must be some amount of
overhead required to accomplish that. (that was at the heart of the original
question). Taking this approach DOES seem to have a performance gain,
visually (immediate), over reading the field from the dataset... it wasn't
really a measurable length of time to read the field... but now it seems
even less so.

After reading numerous posts I started replacing my TadoTable components
with TadoDataset and did notice a considerable gain in performance and have
since found that I prefer working with the dataset component for a lot of
reasons. I was not aware of how TadoCommand played into that scenario...
(good info, thank you).

Is this just a pepsi vs coke thing? (matter of personal preference) or is
there a legitimate reason to take one approach over another.

Your input greatly appreciated!

thanx
b

"Del M" <Del.Murray@xxxxxxxxxxxxxx> wrote in message
news:427ad8a9$1@xxxxxxxxxxxxxxxxxxxxxxxxx
> What's the real question ?? is one more efficient than the other ?? If the
> database is not properly tuned then it doesn't matter which you use, all
> efficiency might be lost by thrashing the db.
> tAdoDataSet is really easy to use. You can set the commandtext to standard
> sql statement or point to a stored procedure. Eitherway, you "open" the
> dataset even though you are pointing to a stored procedure. The stored
> procedure can be as simple as "select sum(x) where .." or it can be a hugh
> join with unions and cross db joins etc, which could result in one row or
> one column or a gazillion rows. When you use a tADOStored procedure, it is
> usually because the storded proc itsself is doing something and you dont
> need a result set, you just want to know if it was successful or not. On
the
> surface, if you want data, do a tadodataset , if you want the strored
> procedure to do it's thing and tell you it is ok, then do a
tadostoredproc.
> But dont use a stored proc return code to return data .... data is not a
> return code, it is data, and return codes are not data, they are return
> codes. That way the person comming behind you will see a tAdodataset and
> know that you are retrieving data (even if it is 1 row, 1 column) and they
> will be better able to understand what you are trying to do. Doctor Codd
> would frown on you using a stored procedure return code to get the sum of
an
> amount column. He would rather you use a stored procedure to execute a
> precompiled sql statment which returns in a recordset, the answer that you
> need.
>
> "Betsy" <betsy.a.tainer@xxxxxxxxxxxxx> wrote in message
> news:427aa075@xxxxxxxxxxxxxxxxxxxxxxxxx
> > General question...
> >
> > -using an ADOSTOREDPROC component... is there any reason why I should
use
> > something else, say ADOQuery ???? With adodataset I was getting an error
> > about a result set and didn't see anywhere where I had the opportunity
to
> > Execproc vs Open... (did I miss something there?)
> >
> > -the only advantage I see is that I'm not trying to return a dataset
when
> > all I need is a stinkin value, amount, string, what-have-you... there is
> > nothing especially clean and simple about it... so... (the question)
> > (FINALLY!)... Did I really gain anything??? (other then some tiny sense
of
> > accomplishment)
> >
> > That is a serious question by the way... is it somehow more effecient to
> > retrieve one value/result when that is all you need?
> >
> > ***for the inquiring mind***
> > stored proc:
> > CREATE PROCEDURE dbo.getPayments @meetingCode char(6), @guestID
char(10),
> > @total money OUTPUT AS
> > /* used to retreive the payments made by a member*/
> > select @total = sum(amount)
> > from payments
> > where (meetingCode= @meetingCode) and (guestid = @guestid)
> > RETURN
> > GO
> >
> > call in a function:
> > function Tdm.GetPayments: currency;
> > begin
> > result := 0.00; //default
> > if adodsMeeting.Active then //a meeting is opened
> > begin
> >
> > with ADOSP do
> > begin
> > close;
> > Prepared := false;
> > Parameters.Clear;
> >
> > ProcedureName := 'getPayments';
> >
> > Parameters.CreateParameter('meetingCode',ftString,pdInput,6,
> > trim(adodsGuests.Fieldbyname('meetingCode').AsString));
> > Parameters.CreateParameter('guestID',ftString,pdInput,10,
> > trim(adodsGuests.Fieldbyname('guestid').AsString));
> > Parameters.CreateParameter('total',ftCurrency,pdOutput,10,0);
> >
> > prepared := true;
> > ExecProc;
> >
> > if varisnull(Parameters.ParamByName('total').Value) then
> > result := 0.00
> > else
> > result := Parameters.ParamByName('total').Value;
> > end;
> > end;
> > end;
> >
> >
> > ps... thanx Ron noone@xxxxxxxxxxxxxx your notes helped tremendously...
I
> > find microsoft help to be a little criptic.
> >
> >
>
>


.