1 2 3 Previous Next 37 Replies Latest reply on Mar 18, 2015 8:57 PM by Fred(CH)

    Get(ModifiedField) doesn't work for new records

    Fred(CH)

      Hi there,

       

      All is in the title .

       

      The Help article state :

       

      Purpose

      Returns a list of fields that have been modified in the current record of the current table.

      […]

      Examples

      When the Invoices::Customer Name and Invoices::Company fields are modified and the record is open, Get(ModifiedFields) returns:

      Customer Name

      Company

       

      And all this is true but… only when the "current record of the the current table", that is "open" indeed, is not newly created ( OpenRecordState = 1 ). In the such case, this Get function returns an empty string.

       

      Jeremiah Hammond posted a bug report to FMI few days ago. But the TS personal (i think in substitution for the product manager) deny that is abnormal and say that they will change the documentation rather the software ! Whats a deal !

       

      I helped Jeramiah because i agreed 100% with him and i posted numerous comments; well, it was like a ping-pong tournament there … My principal arguments were :

      1. if a guy in the world would like the actual behavior, he could perfectly add a simple test before this function ( OpenRecordState = 2 ).
      2. the workaround i provided  -- validate first a blank record on a triggered script

       

      All that prove (to me) that actual behavior doesn't make sense.

       

      Even PhilModJunk, our Community Leader, supported us very clearly but… Silence radio from FMI.

       

      So why I posted here ?

       

      • Maybe ones of you would like to help us, bring his support, and post on the link below.
      • Maybe there is here a person who have an explanation that commit the actual stubbornness of FMI.

       

      Thank in advance for your help guys !

       

      Friendly, Fred

        • 1. Re: Get(ModifiedField) doesn't work for new records
          user14047

          Please return modified field list not only when the record is open, but also when some data is drag and dropped into some field.

           

          レコードが開かれている時だけではなく、フィールドへのドラッグアンドドロップのようにレコードが開かれていない状態での変更でも値を返して欲しい!

          • 2. Re: Get(ModifiedField) doesn't work for new records
            jrenfrew

            This may be unhelpful to you, but has also been talked about in the past several times (I even started one of the threads)

             

            Agreed you might prefer a different behaviour, and agreed that the documentation might not be explicit enough BUT surely until a record has been committed at least once, what is there to compare to, to demonstrate that there has been a change??

            Until the field is committed then it does not 'actually' exist, other than in the world of cache. So if it does not exist, in what sense can it be regarded as get ( AlreadySavedFieldsWithModifiedValues ) - maybe we should suggest a name change to more accurately reflect what the function DOES.

            • 3. Re: Get(ModifiedField) doesn't work for new records
              Fred(CH)

              Thank you Jrenfew.

               

              OK, your answer is exactly the same as FMI's one. But to me, THE point is not a semantic or vocabulary problem, it is functional problem. IMHO, with its behavior, this function is useless in real life.

               

              When you push "delete record" on a record in OpenState 1, imagine if FileMaker Pro was answering you :

              Impossible : this record doesn't exist yet !

               

              It is dangerous to play with semantic….

               

              And the comment of user14047 comfort my idea that this function is only a gadget which gave a moment of pleasure to its developer, whereas it could have been a very powerful tool !

               

              Fred

              • 4. Re: Get(ModifiedField) doesn't work for new records
                jrenfrew

                >>its behavior function is useless in real life

                 

                well not strictly true

                there are cases where it works exactly as expected

                so it's not useless

                 

                it is fair to say that because it does not work as you would like/ or possibly even expect, it is of no use to you

                 

                semantics and language are important.

                • 5. Re: Get(ModifiedField) doesn't work for new records
                  Fred(CH)

                  Dear Jrenfrew,

                   

                  Since many days ago, i try desperately to get an example which can commit this behavior, but without any success, including form the part of FMI.

                   

                  Please note I never said semantic was not important, i said play with it is dangerous.

                   

                  And i love vocabulary…a lot !  But sometimes, i need to work and go ahead.

                   

                  Friendly, Fred

                  • 6. Re: Get(ModifiedField) doesn't work for new records
                    Fred(CH)

                    Sorry user14047 but after some tests, yours seem to be clearly a different issue :

                     

                    When you are doing a drag and drop on a closed record, the OpenRecordState doesn't change and thus, the OnRecordCommit doesn't fire. Note also that the focus doesn't change, the auto-enter calks doesn't fire, etc…

                     

                    But If you modify only "field 1" regularly, making the OpenRecordSate to change, and then do a drag and drop on "field 2", Get(ModifiedField) returns correctly "field 1¶field 2".

                     

                    Bye, Fred

                    • 7. Re: Get(ModifiedField) doesn't work for new records
                      Fred(CH)

                      Please forget my reference to the drag and drop issue : there are two different cases. I stand corrected.

                       

                      Sorry, Fred

                      • 8. Re: Get(ModifiedField) doesn't work for new records

                        The purpose of the function is to create an audit trail. During record modification a developer might want to use a trigger to record the changes to a field to a separate table for historical purposes.

                         

                        By definition every field in a new record is modified when the user enters data into it. What you are asking for is RE-modified, is it not?

                         

                        What value is there in knowing that a user changes data in a field, in an uncommited record, they are entering, one time, two times, etc? Maybe they need to correct a typo.

                         

                        If changes are made to a pre-entered field, that might be noteworty and you could use a trigger to determine that. User changed the default xxx to yyy.

                         

                        Is there any reason to want to know why a user enters Comany name and returns later to change that to Company Name before the record is committed?

                         

                        OK, the real question is why is it important to know that the user modified a particular field in a new, uncommitted record?

                        • 9. Re: Get(ModifiedField) doesn't work for new records
                          Fred(CH)

                          Cannot follow you Jack :

                          The purpose of the function is to create an audit trail. During record modification a developer might want to use a trigger to record the changes to a field to a separate table for historical purposes.

                           

                          I understand this need. But that mean if a user is committing a record accidentally (maybe blank), you will have an audit with a lot more fields than if the record is only committed when the basic entering is really over. It would be more reliable to track ALL modification by the user (for instance when he override a default value) and then have for instance two category or historical record : Creation and Modification.

                           

                          By definition every field in a new record is modified when the user enters data into it. What you are asking for is RE-modified, is it not?

                          As you said : "when the user enters data into it". Sometimes just few field are modified the first time (but i am repeating my self, sorry).

                           

                          What value is there in knowing that a user changes data in a field, in an uncommited record, they are entering, one time, two times, etc?

                          I prefer don't give this idea to FileMaker Engineers. Get reliably a list of modified field on a OnRecordCommit triggered script is difficult enough...

                           

                          If changes are made to a pre-entered field, that might be noteworty and you could use a trigger to determine that. User changed the default xxx to yyy.

                          Easy question : see my first answer. If the user didn't modify anything, OK : he didn't !!!

                           

                          Is there any reason to want to know why a user enters Comany name and returns later to change that to Company Name before the record is committed?

                          If you re read my posts it is not what i am saying.

                           

                          OK, the real question is why is it important to know that the user modified a particular field in a new, uncommitted record?

                          Irrelevant. I also could ask you the same for modified records.

                           

                          Bye bye, Fred

                           

                          Edit : fixed some type errors

                          • 10. Re: Get(ModifiedField) doesn't work for new records
                            coherentkris

                            Fred(CH)

                            You wrote "It would be more reliable to track ALL modification by the user..."

                             

                            If you don't wait for commit then every keystroke, copy, paste et al becomes a modification event.

                            What use would that data be?

                            • 11. Re: Get(ModifiedField) doesn't work for new records
                              Fred(CH)

                              Please apologies my inaccuracy coherentkris :

                               

                              I meant modifications on fields also in a new created record.

                               

                              In conclusion : all is in the title of my post  ...

                               

                              Fred

                              • 12. Re: Get(ModifiedField) doesn't work for new records
                                johnnyb

                                It's the difference between modified on-disk and modified on-screen. Sure, there's nothing to compare it to if the record hasn't been committed, so you can't tell if the field has been modified relative to what is on-disk. That doesn't mean the user has or has not touched the field in the UI, though.


                                It is left to the developer to understand that the function returns a list of fields that have been modified since the last commit. For a new record that has not yet been committed, the behavior is effectively undefined. It should be defined and documented; either it returns all fields because all fields are new since the last (non-existent) commit, or it returns no fields because there is no commit against which they can be said to have been modified. Or maybe even better, it just throws an error for you to handle as you wish.

                                 

                                Separately, if you want to identify the fields that have been touched in the UI, you'll need a different technique. Perhaps it would work to commit the record immediately upon creation before getting modified fields. You might also consider your purpose. For auditing, you'd want to commit all the fields to the audit log, so you don't need the modified fields… if the creation and modification timestamps are the same, just do all the fields, and get individual fields only if needed. For other purposes like form validation, other techniques might apply, perhaps based on keystroke triggers or field exit triggers.

                                 

                                In any case, it's hard to know whether this is a faulty function or if this is confusion caused by one of FileMaker's leaky abstractions. I think it's probably more the latter.

                                • 13. Re: Get(ModifiedField) doesn't work for new records
                                  Fred(CH)

                                  Dear Johnny,

                                   

                                  Thank you for your nogent analysis. I have nothing to add nor contest and I only can thank you for your time.

                                   

                                  However, if you were an FMI engineer, would you really like to deny the abstractions you took 25 year to build ?

                                   

                                  This function actually IS inconsistent with FMP DNA !!! If i would to to manage hard disk I/O, sure i wouldn't had choosen FileMaker as my main production tool.

                                   

                                  A funny example : with 4th Dimension, i would have access to an OLD(Field) calc function that returns the last committed value for the field i want in parameter... Imagine what you could do with that !

                                   

                                  But i preferred FileMaker and still do. This is why i am struggling...

                                   

                                  Big Up and thank you, Fred

                                  • 14. Re: Get(ModifiedField) doesn't work for new records

                                    The Help File Says (13):

                                     

                                    Purpose

                                    Returns a list of fields that have been modified in the current record of the current table.

                                     

                                    A new uncommitted record is NOT the current record.

                                     

                                    Therefore this function has nothing to do with new, uncommitted records, period...

                                     

                                    Further:

                                     

                                    When the Invoices::Customer Name and Invoices::Company fields are modified and the record is open, Get(ModifiedFields) returns:

                                     

                                    The record is NOT OPEN. In fact, it is not yet a record.

                                     

                                    What the user is doing is entering data into fields on a layout and there is no record.

                                     

                                    You can do this:

                                    New Record

                                    Commit Record

                                    go to field xxx

                                     

                                    and NOW having saved the record, you can use modified fields.

                                     

                                    FileMaker was created for  beginners many years ago. It retains that attitude. It has 100,000 beginners using it. FileMaker isn't going to give up that base for one ex-4th Dimension user. I left 4th Dimension at v6 because it was so buggy. I cried and I cried because FileMaker wouldn't...

                                     

                                    FileMaker is just fantastic and easy to use compared to other databases. It needs a few fixes such as telling me if I am connected to the Internet before I waste my time..

                                     

                                    After 30 years, I find myself way out of the loop these days what with all of the things some are doing. Love it...

                                    1 2 3 Previous Next