Forum Stats

  • 3,851,626 Users
  • 2,264,005 Discussions
  • 7,904,793 Comments

Discussions

APEX tabular form update recognition

805153
805153 Member Posts: 9
edited Nov 9, 2010 3:42AM in APEX Discussions
Dear all,

I am quite new to APEX so please apologize if I am asking "stupid" questions. Unfortunately, the information I was able to find up to now was only partially helpful. Apparently I must be missing something obvious. The APEX version I use is 4.0.1.

When submitting a page that contains a tabular form, I need to find out, which record has been created or updated in order to fill in additional information automatically, e.g. logging data (created, last updated, ...). I cannot do this in a trigger, because the trigger sees only APEX_PUBLIC_USER and does not know about the "real" user who has connected to the database. If there is a better or easier way to do this, please let me know.

My problem is to find out, if a new record has been added by clicking the "add row" button and / or if an existing record has been modified, because creation and modification have to be handled differently. Existing and unmodified records in the table must not be touched. I can access the columns by using APEX_APPLICATION.G_Fxx() but how do I recognize modifications? In a thread in this forum I found information about using a MD5 checksum. So I have added a checksum field using APEX_ITEM.MD5_HIDDEN() and tried to check this information. Unfortunately, doing this, I already get a problem when I submit the page after having added an empty record by clicking on "add row" but without having supplied any information. APEX then complains about information that has been modified in the meantime instead of just ignoring the empty record. This is probably because APEX considers the record as changed because of the checksum column I have added (I have read that the SQL query to create the tabular form must not be altered).

Could anybody please show me the right way to do such a check?

Thank you very much for your help.

Best regards,

Ralf Gorholt

Answers

  • fac586
    fac586 Senior Technical Architect Member Posts: 21,197 Red Diamond
    edited Nov 6, 2010 12:08PM
    I cannot do this in a trigger, because the trigger sees only APEX_PUBLIC_USER and does not know about the "real" user who has connected to the database. If there is a better or easier way to do this, please let me know.
    Assuming the "real" user has established their username via authentication in the APEX app, use the PL/SQL method to reference the <tt>APP_USER</tt> built-in value in the trigger:
    nvl(v('APP_USER'), user)
    Please refer to the documentation for more information on APEX built-in substitution strings and user identity:

    http://download.oracle.com/docs/cd/E17556_01/doc/user.40/e15517/concept.htm#sthref151

    http://download.oracle.com/docs/cd/E17556_01/doc/user.40/e15517/sec.htm#BABHIEIA
    fac586
  • 805153
    805153 Member Posts: 9
    edited Nov 7, 2010 9:04AM
    Hello fac586,

    thank you very much for the information. As I wrote, I must be missing something obvious...

    I already knew about these substitution strings and I use them in my application in different places but I was not aware that they can be used in a trigger.

    This solution solves my current problem, but I would still like to know how I can do an update detection in a tabular form myself because I might need it for other purposes.

    Best regards,

    Ralf Gorholt

    P.S. Please excuse the multiple postings. I don't know how this has happened because I am quite sure having clicked the "Post message" button only once. Perhaps an administrator could please delete the double postings? Thank you very much. Ralf

    Edited by: rgorholt on Nov 7, 2010 6:00 AM
  • 805153
    805153 Member Posts: 9
    Hello fac586,

    thank you very much for the information. As I wrote, I must be missing something obvious...

    I already knew about these substitution strings and I use them in my application in different places but I was not aware that they can be used in a trigger.

    This solution solves my current problem, but I would still like to know how I can do an update detection in a tabular form myself because I might need it for other purposes.

    Best regards,

    Ralf Gorholt
  • 805153
    805153 Member Posts: 9
    Hello fac586,

    thank you very much for the information. As I wrote, I must be missing something obvious...

    I already knew about these substitution strings and I use them in my application in different places but I was not aware that they can be used in a trigger.

    This solution solves my current problem, but I would still like to know how I can do an update detection in a tabular form myself because I might need it for other purposes.

    Best regards,

    Ralf Gorholt
  • 805153
    805153 Member Posts: 9
    Hello fac586,

    thank you very much for the information. As I wrote, I must be missing something obvious...

    I already knew about these substitution strings and I use them in my application in different places but I was not aware that they can be used in a trigger.

    This solution solves my current problem, but I would still like to know how I can do an update detection in a tabular form myself because I might need it for other purposes.

    Best regards,

    Ralf Gorholt
  • 725793
    725793 Member Posts: 453
    edited Nov 7, 2010 5:18AM
    Hi Ralf,

    Normally there is a column that represents the ID (primary key) of the current row (hidden). When you add a new row, this has no value and is therefore NULL - until the update/insert is issued.

    Ta,
    Trent
    725793
  • 805153
    805153 Member Posts: 9
    Hello Trent,

    thank you for the information. I already use this method to detect newly added records but how do I detect, if an existing record has been modified or not (like APEX does it with a checksum)? Perhaps I am thinking too complicated and there is a simple solution.

    Best regards,

    Ralf Gorholt
  • 725793
    725793 Member Posts: 453
    edited Nov 7, 2010 2:16PM
    Hi Ralph,

    Well, if you are wanting to check if anything has been updated before the update button is pressed, using JS, you can use the property of the field 'defaultValue' and compare it to the property 'value'
    i.e. for the text input type
    function isElementChanged( myElement ) {
      var iselementChanged = false; 
      var returnVal = false; 
    
      switch ( myElement.type ) { 
      case "text" : 
        if ( myElement.value != myElement.defaultValue )
          return true;
        break;
    default
    	return false;
      }
    }  
    You could cycle through all elements, by:
    allEls = form.elements;
    for (i=0; i < allEls.length; i++){
      if ( allEls<em>.type != undefined && allEls[i].type.length > 0 && allEls[i].disabled == false ) {<br />
    if (isElementChanged(allElls[i])) {<br />
    //TODO: logic here<br />
    }<br />
    }<br />
    }<pre class="jive-pre"><code class="jive-code">Ta,<br />Trent                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
  • 805153
    805153 Member Posts: 9
    Hello Trent,

    thank you very much for the information.

    I will try that.

    Best regards,

    Ralf
This discussion has been closed.