To homepage To homepage
Solved

BC Adapter - Merge extension tables option

andri
Rank
Badge +1

In version 20.10.39 you sneaked in a new features in the BC Adapter data source:

  • 17627: Business Central adapter - Merge extension tables option for SQL Server provider
    Added option to merge a table and its extension tables together as one table.

This feature could be very useful but I can’t find any documentation on how it works and if there are any limits or considerations that need to be taken into account.

Initial testing suggest that it works for some tables but maybe not for tables in extension modules?

icon

Best answer by Thomas Lind 22 March 2023, 15:41

View original

14 replies

Thomas Lind
Rank
Userlevel 5
Badge +5

​Hi Andri

I did the testing of this, so I may have some more info about this.

It is a feature added to help with the newest BC version 20 release. For the earlier versions it will not be able to find any tables to merge.

This version 20 has all the tables split out into multiple tables with a company$tablename$guid setup. Like this

So the what the merge feature does, is to merge these into one customer table for example.

The limits I found was that they were entirely different tables and sometimes the additional ones would make it be not able to be incrementally loaded using the timestamp field.

You can see the generated query if you open the query tool of the table.

 

If you turn off the merge, it will not do so, but the main table will not be named tablename$guid when you select it.

That is pretty much all there is about this.

Also, if you want to try this I can send the demo version I used to you?

Christian Hauggaard
Rank
Userlevel 6
Badge +5

@andri does Thomas’ answer above help clarify the merge functionality? If so could you please help us by marking the best answer above. Please let us know if you have any follow up questions :)

andri
Rank
Badge +1

Thanks, Thomas for giving some description about this feature.

One thing that we are seeing is that fields from extension tables related to “non-standard” BC tables from external modules do not get added to the primary “non-standard” tables. In these cases the extension tables are removed, the guid part of the primary tables are removed from the name but the extension fields do not get added to the primary tables.

Is this a bug, is there a workaround or does this feature only work with extensions to standard BC tables, like Customer, Item etc. ?

Thomas Lind
Rank
Userlevel 5
Badge +5

Hi Andri

Do you use the SIFT option as well?

Then maybe it is an issue.

andri
Rank
Badge +1

Hi Thomas

A change to the SIFT option does not seem to make a difference for this issue.

Thomas Lind
Rank
Userlevel 5
Badge +5

Hi Andri

Can you still locate these tables as extra tables, or do they not exist in the selection area?

andri
Rank
Badge +1

The main tables from the external module are available but they do not include any new fields. The guid post-fix is removed from the name and their related extension tables are not shown in the selection area.

Thomas Lind
Rank
Userlevel 5
Badge +5

If you turn off the merge, so the tables again gets split up, does they appear?

My whole point is to work out what works and what does not to see if there is something to pass on to the developers.

andri
Rank
Badge +1

Yes, if the merge feature is turned off, the extension tables appear again.

Thomas Lind
Rank
Userlevel 5
Badge +5

So for a workaround, you could create two data sources based on the same BC provider.

Then one merges the tables and the other do not.

You then add these extension tables to the main ones in the DSA or DWH.

I don’t know if I can replicate it myself, as I only have an exported test database, but I will ask if this is seen as a bug or a feature.

T
Rank

Is there a version of BC that manages the $ext tables in BC seamlessly now? I have merge option connection that gets data in the core table, but extension table columns do not come in and only the one named table is available. 

-Ted
Thomas Lind
Rank
Userlevel 5
Badge +5

Hi @ted.clark 

It is supposed to merge all these extensions together and generate one table with the name.

If you turn off the merge option, do you then see multiple versions following the setup explained with a guid on the end of it?

T
Rank

@Thomas Lind working through the workaround here and finding that incremental on the $ext part is not a given as there is no modified date kind of column to rely on. I am not sure if you question from 10 months ago every pointed this as a bug or feature, but would like to see it fast-tracked nonetheless. Working with a project where the BC instance has 20+ entities with $ext portions so this workaround on repeat and then individually managing incrementals and joins within the solution is a bit of a big pill to swallow. Thanks for quick reply. 

-Ted
Thomas Lind
Rank
Userlevel 5
Badge +5

Hi @ted.clark 

Yeah, incremental load can be a bit difficult when the extension tables aren’t containing the necessary fields for it as well.

Reply


Terms and ConditionsCookie settings