TRANSFERFIELDS includes 'Obsolete' fields

[hemisphera]

Describe the bug I have two tables with a near identical field layout. I am using TRANSFERFIELDS heavily between those two tables. By mistake I have created a field with ID 5010 in one table as Integer, in the other as Code20. This obviously fails my various TRANSFERFIELDS. The extension is already installed some tenants. Given the fact that I cannot change IDs, remove fields or change names I have no other choice but to mark both fields as Obsolete and then recreate them anew with separate IDs. So far so good. But TRANSFERFIELDS still errors out, even when I declare both fields Obsolete. It does not matter if I change it to Pending or Removed.

Versions:

• AL Langauge: 2.0.56865
• Business Central: IT Dynamics NAV 13.0 (24630)

[charlespockert]

Same sort of thing here: https://github.com/Microsoft/AL/issues/4847

Which for some reason has been closed despite no-one from MS commenting.

Obsolete fields/table relations seem to be included in all sorts of operations - I'd expect that these fields were caught at design/compile time instead of being considered by the runtime since they will never actually work at runtime.

Luckily for the above issue there's a workaround, but it does mean making edits to the obsolete table rather than just marking it obsolete.

[libin80]

I am struck with the same issue!!

we added a field in sales line table of type integer and the same field has been added in sales invoice line with type decimal. This has been moved to live tenant.

Now we have problem with the field while posting. We have obsoleted both the fields from sales line & sales invoice line. But we still have the problem posting as the Transferfields considers the obsoleted fields also.

Because of this problem, we are not able to do any posting. Could you suggest a solution here.

[ArunDelvin]

Myself too facing this same issue. Instead of Sales i was stuck in purchase as mentioned by @libin80 . Folks if any one captured the solution let me know your comments here...!

[pradeepmn91]

held up with this same scenario. issue is killing....pls help with solution asap.

[charlespockert]

Surely obsolete fields should be ignored when doing TransferFields?

If not, there should be an option to ignore them (maybe an overload on TransferFields?).

Obsolete fields are currently considered in many cases where they shouldn't be by the BC platform.

[hemisphera]

I know the following is not a solution for all scenarios ... but: in our case we didn't face a baseline TRANSFERFIELDS but one that sat inside our own code. So we could work around it by using a function called TryTransferFields (that is now part of our baseline-library-app) that uses the Field table and a RecRef and as such is able to:

1. exclude all fields that are marked obsolete
2. does not insist on transferring fields whose data-types do not match (yes, I am looking at you, italian localization ...)

I really think these are both things that the AL-baseline TRANSFERFIELDS should do aswell.

[libin80]

Its really annoying to see that this issue has been under investigation for almost 8 months. If we are struck with this on posting routine, there is no go to the next step :(

[atoader]

@libin80 @hemisphera @charlespockert what versions are you targeting?

[ginopack]

@atoader I too am having the same issue, and raised it to Microsoft a few days ago. Here is our issue:

We created a table extension for the contact table (5050) and added fields: -One field we created 50100 “Shipping Documents” type Boolean. We created a table extension for the vendor table (23) and added fields: -One field we created 50100 “Last Date/Time Modified” type DateTime.

Now the customer gets the attached Field Type error when synchronizing the Vendor to Contact:

We've tried setting the ObsoleteState=Removed and ObsoleteReason='Conflict with Contact'

We are in version SaaS 14.5, and right now our only options is possibly recreating the production environment to clear the obsolete fields.

[demiliani]

Possible workaround (alias, implementation of a "safe" TRANSFERFIELDS): https://demiliani.com/2019/10/17/dynamics-365-business-central-transferfields-and-obsolete-fields/

[jngillard]

Any updates on this issue?

[atoader]

A new overload has been added to the TransferFields method that takes a 3rd parameter that allows you to SkipFieldsNotMatchingType. It will be available with 2019 Wave 2 CU2 and with the 2020 Wave 1 releases.

[demiliani]

Skipping not matching fields will be the default behavior isn’t it? Otherwise problem still remain in the base app.

[atoader]

Could you provide more information as to the problem that will remain in the Base Application?

[libin80]

What happens for obsoleted matching fields? will this field skip the obsoleted field? Is the 3rd parameter mandatory?

[demiliani]

Imagine Sales Line and Sales Shipment Line tables. I add a field 18032100 with type = Code[20] in Sales Line Table. Then I declare it as ObsoleteState = Removed. Then I add a field 18032100 with type = Decimal on Sales Shipment Line. The base application makes a TRANSFERFIELDS from Sales Line to Sales Shipment Line during posting. This field declared as removed must be skipped. I think that this behaviour should be the default.

[charlespockert]

@libin80 don't forget that AL introduced method overloading (it's often forgot because it's not obvious in intellisense).

A new overload has been added - the original method signature will remain the same I'd imagine, you'll just get an overload with the new param.

[libin80]

@charlespockert - Thanks for letting me know. It makes sense that way :)

As the parameter 3 is named SkipFieldsNotMatchingType, just wondering, will this also skip copying data from an Obsoleted field from the source table to a non-obsolete matching field in the destination table?

[charlespockert]

@charlespockert - Thanks for letting me know. It makes sense that way :)

As the parameter 3 is named SkipFieldsNotMatchingType, just wondering, will this also skip copying data from an Obsoleted field from the source table to a non-obsolete matching field in the destination table?

The behaviour I'd expect is that regardless of the new overload, obsolete fields should always be skipped. It seems pointless to map them since using them in code results in an error anyway.

[anyrom]

The default behavior for any of the existing transferfields methods and new overload will be to skip the RemoveObsolete fields. The new overload will allow to skip not matching fields by type.

[ALGitHubBot]

The fix for this issue has been checked in to the master branch. It will be available in the bcinsider.azurecr.io/bcsandbox-master Docker image starting from platform build number 37837.

If you don’t have access to these images you need to become part of the Ready2Go program: aka.ms/readytogo

For more details on code branches and docker images please read: https://blogs.msdn.microsoft.com/nav/2018/05/03/al-developer-previews-multiple-releases-and-github/ https://blogs.msdn.microsoft.com/freddyk/2018/04/16/which-docker-image-is-the-right-for-you/

[radovandokic]

When this will be publicly available? This is a real roadblock for us. We obsoleted field in Bank Account because Transferfileds was complaining about a mismatch in field type during synchronization with Contact, and now we can not create or update Bank Account.