Re: performance of SQL*NET ?
Date: 1995/08/01
Message-ID: <fkuyt.24.00156E0C_at_iaehv.nl>#1/1
>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 :
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).
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,
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;
In this case you don't need post-query triggers, decreasing the network
traffic.