Automatically commit

Hi Guys!
I have a master details form in Oracle Form 10g. In my master block I have a list item. Depending on the value I choose in that list I make changes in the details block and I call a procedure that do lots of insert in some database tables. The problem is if I want to exit that form or navigate to another record without committing the data, I have an alert that asks me if I want to commit the changes. Eventhough I choose No, The changes are committed.
I want to change this behavior. I know that I have to use a rollback but I dont know in what trigger I have to put it?
Thank you for your help
gbardet

You have several issues here. When you get that alert asking if you want to save your changes, I assume it is the standard alert issued by Forms. If you say Yes, that you want to save your changes, Forms posts the updates you made to your detail block and (I think) issues a commit.
If you say no, Forms clears the block, therefore backing out the changes you made to the detail block, but I don't think it does a rollback. It next does an execute_query on the detail block to keep the Master-Detail in sync. Someplace in the process that keeps the Master/detail data in sync, you could probably do a Forms_DDL('Rollback'); and that would back out the changes your procedure made to database tables.
The exit form problem is a separate problem. You can test Form_Status yourself in the key-exit trigger, and issue your own alert. If the user does not want to commit, issue a clear_form(full_rollback), and then exit.

Similar Messages

Automatic commit

Hi
We have implemented an application with jheadstart. Now, we have a new user requeriment for implement "automatic commit". It means that the modificacions on a page must be saved without the user press the button "save".We are trying to implement it with the event "setCurrentRowWithIndex", every time the user move to other register, we want that automatically the application saves the changes. We implemented it in the following way:
- Add commit to the event setCurrentRowWithIndex
<event name="setCurrentRowWithIndex" source="FrmGastoPadre">
<compound>
<invoke method="doIt"
javaType="oracle.jbo.uicli.binding.JUCtrlActionBinding"
instance="${bindings.Commit}"/>
<set target="${bindings.DeptIterator}"
property="currentRowIndexInRange"
value="${ui:tableSelectedIndex(uix, Dept')}"/>
</compound>
</event>
- Also, we added the method setCurrentRowWithIndex to multiRowUpdateEvent form value.
<formValue name="multiRowUpdateEvent" value="setCurrentRowWithIndex"/>
These work more or less. The changes are saved, but the execution order of events is confussing. Like in the previous code, we want commit first and then we want to set the currentRowIndexInRange(move to the next/other register). But, when we execute the code the orden is the oposite, first the currentRowIndexInRange property is set and after it executes the commit. This changes in order of events is confussing, what we are doing wrong? why the events execute in that order if we specify another ?
Thanks in advance.
Liceth

Thank you, the document is very helpful. We have other question. How can we pass a parameter (like id of a row) in a button or primaryClientAction event ?
For example, It's easy with a link:
href="DeleteEmployees.do?event=removeEmployee&id=<c:out value='${Row.Empno}' />"
But, how can we do it with a button event like:
<submitButton event="MyEvento" formName="dataForm"
textAndAccessKey="${nls.SAVE_BUTTON}"/>
or with a event throwed in a primaryClientAction?
<primaryClientAction>
<firePartialAction source="FrmDept"
event="MyEvent"
targets="messageBox _uixState FrmGastoHijo"/>
</primaryClientAction>
Thanks in advance

Automatic commit work after class method?

Hi guys,
after calling a class method, is there an automatic commit work? Or do I have to insert a commit work into the class method?
At which points, a commit work is automatically called?
Regards,
Basti

Hi,
there is so much confusion about commit, commit work and rollback:
1. At the end of LUW and at every interruption (screen display including message issued, RFC calls,...) an implicit database commit occurs.
2. COMMIT WORK will trigger all update task processes that have been registered before (call function in update task, perform on commit). Most BAPI functions use perform on commit. An implicit database commit ist not a COMMIT WORK.
3. Rollback work will delete all pending update tasks inclusing all database updates not yet commited.
4. Only the 'Master'of any process should rule the COMMIT WORK because COMMIT WORK means that ALL pending update tasks are executed. So only the caller on top of the hierarchy should issue the COMMIT WORK because a later ROLLBACK is not possible - ROLLBACK only works if not y<et committed.
These rules work independent of programming feature used - nothing different in oo.
Regards
Clemens

Automatic commit/rollback when debugging

Hi,
A colleague of mine who I asked to use SQL Developer instead of TOAD for debugging, was very surprised to found his debug session to have committed at the end. TOAD doesn't. He lost a lot of time undoing the unintended changes.
He made me remember I went to the same thing when I first used sqldev.
Instead of automatically assuming you want to commit or rollback, this really should be asked on successful completion. Or set a preference: ask, commit, or rollback.
Anyone who agrees, please vote on the added feature request: http://htmldb.oracle.com/pls/otn/f?p=42626:39:1493919074214847::NO::P39_ID:28041
Thanks,
K.

It's not really a bug, but a nasty feature.
You can only vote on the mentioned request to add weight for future implementation.
Until then you can put a breakpoint before completion, and when halted there, stop execution with the red stop button.
Have fun,
K.

Automatic comm channel when assigning Business system during configuration

Hi all,
In scenario file to file during Configuration,
During assigning business system there is a check box:
 'Create communication channels automatically' 
I am planning to use File adapter on both receiver and sender side..
The question is Do I check this box or not ? If I do check this box it creates for me HTTP adapter ...Do I need it or not? I am clearly only using file adapter
thanks all !
Jon

U cannot use it in ur scenario. This function is supported for the following adapter types:
- XI Adapter
- HTTP Adapter
- IDoc Adapter
- RFC Adapter
See this
http://help.sap.com/saphelp_nw04/helpdata/en/42/d1a4d665c5574fa6e19784358ec948/content.htm
Regards,
Prateek

Suggestions for Automatic Commit/Rollback

Consider the following scenario:
A list page displays all of the records currently stored in a table. A user clicks on a link on the list page that fires the Create event and takes them to another page for entering the details of the new record. The user decides they made a mistake and clicks their browser's Back button to abort the process. There is now a new, unpopulated record on the list page.
What is the best way to handle this situation if the user cannot be concerned with manual Commits or Rollbacks? Committing after the new record details are submitted seems okay, but rolling back every time the list page is loaded renders the First/Previous/Next/Last navigation buttons useless.
Thanks,
Ryan

Create Action in ADF JSP bindings is meant to create and insert a new row into collection (and if the dataControl in action is ADFBC, then it also marks the row as temporary/initialized as indicated above).
To achieve the backbutton support, for such cases in ADF apps, we recommend using a cancel operation that is bound to 'delete' Action on the iterator which 'removes' the newly created temporary row from the collection so that it's not visible in the collection at all.
Using browser back button after create action will result in the temporary new row in the collection as noted above.
This was designed as per numerous feedback on OTN for our previous JSP solution for creating new rows where a number of teams complained about duplicate row creation on a create row action. You could still achieve this as suggested above by creating a new and initialized row and then copying it's values on the form and then removing the row and then recreating another new row on submit. Note that that requires extra copying of all display values etc and in ADF we decided to avoid that route.

Do I have to add commit in SQL Server stored procedure

In SQL Server, any statement not within a transaction is automatically commit. for example, single statement "INSERT INTO Table" is commit automatically. but in PL/SQL, you have to issue "COMMIT" after the statement. Since I have about 500 stored procedures need to be migrated from SQL Server to Oracle, Does any one has any solution for me, so I don't need to add "Commit" statement after every "Insert into Table" or "Update table" single statement.
Thanks

Jimmy,
I can't think of any short cuts, only to at least commit at the end of each stored procedure as opposed to after each stmt.

JDBC adapter Commit/Rollback

Hi Guys, I got a question regarding JDBC adapter auto commit. Hopefully you guys can help me :). Until now, when my XI calling a storedprocedure in ORACLE using JDBC adapter, it will automatically commit the calling. When i see my configuration for the JDBC adapter receiver, the checkbox for Enable Autocommit is thicked. My question is, is there anyway that we handle the commit or rollback ourself. How we can handle that? Is it from the BPM or just from the Configuration.
Thank you very much in advance for all replies, advices and answer. Cheers guys..

Hi
Try this out
You can programmatically set auto commit to true as in follows
// Load the Oracle JDBC driver
DriverManager.registerDriver(new oracle.jdbc.OracleDriver());
// Connect to the database
// You can put a database hostname after the @ sign in the connection URL.
Connection conn =
DriverManager.getConnection ("jdbc:oracle:oci:@", "scott", "tiger");
// It's faster when auto commit is off
conn.setAutoCommit (true); 
// Create a Statement
Statement stmt = conn.createStatement ();
regards
krishna

Forms 6i / Auto-Commit-Mode

How can i make Forms 6i to do an automatic commit after entering a value into a database-item?
null

Thank you very much!
<BLOCKQUOTE>quote:<HR>Originally posted by Sandeep Biswas ([email protected]):
Write a key-exit trigger with the following code:
if :system.form_status = 'CHANGED' then
commit_form;
/* if commit failure */
if :system.form_status <> 'QUERY' then
/* display error */
raise form_trigger_failure;
end if;
end if;
exit_form;<HR></BLOCKQUOTE>
null

Why there is implicit commit before and after executing DDL Statements

Hi Guys,
Please let me know why there is implicit commit before and after executing DDL Statements ?
Regards,
sushmita

Helyos wrote:
This is because Oracle has design it like this.Come on Helyos, that's a bit of a weak answer. :)
The reason is that it makes no sense to update the structure of the database whilst there is outstanding data updates that have not been committed.
Imagine having a column that is VARCHAR2(50) that currently only has data that is up to 20 characters in size.
Someone (person A) decides that it would make sense to alter the table and reduce the size of the column to varchar2(20) instead.
Before they do that, someone else (person B) has inserted data that is 30 characters in size, but not yet committed it.
As far as person B is concerned that insert statement has been successful as they received no error, and they are continuing on with their process until they reach a suitable point to commit.
Person A then attempts to alter the database to make it varchar2(20).
If the database allowed that to happen then the column would be varchar2(20) and the uncommitted data would no longer fit, even though the insert was successful. When is Person B going to find out about this? It would be wrong to tell them when they try and commit, because all their transactions were successful, so why should a commit fail.
In this case, because it's two different people, then the database will recognise there is uncommitted transactions on that table and not let person B alter it.
If it was just one person doing both things in the same session, then the data would be automatically committed, the alter statement executed and the person informed that they can't alter the database because there is (now) data exceeding the size they want to set it to.
It makes perfect sense to have the database in a data consistent state before any alterations are made to it, hence why a commit is issued beforehand.
Here's something I wrote the other day on the subject...
DDL's issue a commit before carrying out the actual action
As long as the DDL is syntactically ok (i.e. the parser is happy with it) then the commit is issued, even if the actual DDL cannot be executed for another reason.
Example...
We have a table with some data in it...
SQL> create table xtest as select rownum rn from dual;
Table created.
SQL> select * from xtest;
        RN
         1We then delete the data but don't commit (demonstrated by the fact we can roll it back)
SQL> delete from xtest;
1 row deleted.
SQL> select * from xtest;
no rows selected
SQL> rollback;
Rollback complete.
SQL> select * from xtest;
        RN
         1
SQL> delete from xtest;
1 row deleted.
SQL> select * from xtest;
no rows selectedSo now our data is deleted, but not committed, what if we issue a DDL that is syntactically incorrect...
SQL> alter tab xtest blah;
alter tab xtest blah
ERROR at line 1:
ORA-00940: invalid ALTER command
SQL> rollback;
Rollback complete.
SQL> select * from xtest;
        RN
         1... the data can still be rolled back. This is because the parser was not happy with the syntax of the DDL statement.
So let's delete the data again, without committing it, and issue a DDL that is syntactically correct, but cannot execute for another reason (i.e. the database object it refers to doesn't exist)...
SQL> delete from xtest;
1 row deleted.
SQL> select * from xtest;
no rows selected
SQL> truncate table bob;
truncate table bob
ERROR at line 1:
ORA-00942: table or view does not exist
SQL> rollback;
Rollback complete.
SQL> select * from xtest;
no rows selectedSo, there we have it. Just because the statement was syntactically correct, the deletion of the data was committed, even though the DDL couldn't be performed.
This makes sense really, because if we are planning on altering the definition of the database where the data is stored, it can only really take place if the database is in a state where the data is where it should be rather than being in limbo. For example, imagine the confusion if you updated some data on a column and then altered that columns datatype to be a different size e.g. reducing a varchar2 column from 50 character down to 20 characters. If you had data that you'd just updated to larger than 20 characters whereas previously there wasn't, then the alter table command would not know about it, would alter the column size and then the data wouldn't be valid to fit whereas the update statement at the time didn't fail.
Example...
We have a table that only allows 20 characters in a column. If we try and insert more into that column we get an error for our insert statement as expected...
SQL> create table xtest (x varchar2(20));
Table created.
SQL> insert into xtest values ('012345678901234567890123456789');
insert into xtest values ('012345678901234567890123456789')
ERROR at line 1:
ORA-12899: value too large for column "SCOTT"."XTEST"."X" (actual: 30, maximum: 20)Now if our table allowed more characters our insert statement is successful. As far as our "application" goes we believe, nay, we have been told by the database, we have successfully inserted our data...
SQL> alter table xtest modify (x varchar2(50));
Table altered.
SQL> insert into xtest values ('012345678901234567890123456789');
1 row created.Now if we tried to alter our database column back to 20 characters and it didn't automatically commit the data beforehand then it would be happy to alter the column, but then when the data was committed it wouldn't fit. However the database has already told us that the data was inserted, so it can't go back on that now.
Instead we can see that the data is committed first because the alter command returns an error telling us that the data in the table is too big, and also we cannot rollback the insert after the attempted alter statement...
SQL> alter table xtest modify (x varchar2(20));
alter table xtest modify (x varchar2(20))
ERROR at line 1:
ORA-01441: cannot decrease column length because some value is too big
SQL> rollback;
Rollback complete.
SQL> select * from xtest;
X
012345678901234567890123456789
SQL>Obviously, because a commit statement is for the existing session, if we had tried to alter the table column from another session we would have got
SQL> alter table xtest modify (x varchar2(20));
alter table xtest modify (x varchar2(20))
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified
SQL>... which is basically saying that we can't alter the table because someone else is using it and they haven't committed their data yet.
Once the other session has committed the data we get the expected error...
ORA-01441: cannot decrease column length because some value is too bigHope that explains it

Turn off "Commit Transform" or make middle click return?

Hi All,
I'm finding that having to click the "commit transform" check mark after every adjustement to be annoying. Is there a way to automatically commit transform by clicking a new layer? or make middle click commit the transform?
thx,
jayson

You should be able to click insde the transform handles to commit the transform or switch tools.
Depending your mouse driver you might be able to assign the enter/return key to the middle mouse button.

Error creating job into trigger using DBMS_SCHEDULER.

Hi,
I am trying to create job using dbms_scheduler package. I have one trigger on insert event on one table. I am creating job using following syntax.
CREATE OR REPLACE TRIGGER TRG_BI_JOB_CONFIG BEFORE INSERT ON JOB_CONFIG FOR EACH ROW
DECLARE
BEGIN
     DBMS_SCHEDULER.Create_Job(job_name => 'my_job1'
                         ,job_type => 'PLSQL_BLOCK'
                         ,job_action => 'delete_temp'
                         ,start_date => TO_DATE('15-JUL-2003 1:00:00 AM', 'dd-mon-yyyy hh:mi:ss PM')
                              ,repeat_interval => 'FREQ=DAILY'
                         ,enabled => TRUE
                         ,comments => 'DELETE FOR job schedule.');
EXCEPTION
WHEN OTHERS THEN RAISE;
END;
but I am getting following error while inserting into JOB_CONFIG table.
ORA-04092: cannot in a trigger
ORA-06512: at "PRAKASH1.TRG_BI_JOB_CONFIG", line 41
ORA-04088: error during execution of trigger
same above statement If I am running from sqlplus then It is creating job without error. If I am creating job using DBMS_JOB into trigger then It is also working fine but this package is depricated from oracle10g so I cannt use it any more.
My Oracle version is 'Oracle DATABASE 10g RELEASE 10.2.0.1.0 - Production'.
can anyone help me in this context.

I have a few comments on this thread as an Oracle dbms_scheduler developer.
- Oracle takes backward compatibility very seriously. Although dbms_job is deprecated, the interface will continue to work indefinitely. The deprecation of dbms_job is so that customers will be encouraged to take advantage of the more powerful dbms_scheduler. It is extremely unlikely that entire blocks of functionality will ever be removed. There is currently no plan to remove dbms_job functionality (and even if there were, doing so would be strenuously opposed by many users).
- lots of internal Oracle database components are standardizing on using dbms_scheduler (resource manager, materialized views, auto sql tuning etc). This is good evidence that it will continue to be the recommended scheduling method for the foreseeable future - not even the concept of a replacement exists. It is also under active development.
- The reason for the automatic commit is that a dbms_scheduler job is a full database object like a stored procedure or a table. So a call to dbms_scheduler.create_job is like executing a DDL which takes effect immediately. A dbms_job job is mostly just a row in a table so a call to dbms_job.submit behaves like regular DML. There are many advantages to a job being a full database object but DDL behaviour is an unfortunate requirement of this.
Hope this clears a few things up, reply with any questions.
-Ravi

Data Loss when a database crashes

Hi Experts,
I was asked the question of "how much data is lost when you pull the plug off an oracle database all of a sudden".. and my answer was "all the data in the buffers that have not been committed". We know that you can have committed data sitting in the redo logs (that have not been written to the datafiles) that the instance will use for recovery once the instance is restarted again; however, this got me thinking and asking the question of how much uncommitted data is actually sitting in memory that potentially can be lost if the instance goes down all of a sudden?
With the use of sga_target and sga_max_size, the memory allocation for the cache buffer will vary from time to time.. So, is it possible to quantify the amount of lost data at all (in byts, kb, mb..etc)?
For example if the sga is set to 1gb (sga_max_size=1000mb), check point every 15mins (as we can't predict/know how often the app commits).. assume a basic transaction size for any small to medium size database. Redo logs set to 50mb (even though this doesn't come into play at this stage).
I would be really interested in your thoughts and ideas please.
Thanks

All Oracle Data Manipulation Language (DML) and Date Definition Language (DDL) statements must record an entry in the Redo log buffer before they are being executed.
The Redo log buffer is:
•     Part of the System Global Area (SGA)
•     Operating in a circular fashion.
•     Size in bytes determined by the LOG_BUFFER init parameter.
Each Oracle instance has only one log writer process (LGWR). The log writer operates in the background and writes all records from the Redo log buffer to the Redo log files.
Well, just to clarify, log writer is writing committed and uncommitted transactions from the redo log buffer to the log files more or less continuously - not just on commit (when the log buffer is 10mb full, 1/3 full, every 3 seconds or every commit - whichever comes first - those all trigger redo writes).
The LGWR process writes:
•     Every 3 seconds.
•     Immediately when a transaction is committed.
•     When the Redo log buffer is 1/3 full.
•     When the database writer process (DBWR) signals.
Crash and instance recovery involves the following:
•     Roll-Forward
The database applies the committed and uncommitted data in the current online redo log files.
•     Roll-Backward
The database removes the uncommitted transactions applied during a Roll-Forward.
What also comes into play in the event of a crash is MTTR, for which there is a advisory utility as of Oracle 10g. Oracle recommends using the fast_start_mttr_target initialization parameter to control the duration of startup after instance failure.
From what I understand, uncommitted transactions will be lost, or more precisely undone after an instance crash. That's why it is good practice to manually commit transactions, unless you plan to use SQL rollback. Btw, every DDL statement and exit from sqlplus implies an automatic commit.
Edited by: Markus Waldorf on Sep 4, 2010 10:56 AM

ADF Toystore question: no blank row in viewobject on "Add" JSP form

A new thread based on Suggestions for Automatic Commit/Rollback
In the ADF Toystore application, I did not notice the blank row behavior in the user registration section like we encountered in the other thread posting (Suggestions for Automatic Commit/Rollback To test this, I created another instance of the Accounts viewobject (called it AllAccounts) inside the ToyStoreService app module and then created a JSP to list the contents of the AllAccounts viewobject. Then, I went to the registration page (which creates a blank row in the view object with a status of STATUS_INITIALIZED) and then without submitting the form, I clicked on the link that I created to view the contents of the AllAccounts view object and noticed that a blank row did not appear. What is causing a blank row to appear in our discussions in the other thread (Suggestions for Automatic Commit/Rollback but not in the ADF Toystore application? I guess somehow this row with a status of STATUS_INITIALIZED is being "removed" but I cannot find the code that does this.
Steve -- any ideas?

I was trying to figure out what would be the best practice to implement 'partial rollback'. Could not really find the example in Toy Store demo. For example if we create new account, the model will get dirty. And let's say user does NOT commit the record but rather uses link and navigates to some other pages. After some work user may commit the transaction which in turn will commit blank entry in account table. Well for the sake of example let's assume that this is possible scenario.
So what I am up to is how to implement 'cancel' operation when user changes his/her mind and does something else rather then commit/save_changes in new/edit screens? What would be the best practice?
What I have done so far is rather too bulky. I have implemented event handler for all my links and cancel button in data page:
   * "Cancel" Event Handler.
   * @param ctx The DataAction context
public void onCancel(DataActionContext ctx) {
    HttpServletRequest request = ctx.getHttpServletRequest();
    BindingContext bcc = HttpBindingContext.getContext(request);
    DCBindingContainer dbc = DCUtil.findBindingContainer(bcc, "modifyAddSchedulingUIModel");
    DCIteratorBinding studentCat = dbc.getIteratorBinding("AddModifyScheduleView1",null , "AddModifyScheduleView1Iterator");
    Row currentRow = studentCat.getNavigatableRowIterator().getCurrentRow();
    currentRow.refresh(Row.REFRESH_REMOVE_NEW_ROWS | Row.REFRESH_WITH_DB_FORGET_CHANGES);
    dbc.getApplicationModule().getTransaction().commit();
    String target = "individual";
    ctx.setActionForward(target);
Any other idea?

Copy data from one Table to another Table

How can I copy data from one Oracle Table to another Oracle Table on a different server? Question 2: How can I clear all of the data in one Table with a single SQL script?
Thanks...

Question 1:
I assume you have the privileges. If you don't, ask the DBA to give them to you. Then
1. Login to database_source (It could be either the source or the target. Let's assume it's the source.)
2. Create a database link to database_target: CREATE DATABASE LINK link_to_database_target CONNECT TO myuserid IDENTIFIED BY mypassword USING 'database_target'; Note the single quotes.
3. Copy the table data: INSERT INTO targetowner.mytable@link_to_database_target SELECT * FROM sourceowner.mytable; COMMIT;
Question 2:
You have two options, but you may not have privileges for both.
Option 1:
DELETE FROM tableowner.tablename; COMMIT;
Advantage: Since this is a DML (Data Manipulation Language) statement, you have to commit the transaction. Also, the data will be gone but the table size is NOT changed, so it's ready for accepting replacement data. DML statements can simply be executed not only from SQL scripts, but from PL/SQL scripts as well.
Disadvantage: Slow, because all record deletion is logged, so you can recover from it by issuing a ROLLBACK; instead of the COMMIT; above. The table size is NOT changed, so if you are short of disk space or tablespace space, you have not resolved the issue.
Option 2:
TRUNCATE TABLE tableowner.tablename;
Advantage: Since this is a DDL (Data Definition Language) command, you do NOT have to commit the transaction. (DDL commands automatically commit both before and after their execution.) The table size will be changed back to the initial extent size which is the minimum size a table can have and can only be set when the table is created. If it needs to be changed, the table has to be dropped and recreated with a different initial extent size. The statement execution of this command is not logged, therefore it's much faster then the DELETE.
Disadvantage: No rollback. Being a DDL, this command cannot be executed straight from PL/SQL. If you need to issue this within PL/SQL, you will have to use dynamic SQL.

Automatically commit

Similar Messages

Maybe you are looking for