Re: performance of SQL*NET ?

>
>>I've experimented with changing a normal (case generated) form with a lot
>>of post-query triggers in a form based on a join view. Network traffic
>>decreased by a factor 30 (28 packages in stead of 900). Changing the
>>post-query functionality by calling a remote procedure did not help much
>>since the post-query trigger will fire for each fetched record. It showed
>>a decrease of about 100% for the network traffic though. My advice is to
>>base the form on a join view (especially if there is much lookup data)
>>and write the on-insert etc triggers.
 

>>Teijo Doornkamp (doornkampt_at_vertis.nl)
>
>Teijo,
>
>If you're using O7.1, there is an even better solution. You can write stored
>functions to get lookup-fields from code-tables and implement those in an
>updateable view so you don't have to write on-.... triggers.
>
>What I mean is this :
>Table1 : field1 varchar2,
> code_field varchar2
>
>Code_table : code_field varchar2
> description varchar2
>
>Function1 : declare descript varchar2
> select description into descript from code_table
> where code_field = code_field;
> return(descript);
>
>View1 : create view1 (field1, code_field, description)
> as select field1, code_field, function1(code_field)
> from table1;
>
>Now create a block in Oracle Forms based on that view. You can
>update/insert/delete using standard forms functionality (just make sure the
>description field is non-updateable).
>In this case you don't need post-query triggers, decreasing the network
>traffic.
>
>Another solution when you are using Forms4.5 is the use of Record Groups. You
>can store already fetched description-fields there. You can access them from
>the Record Group and need database access only when a new code_field is
>encountered. This is only feasable for small code_tables, as Record Groups
>are stored in memory on the client.
>
>
>Greetings,
>Frank
>

Frank,

You propose very smart solution, but Forms are too stupid to adopt it. I have no possibility to check it aqainst Forms 4.5 (I haven't it, and, as I believe they are absent for SCO yet), but I carrefully tested this solution against Forms 4.0.13. They try update whole records (all fields) and non-updatable property or even declaring items on virtual columns as display items don't matter for Forms. Real stupidity!

Best wishes,

Alexander Alesinsky,
JSV Investor
Kharkov Ukraine Received on Sat Aug 19 1995 - 00:00:00 CEST