5 Replies Latest reply on Jul 20, 2018 4:13 PM by tramachandran

    AFSDkUpdateOptions.Insert Behaviour Inconsistemt with documentation ?

    hmadlink

      Hi ,

      I am using AFUpdateOptions.Insert to update values using the AFData.updateValue method.

      i might be missing something, or might be understanding it wrong

      the Documentation Request Rejected  says option insert will "Add the value to the archive. Any existing values at the same time are not overwritten."

      but in my example i am changing the same attribute with the same value with the same timestamp.

      according to what i understand all three entries should be inserted in the piarchive but when i see the archive editor i see two rows inserted but the third one is ignored.

      secondly

      if we have two values that are the same and the third value differs (the timestamp is same for all the three values).

      the archive only has two entries and one of the old entries is overwritten.is this the expected behaviour of option insert ?

      Thanks.

        • Re: AFSDkUpdateOptions.Insert Behaviour Inconsistemt with documentation ?
          vkaufmann

          Hi,

           

          Can you please share the snippet of code you are running, the version of the AF SDK, and version of the PI Data Archive you are writing to?

           

          --Vince

            • Re: AFSDkUpdateOptions.Insert Behaviour Inconsistemt with documentation ?
              hmadlink

              Hi,

              DeleteAttributes("\\AdlinkOffice1\\Partition3|Temp"); //this clears the archive of the values for the Attribute Temp

              for the first question in which 2 rows are entered only

              double ts = DateTime.UtcNow.Ticks; //ts is the timestamp passed to the function that sets it in AFValue.Timestamp

              the ChangeAttrib function under the hood uses AfAttribute.Data.UpdateValue(AFValue, AfUpdateOption.Insert);

              The AFValue object is created on the fly.

               

              tb1.ChangeAttrib("Temp", "900", "Partition3", ts); //this calls the Affunctions with AFUpdateUption.Insert

              tb1.ChangeAttrib("Temp", "900", "Partition3", ts);//this calls the Affunctions with AFUpdateUption.Insert

              tb1.ChangeAttrib("Temp", "900", "Partition3", ts);//this calls the Affunctions with AFUpdateUption.Insert

               

              for the second question everything is the same but the values change in the following sequence

              tb1.ChangeAttrib("Temp", "900", "Partition3", ts); //this calls the Affunctions with AFUpdateUption.Insert

              tb1.ChangeAttrib("Temp", "900", "Partition3", ts);//this calls the Affunctions with AFUpdateUption.Insert

              tb1.ChangeAttrib("Temp", "901", "Partition3", ts);//this calls the Affunctions with AFUpdateUption.Insert

               

              AFSDK version 2.9.5.8352

              AFServer 2.9.1.8159

              Archive Version 2016 R2

            • Re: AFSDkUpdateOptions.Insert Behaviour Inconsistemt with documentation ?
              tramachandran

              This is expected behavior and is due to compression being applied to the events.

              The initial 2 values that you see correspond to a value in the archive and snapshot(will be archived depending on the next event or compmax). If you were to write a different value at the same timestamp you should be left with only one value of each. 

              You can use AFUpdateUption.InsertNoCompression to avoid this behavior if you want all the values to be archived.

                • Re: AFSDkUpdateOptions.Insert Behaviour Inconsistemt with documentation ?
                  hmadlink

                  Ah that explains it.

                  can it be documented ? would help i think that if the users new that the insert update option uses compression by default.

                  or

                  am i looking at the wrong documentation / older version ?

                   

                  secondly

                  do other options have any undocumented defaults ?

                  Thanks

                  Haroon

                    • Re: AFSDkUpdateOptions.Insert Behaviour Inconsistemt with documentation ?
                      tramachandran

                      AFUpdateOption Enumeration indicates how to treat duplicate values being written to the archive and this enumeration behavior has not changed from the PI 2.x days and for different APIs (the mode names are slightly different).

                      You can always assume that compression is applied to Insert/Append unless otherwise stated. One important thing to keep in mind is that out of order events are not filtered by compression. Therefore, out of order data result in more events being stored in the archives than if the events were in order and filtered by compression.

                       

                      I do not think the version of the documentation is cause of this issue

                      I understand there might be some gaps in the documentation and we would like to hear your comments on improving it in our Feedback Forum for Developer Technologies. for the benefit of other users.