Pre-query trigger firing twice

I have a pre-query trigger on a block in a form to set the "default where" as
SET_BLOCK_PROPERTY (BLOCK_ID, default_where,where_clause);
but when I look at the current query for the session the where clause looks like
WHERE screening_group_num = :1 AND (screening_group_num = :2)
Why is this firing twice?
I checked this thread : Re: pre-query firing twice but I dont have any calls to execute_query in the form.

I am setting the where_clause in the pre_query trigger for that block.
and the copy value is not set for the screening_group_num item or for that matter any other item in the block. For all other items, it dosent really matter if the comparison is done twice (as the values will be same) , but when I have text (string) items, then its a problem. For example:
Where
(event_description LIKE '%test%') --- this is from the pre_query trigger where I am doing a string_comparison using 'Like and %%'
AND (event_description = :1) --i suppose this is from the default where clause of the block

Similar Messages

Pre-query trigger issue

Hi,
I have a datablock in the form that is based on a DB table. There are few queriable fields in the block including begin and end dates. If i dont use any pre-query trigger, the records are queried fine. But I want to do a range selection between begin and end_Date fields. Therefore I created a pre-query trigger and set a new_where_clause with all my query_fields and set that as defualt where for my DB block.
SET_BLOCK_PROPERTY (block_id,default_where, where_clause);
But when I see the query in toad session , the query looks like
WHERE (field_1 = :1) and field_1 = :1
that means its running the defualt where clause on the block and the new_where clause at the same time.
I checked the form and I dont have any calls to execute query....
what can be the problem?

1. What is your new_where_clause? (example, please)It's hard to read. Use the \{code\} tag.
FUNCTION get_comparison_phrase (database_column_name       VARCHAR2,
                                                         relational_operator       VARCHAR2,
                                                         selection_field_name       VARCHAR2)
          RETURN VARCHAR2 IS
     BEGIN
          RETURN CASE
                          WHEN NAME_IN (selection_field_name) IS NOT NULL THEN
                                    ' AND '
                               || database_column_name
                               || relational_operator
                               || ' :'
                               || selection_field_name
                          ELSE
                               NULL
                     END;
     END get_comparison_phrase;
where_clause := 'WHERE (1=1)';
if NAME_IN (selection_field_name) IS NOT NULL THEN       ' AND '
                               || database_column_name
                               || relational_operator
                               || ' :'
                               || selection_field_name
                          ELSE
                               NULL
                     END;
where_clause :=
     where_clause
          || get_comparison_phrase (
                    'screening_group_num',
                    '=',
                    'EXCEPTIONAL_EVENTS.screening_group_num'
WHERE (field_1 = :1) and field_1 = :1I do not see 'WHERE (1=1)'; there.
Edited by: Michael Roy on Oct 21, 2009 9:47 AM

Pre-Query Trigger

In one of our form ( we generated this from Oracle Designer), we put the Pre-Query trigger to the first block of the form, where we override the default_where so that it includes something liek this
INSTR (cpb_order_title, 'housing', 1, 1) > 0 AND INSTR (cpb_order_title, 'review', 1, 1 )> 0
But when during execution, we found that alongwith the above filter, it also appends the regular default_where to the above condition. Something like this
INSTR (cpb_order_title, 'housing', 1, 1) > 0 AND INSTR (cpb_order_title, 'review', 1, 1 )> 0
AND ( UPPER (cpb.cpb_order_title) LIKE :1
AND (cpb.cpb_order_title LIKE :2 OR cpb.cpb_order_title LIKE :3)
Could not find how it is adding the default condition. Any help would be very much appreciated.
Thanks
Deb

Debra,
So, this is the default WHERE clause on the block?
AND ( UPPER (cpb.cpb_order_title) LIKE :1AND (cpb.cpb_order_title LIKE :2 OR cpb.cpb_order_title LIKE :3)>
I don't see anything in your code that would cause the new where clause to be appended to the original where clause, unless you have code somewhere else that automatically sets the default where clause programatically.
The fact that your code sample sets the block where clause to an empty string ( '' ) if the order_title is NULL makes me wonder why you have a DEFAULT_WHERE defined in the first place. Not to mention the fact that the first thing your Pre-Query trigger does is set the DEFAULT_WHERE to an empty string as well. My first suggestion is to simply eliminate the WHERE property default value.
What is the output of your call to "MESSAGE_POPUP?" Is the original WHERE clause listed in the resulting Alert? Have you displayed the contents of the vQuery variable before the DEFAULT_WHERE assignment and if so what it the output?
Craig...

PRE-QUERY not firing

I have a Form that has 4 cascading List Item after you make a chose on the Bpost_Tag (4th) you press the Button Execute Query. On the Data Block I have PRE-QUERY as shown below! What I’m trying to get in return is if you chose Bpost_Tag 100 you will get all Bpost_Tags 100 and greater on the Form. Right now all I’m getting in return is one Bpost_Tag of 100.
Data Block
PRE-QUERY
DECLARE
               wh_clause VARCHAR2(200);
BEGIN
               IF :PMISCURR.SYSTEM is not null then
               wh_clause := 'SYSTEM = '||:PMISCURR.SYSTEM;
          END IF;
               IF :PMISCURR.COUNTY is not null then
               wh_clause := wh_clause ||' AND COUNTY = '||:PMISCURR.COUNTY;
          END IF;
               IF :PMISCURR.ROUTE is not null then
               wh_clause := wh_clause ||' AND ROUTE = '||:PMISCURR.ROUTE;
          END IF;
               IF :PMISCURR.BPOST_TAG is not null then
               wh_clause := wh_clause ||' AND BPOST_TAG >= '||''''||:PMISCURR.BPOST_TAG ||'''';
          END IF;
          Set_Block_Property ('PMISCURR', DEFAULT_WHERE, wh_clause);
END;
The Go_Block ('PMISCURR'); is on the Execute Query Button.
Edited by: Monty on May 13, 2011 12:06 PM

Andreas
Based on the same Table!*
DATA BLOCKS:
PMISCURR
..........SYSTEM
..........ROUTE
..........COUNTY
..........BPOST_TAG
PMISCURR1
..........SYSTEM_1
..........ROUTE_1
..........COUNTY_1
..........BPOST_TAG_1
I moved the PRE-QUERY as is to PMISCURR1 still got all the values from the Database Table/PMISCURR_BPOST_TAG. I changed the SQL to point to PMISCURR1 and got the same results. I’m just having hard understanding what is wrong. I have asked several coworkers to take a look at it and all they say is it should work my guess is they don’t know either!
Changed POST-QUERY on PMISCURR!
DECLARE
wh_clause VARCHAR2(200);
BEGIN
IF :PMISCURR1.SYSTEM_1 is not null then
     wh_clause := 'SYSTEM_1 = '||:PMISCURR1.SYSTEM_1;
END IF;
IF :PMISCURR1.COUNTY_1 is not null then
     wh_clause := wh_clause ||' AND COUNTY_1 = '||:PMISCURR1.COUNTY_1;
END IF;
IF :PMISCURR1.ROUTE_1 is not null then
     wh_clause := wh_clause ||' AND ROUTE_1 = '||:PMISCURR1.ROUTE_1;
END IF;
IF :PMISCURR1.BPOST_TAG_1 is not null then
     wh_clause := wh_clause ||' AND BPOST_TAG_1 >= '||''''||:PMISCURR1.BPOST_TAG_1 ||'''';
END IF;
Set_Block_Property ('PMISCURR1', DEFAULT_WHERE, wh_clause);
END;
Monty

Setting item "database property" properties at pre-query trigger ?

Hi all,
I have a "from clause query" form and try to execute according
to some field value that correspond to different queries.
but my problem is ;
to run from clause query form, all items should be Database item at the same block.
So how can I set some item database properties to yes/No
Is there any build in to achieve this?
Thanks in advance.
Regards,
Defne

Hi all,
I have a "from clause query" form and try to execute according
to some field value that correspond to different queries.
but my problem is ;
to run from clause query form, all items should be Database item at the same block.
So how can I set some item database properties to yes/No
Is there any build in to achieve this?
Thanks in advance.
Regards,
Defne

Join with another table in pre-query

Hi,
We have a large data block and we need to order some columns based on street name for example, not id. The base table of db block contains an id_street column, and 'streets' table contains id and name.
Ok, in pre-query trigger of that block, we have a complex logic and we dynamically build the where clause. At the end, we set the order_By clause of the block, to order the rows, for example we need to order by the 'my_date' column asc (it's a date type column), and street desc; but street NAME, not id. We don't want to use a from clause query, because the dynamically where clause logic it's complex.
How can we join the db block table with 'streets' table in pre-query, so when constructing the order by clause to specify something like
set_block_property('ADRESE_NEZONATE', order_by, 'my_date, name desc');where 'name' is the name of the street, from the 'streets' table.
Is it possible in pre-query, somehow? Or, in my case where can I join with that table and use that column in pre-query at setting order by?
Thanks!
Edited by: Roger25 on 26.04.2013 12:31

I understand what you say but partially.. please explain in more detail how to do that;
How should look the adrese_nezonate block, then? I have to add a 'name' column and set copy value from item property to 'STREETS.NAME', and database_property No?
Then the post-query trigger how should look like (the order by clause)? The post-query sends the entire query (with where/order by clauses) to the server, but in that "select... where... order by" (built dynamically) there are only columns from that block (adrese_nezonate). I need to join with streets, INSIDE that query.
Thanks.

Pre-insert trigger is not firing after post built-in

Hi,
I have a 10g form in which Post built-in is used in When-button-pressed Trigger. After the post command I am checking some condition,by using the same record which I have posted.But it is not working.
I have also put the message in the pre-insert trigger but the message is not displaying.
But the same form iis working fine in form 6i, as I have migrated the forms from form 6i to 10g.

Yes, In that block there are other items also. I have made the required property no for all the items.
what exactly we have is
(if x=y then)on some condition check
POST;
After that, form have a select statement in which it is selecting the same row which is being posted above.
if the select statement gives count of row zero
raise form_trigger_failure is fired.
and in the pre-insert trigger form is assigning a value to a block item.

Custom Trigger on MTL_SYSTEM_ITEMS_B firing twice from Item form

Hi ,
I wrote a custom trigger on MTL_SYSTEM_ITEMS_B for after update. When ever an item is update from the seeded Items Form, it is firing twice. When I do it from back end it is working fine. Any insights or fixes into issue will be much appreciated.
Thanks.

Obtain FRD log file to find out why the trigger is fired twice.
R12: Forms Runtime Diagnostics (FRD), Tracing And Logging For Forms In Oracle Applications (Doc ID 438652.1)
Steps To Take FRD Trace in 11.5.10 & R12 (Doc ID 867943.1)
R12: How To Create An FRD (Forms Runtime Diagnostic) Log Using Forms 10g (Doc ID 445166.1)
How To Collect And Use Forms Trace (FRD) in Oracle Applications Release 12 (Doc ID 373548.1)
Thanks,
Hussein

Pre-Insert Trigger not firing

Hi,
I am using Oracle 10G DS with Oracle 11G XE. I tried PRE-INSERT Trigger with the Code given by Mr Hamid. However, its not working. Though, the WHEN-NEW-ITEM-INSTANCE works fine, I wish to use PRE-INSERT Trigger only.
Can you please help me.
My Code is shown below
BEGIN
SELECT asset_id_seq.nextval INTO :r_it_blk.asset_id
FROM dual;
END;
Thanks in advance
Ramesh

Hi Hamid,
Thank you very much for your reply.
I tried at Block Level itself. Further, I also tried the below Code with Cursor (Block Level). Unfortunately, it is also not working. Even the Error Message is also not displayed. The User has full privileges.
DECLARE
     CURSOR next_id IS SELECT asset_id_seq.NEXTVAL FROM dual;
BEGIN
     OPEN next_id;
     FETCH next_id INTO :r_it_blk.asset_id;
     CLOSE next_id;
     IF :r_it_blk.asset_id IS NULL THEN
     Message('Error Generating Next Asset ID');
     RAISE Form_Trigger_Failure;
     END IF;
END;
Regards
Ramesh

Post-query trigger ? save changes?

I have a similar problem to that posted by 'nova' on Dec. 27, 2000. I have a form generated by Designer. The problem is that upon subsequent querying (F8 pressed twice), it asks me if I want to save my changes, when I have not made any changes.
I looked in the generated code for the post-query trigger and found SET_RECORD_PROPERTY(:SYSTEM.TRIGGER_RECORD, 'NEW_CUST', STATUS, QUERY_STATUS) which is apparently not the problem, according to this prior post. I am at a loss and have tried everything I could think of.
What else could be causing this? I checked to see if there were any items being set in the property sheet to default values, and removed the defaults - that did not work.
??? I would greatly appreciate any assistance. Thanks.

Hi Pina,
my similar problem I have solved like this:
Post-Record trigger:
BEGIN
*** this is important to test the record status - without this I had the same problem
IF :SYSTEM.Record_Status='INSERT' THEN
IF :TRANZIT_ZADAJ.ID_SADZBY_TV_PRENOSOV IS NULL THEN
:TRANZIT_ZADAJ.ID_SADZBY_TV_PRENOSOV:=:SADZBY_ZADAJ.ID;
END IF;
END IF;
END;
You can check Pre-... and Post-... triggers
if there are any items being set to any values.
I hope this will help you.
Helena

Forms trigger Firing Sequence

Does anyone know where I can find details on firing sequence of each type of triggers on Item, Block and Form levels?
Can I set the Debugger to trace the actual sequence of firing of triggers at run-time?
Message was edited by:
wyfwong

i hope that the document may help!
(V45) Trigger Execution Sequence in Forms 4.5
=============================================
Introduction
This document lists the order in which triggers fire in Oracle Forms 4.5:
o The first column, Action, describes the function to be performed
(e.g. deleting a record).
o The second column, Trigger Firing Order, describes the order
in which triggers fire after a function is performed.
o The third column, Level, describes the level (form, block, item)
at which the trigger fires. This was accomplished by creating a form
with all the triggers invoked. If a trigger could fire at all levels,
it was included at all levels. Such a trigger fires at the lowest level
at which it is defined.
Key triggers and triggers which fire via buttons or check boxes are
not included.
This bulletin does not cover every contingency and covers only the
most commonly used actions.
Action Trigger Firing Order Level
Runform 1. Pre-Logon Form
2. On-Logon Form
3. Post-Logon Form
4. Pre-Form Form
5. When-Create-Record Block
6. Pre-Block Block
7. Pre-Record Block
8. Pre-Text-Item Item
9. When-New-Form-Instance Form
10. When-New-Block-Instance Block
11. When-New-Record-Instance Block
12. When-New-Item-Instance Item
Enter Query 1. Post-Text-Item Item
2. Post-Record Block
3. When-Clear-Block Block
4. When-New-Record-Instance Block
5. When-New-Item-Instance Item
Note: If you define the Key-ENTQRY trigger, this is the only trigger
which fires in an Enter Query situation.
Execute Query
After Enter Query 1. Pre-Query Block
2. Pre-Select Block
3. On-Select Block
4. When-Clear-Block Block
5. Post-Select Block
6. On-Fetch Block
7. On-Close Form
8. When-Clear-Block Block
Note: If you define the Key-EXEQRY trigger, this is the only trigger
which fires in an Execute Query situation.
Execute Query
Without Enter
Query 1. Post-Text-Item Block
2. Pre-Query Block
3. Pre-Select Block
4. On-Select Block
5. Post-Select Block
6. On-Fetch Block
7. On-Close Form
8. When_Create_Record Block
9. Pre-Record Block
10. Pre-Text-Item Item
11. When-New-Record-Instance Block
12. When-New-Item-Instance Item
Exit 1. Post-Text-Item Item
2. Post-Record Block
3. Post-Block Block
4. Post-Form Form
5. On-Rollback Form
6. Pre-Logout Form
7. On-Logout Form
8. Post-Logout Form
Next Field and
Previous field 1. When-New-Item-Instance Item
Next Record and
Previous Record 1. When-New-Record-Instance Block
2. When-New-Item-Instance Item
Next Block and
Previous Block 1. Post-Text-Item Item
2. Post-Record Block
3. Post-Block Block
4. When-Create-Record Block
5. Pre-Block Block
6. Pre-Record Block
7. Pre-Text-Item Block
8. When-New-Block-Instance Block
9. When-New-Record-Instance Block
10. When-New-Item-Instance Form
Records Are Queried 1. Post-Query Block
2. Post-Change Block
3. Post-Change Item
4. Post-Change Block
5. Post-Change Block
Go back to Post-Query
NOTE: This cycle is repeated for each record retrieved.
No Records Are Queried 1. When-New-Record-Instance Block
2. When-New-Item-Instance Item
NOTE: To observe this Trigger Firing Order:
a. Enter a query.
b. Enter a nonexistent record.
c. Execute the query.
The two triggers listed above, the Enter Query triggers, and
the Execute Query triggers fire.
Create Record 1. Post-Change Block
2. When-Validate-Item Block
3. Post-Text-Item Block
4. When-Validate-Record Block
5. Post-Record Block
6. Post-Block Block
7. On-Savepoint Form
8. Pre-Commit Form
9. Pre-Insert Block
10. On-Insert Form
11. Post-Insert Block
12. Post-Forms-Commit Form
13. On-Commit Form
14. Post-Database-Commit Form
15. Pre-Block Block
16. Pre-Record Block
17. Pre-Text-Item Block
18. When-New-Item-Instance Form
Update Record 1. When-Database-Record Block
2. Post-Change Block
3. When-Validate-Item Block
4. Post-Text-Item Block
5. When-Validate-Record Block
6. Post-Record Block
7. Post-Block Block
8. On-Savepoint Form
9. Pre-Commit Form
10. Pre-Update Block
11. On-Update Block
12. Post-Update Block
13. Post-Forms-Commit Form
14. On-Commit Form
Here the transaction is complete and one record added.
15. Post-Database-Commit Form
16. Pre-Text-Item Block
17. When-New-Item-Instance Form
NOTE: To observe this Trigger Firing Order:
a. Execute a query.
b. Change a value.
c. Choose Action->Save from the menu.
d. Record the triggers from that point.
Delete Record 1. On-Lock Block
2. When-Remove-Record Block
3. Post-Change Block
4. Post-Change Block
5. Post-Change Block
6. Post-Change Block
7. Post-Change Block
8. Post-Change Block
9. Post-Change Item
10. Post-Query Block
11. Post-Text-Item Block
12. Post-Record Block
13. Pre-Record Block
14. Pre-Text-Item Block
15. When-New-Record-Instance Block
16. When-New-Item-Instance Form
NOTE: To observe this Trigger Firing Order, delete a detail record.

After Update Trigger executes twice when single row is uptd thro proc

We have the below trigger in our db. When a single record is updated using a procedure the trigger is executed twice and it inserts two records in other table.
But when i issue an update statement using any sql client tool it is executing only once and inserts only one record in other table.
Can any one please help me to find the reason?
Trigger:*
create or replace TRIGGER CX_HEADER_ESCL_T1 AFTER UPDATE OF STATUS ON CX_HEADER
FOR EACH ROW
DECLARE
"b1-CTRIYJ" boolean := FALSE;
BEGIN
IF UPDATING('STATUS') AND(:NEW.status = 'SUCCESS') THEN
"b1-CTRIYJ" := TRUE;
END IF;
IF "b1-CTRIYJ" = TRUE THEN
INSERT
INTO siebel.s_escl_req(req_id, created, bt_row_id, rule_id, tbl_name, created_by, group_id)
VALUES('11111111', CURRENT_DATE, :NEW.row_id, '1-CTRIYJ', 'CX_HEADER', :NEW.last_upd_by, '1-2CU3');
"b1-CTRIYJ" := FALSE;
END IF;
END;
Procedure:
CREATE OR REPLACE
PROCEDURE CLOSE_BATCH
(ChildRecordCount IN NUMBER, HeaderId IN VARCHAR2, CompletionStatus OUT VARCHAR2) AS
CafeChildCount NUMBER;
BEGIN
select count(*) into CafeChildCount from SIEBEL.CX_CHILD where HEADER_ID=HeaderId;
IF ChildRecordCount = CafeChildCount THEN
update SIEBEL.CX_HEADER set STATUS ='SUCCESS', MODIFICATION_NUM = MODIFICATION_NUM+1 where HEADER_ID=HeaderId;
CompletionStatus := 'SUCCESS';
ELSE
update SIEBEL.CX_CHILD set STATUS='FAILED' where HEADER_ID=HeaderId;
update SIEBEL.CX_HEADER set STATUS='FAILED' where HEADER_ID=HeaderId;
CompletionStatus := 'FAILED';
END IF;
commit;
/*CompletionStatus := 'SUCCESS';*/
EXCEPTION
WHEN OTHERS THEN
CompletionStatus := SQLCODE;
rollback;
END;

Your problem seems not be related to the trigger restart issue I have already mentioned because you are using a AFTER UPDATE trigger and not a BEFORE UPDATE trigger:
>
BEFORE Triggers Fired Multiple Times
If an UPDATE or DELETE statement detects a conflict with a concurrent UPDATE, then Oracle Database performs a transparent ROLLBACK to SAVEPOINT and restarts the update. This can occur many times before the statement completes successfully. Each time the statement is restarted, the BEFORE statement trigger is fired again. The rollback to savepoint does not undo changes to any package variables referenced in the trigger. Your package should include a counter variable to detect this situation.
>
If you are sure that you update a single row and that your trigger fires twice and if you can easiily reproduce the issue, I recommend that you contact Oracle Support and create a Service Request for your issue that could be an Oracle bug.

Sequence of trigger firing in forms 6i

hai,
please reply soon ..
i need full details about sequence of trigger firing when form initiate,
query mode,modify mode,delete mode and insert mode in forms 6i .
regards,
B.prakash

please look into the forms 6i online help manuals. There are the trigger flows of all events

Post-query trigger order for data blocks in master detail relationship

Using Forms [32 Bit] Version 10.1.2.2.0 (Production) Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production.
I have the following problem with a form I am working on. It has a master data block with multiple detail data blocks. I am trying to create a post-query trigger on one of these detail blocks that will do a select using the value of a field from another of the detail blocks.
The problem is that the post-query trigger of the data block I am trying to do the select with is firing before the post-query trigger of the block I need the value from is firing. I tested by just putting in a display message and having it return the value of the id I am tryign to use. Right after I do a query on the form, I get the messages saying:
"Error: cannot find price for id:" and there is no id, and then the message from the other datablocks post-query saying, "id is: 123"
Is there a way to change the order that the datablocks are queried? Or should I be using a different trigger to do this?

Do you mean as it is displayed in the object navigator? It's not the first block under the data block section, but it is above the other block that is exceuting before it, so I assumed the order in that did not matter.
EDIT: Thanks Magoo! That solved the issue.
Edited by: a small rabbit on Sep 4, 2009 11:28 AM

Pre-Query - Modifying the default_where

Hi,
I'm trying to get the value of the default_where clause to modify it (with set_block_property) after the user has entered the ENTER QUERY MODE and decides to RUN QUERY. I'm creating a Pre-Query event for the module component where the search criteria are entered, but it doesn't seem to work; the where_clause (l_old_where) I retrieve is always empty. My code to retrieve the default_where is:
BEGIN
DECLARE
l_block VARCHAR2(32) := name_in('system.trigger_block');
l_old_where VARCHAR2(2000);
BEGIN
l_old_where := get_block_property(l_block, default_where);
message('l_old_where =' || l_old_where); --unfortunately this message always returns an empty value
EXCEPTION
WHEN VALUE_ERROR THEN
qms$forms_errors.push(QMS$FORMS_ERRORS.MSGGETTEXT(33, 'Query criteria too complex - simplify and re-query'), 'E', 'OFG', 33);
qms$forms_errors.raise_failure;
END;
END;
Does anybody know what I am doing wrong? Do you have a better way to retrieve the default_where value?
Thanks,
Denis.

Denis,
The DEFAULT_WHERE is part of all queries. It is set either in the property palette at design time, or programatically at runtime. If a user does an enter query and specifies some criteria, that criteria is appended to the DEFAULT_WHERE. Thus, interrogating the DEFAULT_WHERE won't help you in this case.
There is no "nice" way to do this. You have about three triggers you can choose from, that get fired after the users has entered their criteria, but before the query is executed. One is PRE-QUERY, and I forget the other two. One of them is SET-QUERY or something like that.
What you do is interrogate the fields themselves. For example, if you have two fields: NAME and SALARY, and the user entered the criteria "A%" and ">5000", then it's up to you to examine those fields to see what the user typed. Then you can do with them what you will.
So you don't get the SQL that Forms generates, but you do get the same info that Forms uses to generate the SQL.
There is also a gotcha to look out for. When referring to fields in a block that are active during enter-query mode, use the NAME_IN builtin. For example, the SALARY field is of type number, but the criteria is ">5000". That ">" is not acceptable (normally) to a NUMBER field, so you will get errors if you do something like "message('Salary criteria: '||:block.salary);"
I hope this helps.
Regards,
Robin Zimmermann
Forms Product Management

Pre-query trigger firing twice

Similar Messages

Maybe you are looking for