Closed jwikman closed 10 months ago
You're right, it's indeed related to #466.
The problem here is not the SqlTimestamp = true
, but the fields don't have the samen name.
field(9; "Record Time Stamp"; BigInteger)
field(9; "Snapshot Id"; BigInteger)
I'm going to close this one so we can continue the discussion further in #466.
The problem here is not the
SqlTimestamp = true
, but the fields don't have the samen name.
Oh, of course. I should've realized that... 😳
Let's continue discussion in other thread then.
I get a, at least in my opinion, false positive when everything is identical, except that one field has
SqlTimestamp = true
set in one of the tables (the source of TransferFields). This is very intentional and should not raise LC0044. I cannot set the RowVersion of a record anyway, so having that on the target table does not make sense...What properties are being looked at to identify the fields as conflicting?
My scenario is that we've got a setup table, in this sample connection details to an Azure Storage. And everytime time this is being used, we are logging this. And we want to log the setup details as it was when it was used. To achieve this we use the RowVersion of the setup record, but in the old way of specifying a BigInteger field with
SqlTimestamp = true
(this was created ages ago, before we had RowVersion on all tables). So, every time someone is using the setup, we check if we already have logged the setup or if the setup has been changed since last time and then save a new "snapshot" of the setup.Source Table:
Target Table:
The TransferFields() call:
Bottom line: Yes, I can use pragma or
SkipFieldsNotMatchingType
parameter ofTransferFields
, but I still believe that this is a false positive that could be fixed instead. :)(This might be a bit related to #466)