Re: SQL FORMS beginner's questions

From: Paul M. Mickel <mickel_at_nostromo.OES.ORST.EDU>
Date: 23 Feb 93 18:59:51 GMT
Message-ID: <1mds77INNbvq_at_gaia.ucs.orst.edu>


In article <C2wtMH.BEv_at_news.iastate.edu> GO.MSB_at_isumvs.iastate.edu writes:
>In article <C2uMCF.4pF_at_shakti.ncst.ernet.in>,
>adv8_at_shakti.ncst.ernet.in (Course account) writes:
>>In article <1lldp7$8ol_at_news.cs.tu-berlin.de> ernst_at_cs.tu-berlin.de (Ernst Kloecker) writes:
>>>Hallo,
>>>
>>>I just started using SQL FORMS and ran into two simple problems :
>>>
>>>
>>>1. How can one invoke an OS command from within SQL FORMS and pass a
>>>field value as a parameter ? (OS = OS/2 in this case)
>>>
>>>
>>>2. I find one feature of SQL FORMS quite annoying : When I press COMMIT,
>>>all the records previously accessed are updated, even if I was only
>>>browsing through their contents. I would rather have COMMIT to update
>>>only the record on screen. Is it possible to do that ? Or else, is it
>>>possible to disable scrolling through records with the cursor keys ?
>>>
>>>Can anybbody help me out ? Thanks in advance, Ernst.
>>>--
>>>-----------------------------------------------------------------------------
>>>Ernst Kloecker phone: ++49-30-6181635 e-mail: ernst_at_cs.tu-berlin.de
>>>-----------------------------------------------------------------------------
>>
>>I have an excellent suggestion .... Just dont do anything

boy, it must be nice that you don't have a business to run and people who rely on it to be productive......

>>>>R. Chitra phone : India ,Bombay - 2186567, 8377598
 

>*****************************************
>Mr/Ms Chitra, that is a lousy suggestion. One doesn't get ahead in this
>world watching others, or doing nothing as you suggest.
>
>I have been waiting for an intelligent reply to the above query, but since
>I have seen none, I will add my $.02 worth.

I think that I will add some intelligent comments also:

> 1) there is the HOST procedure. Can you not build the "system_command_string"
> to contain the field variable through concatenation of strings?

This is very simple to do. One of the ways that I have done this is to build a string in other triggers, set up a global variable to store the string, then use the global variable in the trigger calling the host command. There is a danger in this as you are restricted to 256 chars for a global variable, so if the string is based on a variable such as :system.last_query, you run the risk of having it chopped off when the assignment to the global variable is done. This is for Oracle v6, so it may have been fixed in v7. For instance, this might the case:

KEY-EXEQRY trigger:
begin

    execute_query;
    :global.last_query = :system.last_query; end;

ON-VALIDATE-FIELD trigger (for printing thru SQR): declare

    sqrstring char(512);
begin

    sqrstring := 'sqr report.sqr extract/the_goal -Freport.lis';
    sqrstring := sqrstring || '"' || :global.last_query || '"';
    if (:print = 'Y' or :print ='y') then
       host(sqrstring);
       host('lp -s -dextract report.lis',NO_SCREEN);
       redisplay;

    end if;
    :print :='N';
end;

> 2) I find the fact that COMMIT is always on a form-level basis very annoying
> also--I would like a block-level commit. What I do in this case is to
> sequentially go through the other blocks with a PRE-COMMIT trigger,
> do a CLEAR-BLOCK(no validate), and then a COMMIT. Of course all other
> data has now been cleared from the form. In one case, I saved the
> ROWID's of each of the other blocks and then restored the data. What
> a pain.

One way to do this would probably be to create a PRE-COMMIT trigger on the block in question with the following code:

begin

   if (:system.block_status = 'QUERY') then

     message('No need to commit');
     raise form.trigger_failure
   else
     <actions>

   endif;
end;

There are probably better ways, but this is off the top of my head.

> 3) Why do you want to disable scrolling? Why retrieve the data if you
> don't want the user to see it? It is the presence of a record in the
> other blocks which screws up the commit. The number of records is
> immaterial. The other blocks must be cleared to prevent the commit
> from duplicating them back into the database tables.
>
>Any other (intelligent) comments on this would be appreciated.
>
>Marvin Beck Iowa State University

-- 
Paul M. Mickel			  	   Internet:mickel_at_oes.orst.edu
Sysadmin, Oregon Extension Service	   Corvallis, OR 97331
Database Programmer, Teledyne Wah Chang    Albany, OR 
Disclaimer: Neither employer has *ever* claimed any of my opinions.
Received on Tue Feb 23 1993 - 19:59:51 CET

Original text of this message