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

Thank you Bill for the link... it was most informative.

Mr. Del M,

You might consider ramping up your stress-tabs a little.

Whipper-snapper... I like that!

So, my subject line may have been a little amiss. What I'm actually using
is an OUTPUT parameter, not a return code. Would that produce a more
favorable response from you regarding my approach?

I'm not new to database development. I am, however, recently exposed to a
'real' database and all of the goodies that come with it and ADO
connectivity and components are a new treat for me. I feel the need to
explore the possibilities, the possible advantages and/or disadvantages in
using these new tools and their features. I am not willie-nillie jumping
into any of it without thought and consideration... that would be why I am
here putting out what may seem like stupid questions to the group... perhaps
find some angle or perspective that I have not come up with myself.

The whole thing of M$ (like the $ by the way!) cutting us off at the knees
was a little wild... not that it doesn't or hasn't or won't happened... just
that it seemed a little paranoid... we can't afford to stagnate on what
little twist $Bill might have in store for us.

I think Dr. Codd would be most impressed with my work, my approach and my
reasoning. He explored cleaner, more efficient strategies and approaches to
accomplishing things, building the theories and structures that we have all
grown to know and love.

When we're all done with this discussion maybe we can exchange war stories
and photos of our grand-children!

re: OUTPUT param ??? your thought ol' man!

b (aka whipper-snapper)

ps... have to confess.. I did have a whipper-snapper working for me
'breifly'... (downloading components, api calls and impossible code
everywhere, non-intuitive interfaces, less then a firm grasp and emphasis on
datastructure, and absolutely no clue why we couldn't walk on the wild side)
and DO understand that 'angle'/'perspective'... just think it's not
warranted in this instance.

"Betsy" <betsy.a.tainer@xxxxxxxxxxxxx> wrote in message
news:427b956b@xxxxxxxxxxxxxxxxxxxxxxxxx
> 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.
> > >
> > >
> >
> >
>
>


.