Triggers no fire on SuSe80 Linux

My platform is SuSe Linux 80 and Developer Suite 9i.
My forms compile fine, but triggers no fire.
When I make : unset NLS_LANG - everything is fine - triggers fire.
Where is problem ?
NLS_LANG is my national setting, not AMERICAN_AMERICA...

Sorry, folks. Forgot the obvious. Compiling on the destination architecture fixed the problems.

Similar Messages

Trigger no fire on SuSe80

My platform is SuSe Linux 80 and Developer Suite 9i.
My forms compile fine, but triggers no fire.
When I make : unset NLS_LANG - everything is fine - triggers fire.
Where is problem ?
NLS_LANG is my national setting, not AMERICAN_AMERICA...

the actual requirement is like this:
i have 2 tables one is having data about the total capacity of rooms in resort. that is refer by the one which is used to keep the record of booked rooms. and that trigger or scheduler is to reclaim the rooms capacity when time ends as you know room is booked for hourly basis. and this is just a simple example theres more of this type where one thing is booked and reclaimed again.Rahul,
I according to this logic - i don't think job is useful in this regard.
Question is why?
Just follow your current proposed solution ->
You say whenever room booked you will start the job though trigger to see whether you can reclaims that room or not.
Now, how do you get to know - the room is free or not? For that there must some other transaction will be taken place by any front end (or by any other application) which is validating inside in your procedure and your job continuously check that value through procedure. Am i right?
So, your job is not sufficient alone to decide that main issue whether it is ready to reclaim the room or not, except if you want to display this information to the owner about the probable available rooms after a specific time? In that case, you need this job. But, this will not show the actual available room. Correct me if i'm wrong - up to this explanation.
As a result, if we can tap that transaction which will ultimately taken place by any front end (or some other application to ensure that) then we can reclaim the room, and can directly put our trigger into that transaction without the job, thus reducing the overhead and complexity of the current logic.
I may be wrong - or not understood or missed some important place of your logic. So, please share your thought in this regard.
Regards.
Satyaki De.
Edited by: Satyaki_De on Oct 12, 2008 1:46 AM

Triggers doesn't work on Linux

Does anybody know why triggers doesn't work on Linux machine? Forms are developed in WIN2k and triggers works there fine. When the forms are transferred to linux triggers doesn't work anymore.
I use Oracle 9i database and Forms 9i and Linux Redhat Advanced Server.

Forms are compiled on Linux either by opening them in the builder and hitting compile or by using the compiler from the command line:
Use the script $ORACLE_HOME/bin/f90genm.sh (or f60genm.sh if this is 6i).
So if you are developing on Windows and running in Linux, you woudl FTP the FMB, MMB and PLL files to the Linux box and compile using f90genm.

Linux forms6i+patch 1 : no triggers will fire

Hi there:
We are having significant problems w/ our Redhat 6 linux box as our forms server. (We're opting for apache 1.3 instead of OAS (for right now).) The linux box is running 6i w/ patch 1.
The form appears fine and interacts w/ key strokes and tabs, but absolutely no trigger will fire. No when-button-pressed, no post-query, no key-next-items -- not a thing. If I take the exact same .fmx (compiled on a w2k box) to an NT box running forms 6i server, it works correctly.
Interestingly enough, when a new client loads the f60cgi base page, it prompts the user to download jinitiator 1.1.7.31, but in order to run the form, the client must have 1.1.7.30 (otherwise nothing happens). Maybe there is some sort of synch problem?
We're also using a netscape client since IE shows no cursor, and tabs don't work.
Any help greatly appreciated.
Thanks,
Charlton

Sorry, folks. Forgot the obvious. Compiling on the destination architecture fixed the problems.

HOW can I get a STATUS OF TRIGGERs TO FIRE CORRECTLY ???

Hi all,
I had trouble with a migrated DB (7.3.4 -> 9.2.04) why all important TRIGGER did not fire (Business Rules).
I could see all TRIGGERS WAS VALID with:
SELECT a.object_name FROM all_objects a
WHERE a.object_type = 'TRIGGER'
AND a.status = 'INVALID'
AND a.owner = Decode(Upper('SCHEMA'), 'ALL',a.owner, Upper('SCHEMA'));
but they DID NOT FIRE !!! (After recompiling all works well)
This is a production DB and I must:
- simulate this state - HOW can I do it ?
- HOW can I select this TRIGGER STATE in my PRODUCTION
system to re-compile this triggers ???
I must prevent this state on triggers before the user writes data from Forms to the Database:
if NOT TRIGGER_FIRE('Trigger') then RECOMPILE('Trigger'); end if;
Has anyone a good solution ?
Thanks in advance
Friedhold

Are you sure the triggers have been correctly imported? That they have been imported in the right user schema?
I remember having some problems with triggers when importing in an Oracle 8.0.5 database: the triggers got to be on tables in another schema.
And are they enabled?
Check the sys.all_triggers view:
select * from all_triggers where owner = &my_schema
and see the status column if it is "ENABLED".

Triggers not Fire in Logical Standby

Hi,
I'still have this question even after reading some post in this forum concerning creating Triggers in a Logical Standby
Let's see this Case.
MY Primary
Table A Trigger A1 Fire into > Table A1
MY Logical - Just Created as New
Table A Trigger A1 Fire into > Table A1 >>>> This Is a copy of the Primary Structire
IF I want to add a new Trigger into Table A I get :
Table A Trigger A2 Fire into > Table A2 >>>>> This is after
My Logical Structure will become:
Table A Trigger A1 Fire into > Table A1 >>>>> This belongs to the initail Strcuture
Trigger A2 Fire into > Table A2 >>>>> This Added After
My Question?
When the log are being applied on the Logical and obviously inserts into TABLE A will occur ... will Trigger A2 Fire into Table A2 ?
I hope I make myself understandable ...
Thxs for your Help

I know it's quite a long-time that anyone replied this post, but I just need to report our attempts to workaround that.
Dropping function-based indexes in primary database, just before creation of Logical Dataguard hasn't solved our problem, neither dropping indexes in logical database.
In my opinion and after some docs in metalink, I think there's no way to solve it.
Or you drop them or you migrate to 10g.
Regards.

When do Navigation triggers not fire?

hi there! I read this statements below, but i cannot understand. Can anybody give more illustration or example? tx.
"The Pre- and Post-navigation triggers do not fire if they belong to a unit that is lower in the hierarchy than the current validation unit. For instance, if the validation unit is Record, Pre- and Post-Text-Item triggers do not fire."

At design time in property palette, and also at runtime with Set_Form_Property( VALIDATION_UNIT ).
Look at the online help documentation.
Francois

List of triggers which fire in enter query mode?

hello experts , please tell me list of forms trigger which fire in enter query mode?
thanks
yash

I don't believe there is a published list, but if you check the Forms help system the description of each trigger will tell you if it fires in "Enter Query" mode. Unfortunately, you will need to check each trigger in the help system and build your own list.
Craig...

Query: Can we write Triggers in a Packages??

Hi Al

Triggers provide a way of executing PL/SQL code on the occurrence of specific database events. For example, you can maintain an audit log by setting triggers to fire when insert or update operations are carried out on a table. The insert and update triggers add an entry to an audit table whenever the table is altered.
The actions that Informix Dynamic Server triggers perform are constrained to multiple insert, update, delete, and execute procedure clauses; whereas, Oracle allows triggers to execute arbitrary PL/SQL code. Oracle triggers are similar to stored procedures in that they can contain declarative, execution, and exception handling code blocks.if you mean trigger call package, yes!
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_7004.htm
Edited by: Surachart (HunterX) on Jun 14, 2009 8:46 PM

Question on triggers in master-detail from

I'm a bit confused on what triggers will fire when in master-detail as follows:
If I understand correctly the post-query trigger in the master block will fire during query processing for each record, but not again when you use previous record or next record, unless the record needs to be fetched again.
In the detail block, are the records fetched each time, and post-query trigger fires, for a new instance of the master record or only once the first time they are queried? In other words, is the execute_query built in executed each time for the detail block when there is a new instance of the master record.

Never mind, found my answer.

Related to Triggers exists in the form

Hi All,
I am working on forms customization.I just want to know the sequence of the firing triggers exists in the form.(Form Level,Block Level,Item Level)
Could you please let me know the sequence.
Thanks & Regards,
Dhanasurya

Normally the order of the trigger firing is
1st Item level triggers
2nd Block level triggers
3rd Form level triggers
You need to specify the event* and existing triggers, if u need to know the names of triggers that fires for that event.

After and before triggers

My doubt is about the execution of triggers
I have a table T1
create table T1
+(ID1 number(9,2) primary key,+
NAME1 VARCHAR2(100)) ;
It has following 2 rows.
insert into t1 values (1,'sandeep')
insert into t1 values (2,'tom')
commit;
I have following 4 triggers
create or replace
TRIGGER TRIGGER1_before_statement
before update on T1
begin
dbms_output.put_line('fired before statement');
END;
create or replace
trigger TRIGGER_BEFORE_EACHROW
before update on T1 for each row
begin
DBMS_OUTPUT.PUT_LINE('fired before each row');
END;
create or replace
TRIGGER TRIGGER_after_eachrow
after update ON T1
FOR EACH ROW
begin
DBMS_OUTPUT.PUT_LINE('fired trigger after eachrow');
END;
create or replace
trigger TRIGGER1_AFTER_STATEMENT
after update on T1
begin
dbms_output.put_line('fired after statement');
END;
i ran the following script
SET SERVEROUTPUT ON;
begin
update T1 set T1.ID1=1 where T1.ID1 = 2;
end;
This update statement will fail because it violates the primary key constraint on the table.
During execution of the update statement, i expect only the before statement and row triggers to fire because after triggers will be fired after execution of the statement and in this case the update execution has failed.
But the output i am getting is
fired before statement
fired before each row
fired trigger after eachrow
which means the after TRIGGER_after_eachrow has also fired but my update statement has failed and TRIGGER_after_eachrow should fire only after updating the rows.
Why this trigger was fired? If oracle processes all the triggers even if the triggerig statement fails, then why TRIGGER1_AFTER_STATEMENT was not fired.
Thanks in advance.

Hi Sandeep,
While trying to search for the answer to your after trigger execution related issue, I got below from asktom site where I got a discussion regarding the same topic.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:29259877603106
Below is the exact question post by one member and answer by tom in it.
I thought
Here is some sample which shows that after row statement fires event though the integrity
constraint check should have failed first.
Me and my colleagues are confused with the definition found at
http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/triggers.htm#sthref3288
drop table emp;
drop table dept;
-- Create table
create table DEPT
ID    NUMBER not null,
name VARCHAR2(100)
alter table DEPT add primary key (ID);
create table EMP
ID      NUMBER not null,
NAME    VARCHAR2(100),
DEPT_ID NUMBER
alter table EMP
add primary key (ID);
alter table EMP
add constraint EMP_DEPT_FK foreign key (DEPT_ID)
references DEPT (ID);
create or replace trigger EMP_AFT_INS_ROW_TRG after insert on emp for each row
declare
    n number;
begin
    select 1 into n from dept where dept.id = :new.dept_id;
exception
    when no_data_found then
        raise_application_error(-20001, 'No such department');
end;
insert into dept(id, name) values (1,'First department');
commit;
insert into emp (id, name, dept_id) values (101, 'First employee', 1);
commit;
rem here I expect a foreign key violation message instead of 'No such department' application error
insert into emp (id, name, dept_id) values (102, 'Second employee', 2);
commit;
Followup   September 5, 2006 - 5pm Central time zone:
constraints technically are validated AFTER the statement executes - it is not really defined
whether a trigger will or will not fire (and if you have logic that depends on such intricate
ordering, we have a really big logic problem)
but a for each row trigger - sure, because tables are allowed to violate their constraints during
the DML, think about this:
update emp set empno = empno+1;
every row updated could temporarily violate uniqueness as there could be two empno =2, empno=3 and
so on as this goes through row by row. May be its useful to you..
Regards,
Dipali..

OGG and firing triggers

Hi,
I am designing and implementing OGG to replicate a set of about 200 tables from a master system to two target systems. Updates to these tables only occur on the master system so this is a 1:n uni-directional situation. The master and target systems are all Oracle.
Some or all of the target tables have triggers on them. For 95% of the tables, we don't want the triggers to fire when GG replicates to the table. This is easily accomplished by using the SUPPRESSTRIGGERS subparameter of the DBOPTIONS parameter in the replicat parameter file. So, I set up one extract/pump/replicat process to replicate the data to these tables.
Of the remaining 5% of the tables, most of the time we want the triggers to fire on the target systems when data is replicated to the target table. Again this is easily accomplished by setting up another extract/pump/replicat process with DBOPTIONS NOSUPPRESSTRIGGER.
There are a couple of tables on the target systems which have more than one trigger and we want one of the triggers to fire when replicating but not the other ones. I believe that I can partly accomplish this by putting a SQLEXEC on the MAP statement for these tables which issues an ALTER TRIGGER <schema.trigger>; DISABLE. The documentation says this SQLEXEC will run before the data is replicated to the target table so the trigger will be disabled when the replication happens.
My problem is... How do I enable the trigger again once I have replicated data to the target table? I don't think it's possible to have a SQLEXEC run after the replication happens. Is that true?
I have considered simply disabling the triggers when replication starts with a standalone SQLEXEC statement that runs when replication starts and enabling them using SQLEXEC ONEXIT to enable the triggers again when replication stops. this will work but I'm not sure my customer will buy this solution.
Thanks a lot for any help you can provide.

I've figured out how to do this. Start the replicat with DBOPTIONS SUPPRESSTRIGGERS specified. Then run a standalone SQLEXEC which executes the following stored procedure call for each trigger you want to have fire: dbms_ddl.set_trigger_firing_property(<trigger_owner> '<trigger_name>', FALSE);
I have a set of eight triggers I want to fire so I created a simple stored procedure that executes this SP for each of my triggers. It could probably be done inline in the replicat parameter deck too.
Also, I have a second SP which I call using SQLEXEC ON EXIT. This disables all the triggers I enabled at the beginning.
Looking at ALL_TRIGGERS at the FIRE_ONCE column/property will tell you what state a trigger is in. Ironically, NO means the the trigger will fire and YES means it will not.

Timer fires during trigger processing on web

I was looking for a way to augment the default behaviour
of a hierarchical tree. The trouble is clicking in a tree can fire various combinations of WHEN-MOUSE-CLICK, WHEN-TREE-NODE-SELECTED, WHEN-TREE-NODE-EXPANDED,
WHEN-TREE-NODE-ACTIVATED, WHEN-MOUSE-DOUBLE-CLICKED. I wanted to trigger some action after they had finished firing but as I didn't know which would fire last, where to put the code ?
The solution I found was to start a 1 ms timer in WHEN-MOUSE-CLICK (which always fires first), gather information from the other triggers into a variable, and do my processing in WHEN-TIMER-EXPIRED. This worked fine on client/server but when I deployed it on the web I found the timer expired between WHEN-MOUSE-CLICK and WHEN-TREE-NODE-SELECTED (triggered by a single click).
My understanding of timers is that, however short their duration, they should not expire during trigger processing. Have I got this wrong or is this a bug ?
It seems to work OK with 5 ms but I would like to know what is going on.
(f6i patch 7)

All,
as promised, here's an answer from development. Duncan said it already, but here's the long version
1). Regarding timers in general. 1ms timers fire on the server (effectively,
at the time the timer is created in a trigger, we put a timer macro on the
stack so that that next time we go for input (after we've processed all
of the events we've already gotten at that point), it will act as if the timer
has expired. This, as you know, prevents us from doing round-trips to the
client when people are simply creating a timer to get around some of the
restricted built-in/trigger issues. Any timer of longer than 1ms will get
created on the client and thus cause round-trips. We have no plans to
bump that threshhold up, so people could use 2ms timers if they wanted...
2). Regarding timers expiring during trigger processing. It is true in both
client/server and web that we will not expire a timer while a trigger is
firing. However, the order in which the user will see events (and thus
which triggers will fire in) can vary. In the example that was given,
the user (double)clicks on a node in the tree on the client. The first
mouse click causes a message/event to be sent immediately to the
server, which ends up causing the when-mouse-clicked trigger to fire.
As soon as that message is sent, the server starts processing that
trigger. In the meantime, the client may decide that it needs to send
other messages (such as when-node-selected, etc.). However, until
the server sends a return-message to the client asking for more input,
this won't get sent. Now, the server fires the when-mouse-click trigger,
and as part of it a timer gets created. There are two possible scenarios
here.
In the first scenario, the timer is 1ms, and thus is handled on the
server. Thus, when the trigger ends, the server sees if there is any more
input to be processed, and sees that the timer has expired (because, as
I explained above, this gets put directly onto the macro stack). Thus, the
timer expired trigger fires. After that trigger fires, the server sees that it
has no more input waiting, and sends a message to the client telling it to
send more input. At that point, the client can send whatever other events
it has queued up (such as the when-node-selected) and we carry on.
In the second scenario, the timer is more than 1ms long. In this case, when
the trigger says to create a timer, the server queues up a message to send
to the client telling it to create a timer. When the rest of the trigger is complete
and the server sees that it has no more events to process, it sends this timer
creation message to the client at the same time it asks the client to give it
more events. The client sends the when-node-selected event, the server
processes it, and eventually asks the client for more input. By then, the
timer has expired and then the timer message gets sent to the server.
In neither of these cases does the timer trigger fire in the middle of
another trigger that is already firing, it is simply that the separate triggers
might fire in a different order because of the order that the underlying
events are processed. In client/server, the process is effectively the same
as the 2nd scenario above, because the timer is handled by the toolkit, just
like the other events, and thus the message for the timer expiring will get
sent to Forms after any of the events related to the mouse click. But again,
the rule about timers firing during trigger processing is not violated, it is just
that there is a break between triggers that can allow a 1ms timer to fire
'sooner' on the web than in client/server.
Fran

Triggers and EJB ?

I have an EJB container managed, and I want to add an entry with an ID that is normally set by a BEFORE INSERT trigger. That trigger ask a sequence and set the ID.
Unfortunately, the EJB is always try to add ID = 0, even if I don't set the ID. Is it a bug of Oracle8i, or is there a way to fire automatically the trigger ?
Thanks
cyril ZEKSER

LuckyJim1006 wrote:
No triggers created by me, no. ( I would have no idea how to :-) )
This is where my inexpierence shows. All I have from them are the statements above.
All I have done is a whole bunch of SELECT statements, an INSERT script I wrote to populate an empty table with lookup values and a single DELETE statment on a test row of data.Was this empty table an important table in production environment or was it a test table that you had created?
If it was important from production point of view, you should be reverting the changes that you have done (inserts, updates and delets).
If it was a test table that you only had created, I don't think it will have anything to do with the database becoming "corrupt" as per software supplier.
Am I correct in saying that Triggers are fired irrespective of the software used to to access the database ?
So no matter if it's SQL*Plus, SQLDeveloper, a Java app or an Oracle Forms app the Triggers still fire.Yes. Triggers fire for an operation against a table; the operation source can be anything.
>
And do Oracle objects (tables etc) actually need to be 'recompiled'Only the stored executable units (like procedures, functions, triggers, packages) need to be compiled. Tables cannot be compiled.

Triggers no fire on SuSe80 Linux

Similar Messages

Maybe you are looking for