how extend the READ statement?

Author: i2stiller@gmx.de (istiller)

Hi Just a "simple" question into the round: "how extend the READ statement"? background: We have to implement some kind of treatment on every read row from database. This includes DISCARDS if special condtions are envountered. Currently we ddo this by a global proc called after the READ in READ-trigger. My idea is to replace also the READ statement itself, so that there is (normal) only one line in READ-Trigger Before

read call SO_READ_AFT() What I want is

call SO_READ("") So far so goodConfused But what if you have to apply conditions and/or order directives? First idea was, to expand the parameter list of SO_READ by a few arguments like v_CONDITION, v_ORDER,  ... But there are two drawback Cry

  1. Performance: On every "read" (not only "retrieve") I have to considerd parameters to use the correct READ statement
  2. Compile-time checks of the entitys and fields in question are not done

So I tought about precompiler statments, but is it not possible to define function-macros like C/C++ One have to write something like this:

#define entity=A_ENT #define order=FLD1:a #define condition= #include SO_READ Drawback

  1. Don't forget to define/undefine, elsecase the next #include could run into trouble.
  2. It's not readable

So once again the simple question "how extend the READ statement" ?Confused Ingo

6 Comments

  1. Maybe you can split the code, to call an entry from your global proc so you get something like this in your <READ> Trigger:   call SO_READ_ATF   entry DO_DISCARD    if (PRICE > 1000)       discard    endif end


    Author: Theo Neeskens (tneeskens@itblockz.nl)
  2. wasn't it that one can not call a local proc out of a global proc? (IIRC)


    Author: ulrich-merkel (ulrichmerkel@web.de)
  3. We use a global proc for our read triggers and in that proc we essentially have

    if ($dbocc == 0)
        $collhandle->preRead(t_where, t_order, t_options)
    endif
    read options t_options where t_where order by t_order
    if ($status >= 0)
        $occhandle->postRead($status)
    endif
     

    We have dummy preRead and postRead operations defined for each entity in the model and we can override those at component level if necessary.


    Author: Andy Heydon (andy@heydon.org)
  4. Hi Andy, Good thinking (as ever), the $collhandle is a very nice way to make local coding accessable from the global proc. Especially because you can use the same operation name over and over again without problems. I use it as well with collection based INIT and CLEANUP operations. These will be invoked during components INIT and CLEANUP operation and perform all these nice tasks like populating valreps etc. I have a #defines dur_formentities = ent1,ent2 to iterate over the entities. The automatic creation of these type of definitions for forms and entities was designed and implemented in the dITo Uniface Reflection (DUR) project.   Greetings from a cold Frankfurt/Germany morning Uli


    Author: ulrich-merkel (ulrichmerkel@web.de)
  5. Hi Uli,    Can you not replace your #defines with a recursive subroutine using $componentinfo($instancename,"OUTERENTITIES")) as the primary, and $entinfo(v_current_name, "INNER") to recurse.  params string v_names : IN endparams variables string v_current_name endvariables forlist v_current_name in v_names ... do your entity level processing if($entinfo(v_current_name,"INNER") != "") forentity v_current_name  call recursive_proc($entinfo(v_current_name,"INNER")) endfor endif endfor


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  6. Hi Iain, the dur_* defines are created automatically within a 2phase compile so there is no manual overhead. And dur_formentities is just one of a suite of needul definitions added to the component. Please have in mind that a couple of years ago we learned in some uniface courses that field indirection takes 10 times longer at runtime than mentioning the direct fieldname in the code. So  the #defines is not only a straight forward coding, but results in a much better performance at runtime compared to that messing around with outerentities and innerentities and recursions and ... And: at compile time, the painted entities are fixed, so there is no gain traversion entity trees at runtime So to your question: Especially if you have entity propagation multiple times in your code, the $componetinfo/$entinfo could be used, but the #defines is the much better option. Greetings from Frankfurt/Germany, Uli


    Author: ulrich-merkel (ulrichmerkel@web.de)