Forum Discussion
Change in Index After Expanding Merged Table Columns.
Before you do the merge, wrap both tables in Table.Buffer() and see if that helps. To do that:
- Go to each table
- Go to the last step
- Go to the formula bar. Whatever is there, add "Table.Buffer(" on the front, and another ")" on the end.
- Repeat with 2nd table
- then do the merge.
What I suspect is happening is your index is based on how data is sorted, and sorts in Power Query can be affected by other data, like data coming from a merge. Table.Buffer protects from that. It also breaks any Query folding, so if you are connecting to a SQL DB or other RDBM, be aware of that potential performance hit.
I don't know why this fixes the issue but it apparently does. Thank you!
It's quite counterintuitive if table A has created an index column, and table B is based on A but they end up with different values in the index column (scrambled).
It prevents external changes from affecting the query. Power Query doesn't always evaluate the transformation steps in the order you create them. It may do them in a different order to optimize performance. Things like merges can affect the order of a table, which is usually fine, unless building indexes. Table.Buffer prevents that, but at a cost. That table has to be loaded into memory. If it is large, it can slow your query down, or even halt the progress if the table is too large for the RAM of the machine running the query.
Thanks for the explanation although even if the order of the steps is not the one we define, the index column is only created once, so it shouldn't have different values on two tables when one just adds a few steps to another, or is merged with it based on common columns.
Anyway using Table.buffer() as a workaround is viable, but I wonder whether there is a better way to normalize a big flat table.
If table A is the original table, I'm currently basing table M (master) on A, dropping the value columns, keeping the "master" data, using distinct to remove duplicate master data, and creating an index column.
Then I base table D (detail) on A again, and join it with M based on the "master" columns, in order to get the M.index column and thus be able to link M and D in the model. Drop the master columns on D and keep the value colums and the index reference.
This fails randomly after a refresh (there is no error but the values make no sense as the index is different on each table) and only consistently works by using Table.buffer before the merge.
Is there a better way of dealing with this?
Thank you!
I know the index is only created once, but it may not be created when you think it is. Table.Buffer ensures it is.
The best solution is do this earlier than Power Query. If Table.Buffer works for you that is great, but if your table has 100M records, it won't work and a SQL Server or other data warehouse should be adding the indexes.Thank you edhans for your patience, explanations, and workaround!
I just wanted to point out that following the transformation steps I mentioned above, even if we don't know "when" the index is created, as long as it is created only once, there shouldn't be any problem. The fact that we sometimes end up with scrambled indexes in both tables (with a common ancestor where the index is supposedly created) seems to indicate that the index is actually being created twice, once for each one of the two tables, which could then result in non-matching indexes.
That is quite counterintuitive when you base your transformations on the principle of causality.
I agree with you that ideally the data should come already normalized from the backend, but sometimes you have to work with long flat tables in PQ and need to normalize them a bit in order to have a manageable model. As you mentioned if the tables grow too much there might not be an alternative to normalizing on the backend.
Since I haven found much information about this anywhere except on this thread, it's probably not identified as a bug yet, so it may take a long time to fix.
Thankfully we can work around it with your Buffer recommendation (even if that may cause other problems).
Cheers!