CODEWITHSUNDEEP
oracle-databaseplsqloracleforms
Jarrod Nettles
Jarrod Nettles

Reputation: 6283

Oracle Forms - Commit Single SQL Statement Instead of Entire Form

I'm working on an Oracle Form (10g) that has two blocks on a single canvas. The top block is called QUERY_BLOCK which the user fills out to fill PRICING_BLOCK with rows of data.

However, in QUERY_BLOCK I also have a checkbox which needs to perform an INSERT and DELETE on the database, respectively. My WHEN-CHECKBOX-CHANGED trigger looks like this:

begin
    if :query_block.profile_code is not null then

        if :query_block.CHECKBOX_FLAG = 'Y' then
            begin
                INSERT INTO profile_table VALUES ('Y', :query_block.profile_code);
            end;
        else
            begin
                DELETE FROM profile_table WHERE profile_code = :query_block.profile_code and profile_type_code = 'FR';
            end;
        end if;
    end if;
end;

I know that I need to add some sort of commit statement in here, otherwise the record locks and nothing actually happens. However, if I do a COMMIT; then the entire form goes through validation and updates any changed rows.

How do I execute these one-line queries I have without the rest of my form updating as well?

Upvotes: 2

Views: 7523

Answers (1)

DCookie
DCookie

Reputation: 43523

Without commenting on the actual wisdom of this, you could create a procedure in the database that performed an autonomous transaction:

CREATE OR REPLACE FUNCTION my_fnc(p_flag IN VARCHAR2) 
  RETURN VARCHAR2 IS
  PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
  IF p_flag = 'Y' THEN
    INSERT...
  ELSE
    DELETE...
  END IF;
  COMMIT;
  RETURN 'SUCCESS';
EXCPTION
  WHEN OTHERS THEN
    RETURN 'FAIL';
END;

Your Forms code could then look like:

begin
    if :query_block.profile_code is not null then
      stat := my_fnc(:query_block.CHECKBOX_FLAG);
    end if;
end;

This allows your function to commit independent of the calling transaction. Beware of this, however - if your outer transaction must roll back, the autonomous transaction will still be committed. I would think there should be a transactional way to do what you need done to solve your locking problem, which would likely be the superior approach. Without knowing the specifics of your process, I can't tell. Generally speaking, autonomous transactions are used when an update must occur regardless of whether the transaction commits or rolls back, e.g., logging.

Upvotes: 2

Related Questions