Re: table API

"bdj" <B.D.Jensen_at_gmx.net> wrote in message
news: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| >| >

|
|

not an issue -- you just write the appropriate procedure/function that
manipulates the appropriate rows