Re: table API

From: bdj <B.D.Jensen_at_gmx.net>
Date: Wed, 15 Dec 2004 21:04:05 +0100
Message-ID: <41c0988c$0$286$edfadb0f_at_dread11.news.tele.dk>


Hi!
But what about performance when you have to manipulate more than one row quickly?
Greetings
Bjørn
"Mark C. Stock" <mcstockX_at_Xenquery .com> skrev i en meddelelse news:apOdnWPwarUfvV3cRVn-rg_at_comcast.com...
>
> "bdj" <B.D.Jensen_at_gmx.net> wrote in message
> news:41bf3ce8$0$281$edfadb0f_at_dread11.news.tele.dk...
> | Hello!
> | With Designer (and other tools) you can generate table-API's.
> |
> | When is a good idea to use it? I assume that it only make sense when
> have
> to
> | modify an single row by an
> | Forms/Report or other end-user-application (for example
> web-interfaces) -
> | right?
> |
> | Where to read more about it?
> |
> | Greetings
> | Bjørn
> |
> |
>
> i've come to be quite an advocate of TAPI's the more applications i've had
> to maintain
>
> TAPI's generated by tools are of course very rudimentary -- but as you
> fold
> in appropriate business rules, having a single procedure that maintains a
> table greatly simplifies maintenance and development -- and debugging. on
> many projects that i've been called in on to support/maintain/enhance i've
> had to spend most of my time searching code to find out what procedures
> are
> accessing a certain table. if it's all in a single package, you've got a
> nice clean structure to work with.
>
> ++ mcs
>
>
Received on Wed Dec 15 2004 - 21:04:05 CET

Original text of this message