Tom:
Thanks a lot about pointing me this neat web feature:
1. Is this what you use always in asktom site?
2. I was trying to see more examples of this but the above link you refer to
</code>
http://www.olab.com/doc/books/plsql/pl_invk.htm <code>
does not seem to work?
3. Let us say I have the following html form and after user fills it out I want
to post values to a save procedure:
htp.formtext(p_lastname,30,30,null);
htp.formtext(p_firstname,30,30,null);
htp.formtext(p_city,30,30,null);
htp.formtext(p_state,10,10,null);
htp.formtext(p_zip,5,5,null);
FOR x in (1..5) LOOP
htp.formtext(p_itemno,2,2,null);
htp.formtext(p_description,30,30,null);
htp.formtext(p_qty,5,5,null);
htp.formtext(p_unit_price,5,5,null);
END LOOP;
---------*this is how I used to do it.
create or replace procedure save_form (
p_lastname VARCHAR2 DEFAULT NULL,
p_firstname VARCHAR2 DEFAULT NULL,
p_city VARCHAR2 DEFAULT NULL,
p_state VARCHAR2 DEFAULT NULL,
p_zip VARCHAR2 DEFAULT NULL,
p_itemno TYPES.ARRAY DEFAULT TYPES.EMPTY_ARRAY,
p_description TYPES.ARRAY DEFAULT TYPES.EMPTY_ARRAY,
p_qty TYPES.ARRAY DEFAULT TYPES.EMPTY_ARRAY,
p_unit_price TYPES.ARRAY DEFAULT TYPES.EMPTY_ARRAY,)
as
v_personid number(5);
begin
select person_id into v_personid from dual;
insert into person (personid,lastname,
firstname,state,zip )
values
(v_personid,p_lastname,p_firstname,
p_city,p_state,p_zip);
If (SQL%ROWCOUNT > 0) THEN
FOR i in 1..p_description.count
LOOP
insert into items (personid,itemno,description,
qty,unit_price)
values
(v_personid,p_itemno(i),
p_description(i),p_qty(i),
p_unit_price(i) );
END LOOP;
ELSE
rollback;
END IF;
END;
-----Now to use flexible parameters is this how you do it?
create or replace procedure save_form (
name_array TYPES.ARRAY DEFAULT TYPES.EMPTY_ARRAY,
values_array TYPES.ARRAY DEFAULT TYPES.EMPTY_ARRAY)
as
v_personid number(5);
begin
select person_id into v_personid from dual;
insert into person (personid,lastname,
firstname,city,state,zip )
values
(v_personid,
value_array(1),value_array(2),
value_array(3),value_array(4),
value_array(5) );
If (SQL%ROWCOUNT > 0) THEN
FOR i in 1..name_array.count
LOOP
If (name_array(i)='p_description') THEN
insert into items (personid,itemno,description,
qty,unit_price)
values
(v_personid,value_array(i),
value_array(i+1),value_array(i+2),
value_array(i+3) );
END LOOP;
ELSE
rollback;
END IF;
END;
4. Would not using flexible parameters make code much easier to maintain. If you change forms by adding or deleteing text fields you do not have to worry about adding/deleteing the parameters in the save/update procedure?
5. when would you use a four parameter interface instead of two?
Thank you,
1) nope, i like formal named parameters. I like things clear, explicit. I type fast -- I don't mind having real argument lists that help me validate my inputs and outputs. generic code is fine, generic code breaks lots. Less chance for error if you are explicit.
2) </code>
http://docs.oracle.com/cd/A97329_03/web.902/a90855/feature.htm#1005765 <code>
is the only source I'm aware of. OLAB was the name of the app server groups webserver a couple of years ago -- long time ago.
3) sort of -- you'll need checks to see how many rows are actually in your form so you don't end up inserting lots of empty rows into items -- your current logic doesn't look right but thats a programmer bug -- you can fix that up.
4) i seriously 100% doubt it -- sincerely.
I would hate to inherit a zillion lines of spagehtti code that indirectly referenced everything through arrays like that.
You tell me -- which is really clear to you as to what it expects as input:
create or replace procedure save_form (
p_lastname VARCHAR2 DEFAULT NULL,
p_firstname VARCHAR2 DEFAULT NULL,
p_city VARCHAR2 DEFAULT NULL,
p_state VARCHAR2 DEFAULT NULL,
p_zip VARCHAR2 DEFAULT NULL,
p_itemno TYPES.ARRAY DEFAULT TYPES.EMPTY_ARRAY,
p_description TYPES.ARRAY DEFAULT TYPES.EMPTY_ARRAY,
p_qty TYPES.ARRAY DEFAULT TYPES.EMPTY_ARRAY,
p_unit_price TYPES.ARRAY DEFAULT TYPES.EMPTY_ARRAY,)
create or replace procedure save_form (
name_array TYPES.ARRAY DEFAULT TYPES.EMPTY_ARRAY,
values_array TYPES.ARRAY DEFAULT TYPES.EMPTY_ARRAY
I would find maintaining version 1 about a million times easier I believe then version 2.
Your logic of "If
you change forms by adding or deleteing text fields you do not have to worry
about adding/deleteing the parameters in the save/update procedure?" is
fundementally flawed.
Tell me -- if you add something (a new field) to your FORM and you do not modify you save_form routine -- whats going to happen???? (bug). You have to edit the code anyway to add the logic to deal with this new field (ESPECIALLY IF THIS FIELD is added to the middle of the form, sort of shifts all of your indexes no? yes, in fact it would destroying the logic in there... hmmm.) You have to update the code when you do this anyhow -- so what pain is there in documenting for programmers in the future who would otherwise have the unenviable job of getting this "array based" code to try and figure out what it does. (i would hate it myself)
5) never -- as it says clearly:
2.5.2.2 Four parameter interface
The four parameter interface is supported for compatibility.
it is the was OAS (iAS's precursor) did it.