Moving Calculated Columns/Measures to Replicated Snowflake Tables

[qbarnes]

Hello All, 

We have replicated all Tables/Columns on our SQL Server, with same naming convention over in Snowflake.  Now, its time to move the Calculated Measures and Calculated Columns within each report. 

So far, on my first few runs... I've loaded snowflake tables onto an existing report, and used the old trick of changing the home table for Calculated Measures, along with pointing to the identical column within the Snowflake Table.  That's okay for Calculated Measures...  However, this is very time consuming, as I have too measures many to count.

Further, when it comes to the Calculated Columns - I have no tricks.   

I tried to get fancy, and copy the snowflake source/navigation into the original table on the Query Editor, in hopes evertything just falls in place (since the naming convention is the same), while maintaining the calculated Columns/Measures... but Im getting errors of:    "The columns [...] either doesn't exist or doesn't have a relationship to any table available in the current context."  -or-  "Column [...] in table [...] cannot be found or may not be used in this expression." 

Therefore, my question is, has anyone figured out a more streamlined way of moving Calculated Columns (and Measures) from SQL Server Tables to Snowflake Tables??

[edhans · Accepted solution]

Ideally this is what you do. 0% work will need to be done in Power BI, all in Power Query.

1. Connect to Snowflake
2. Transform the Snowflake connections in Power Query to mirror those of the SQL tables. This includes column renames as well as any other transformations.
3. Open the Advanced editor for one of the snowflake tables and copy all of that M code.
4. Open the Advanced editor for the SQL table you are replacing. Paste in all of that M code replacing the SQL M code.
5. Close and apply.

Power BI Desktop will not know the difference. It will just work. Wash, rinse, repeat for every table.

In the tabular model, the table names aren't used. It really references table numbers, which is why you can easily rename tables with no harm. But it means you cannot create a new query in Power query with the same name and delete the old query and then import. They will have different underlying IDs.

This article from P3 is essentially the same thing.

[qbarnes]

@edhans ,

Totally cool!  This will be a huge time saver for me. 

- I am experiecing other little bugs on close and apply, for two PBI Tables that were actually developed via SQL Queries.  Here's the error prompt:

• Failed to save modifications to the server. Error returned; 'The column 'ExampleTable[ExampleColumn]' either doesn't exist or doesn't have a relationship to any table available in the current context. A circular dependency was detected: OtherTable[CalculatedColumn1], OtherTable[CalculatedColumn2], OtherTable[OtherTable[CalculatedColumn1].'.

So it appears my next hurdle will be to point all of my SQL Queirnes to the Snowflake Tables; I'm guessing.

[edhans]

Those look like calculated columns issues given the error. Is that what they are? Calculated Columns can cause circular dependency issues. If that is not the case, provide more details.

[qbarnes]

Hi @edhans , 

Yes, they are calculated columns.  

[edhans]

You can do one of two things:

1. Remove them and redo them as Custom Columns in Power Query
2. Do a deep dive on DAX circular dependency issues and adjust the DAX to compensate.

I personally recommend option 1.

In general, try to avoid calculated columns. There are times to use them, but it is rare. Getting data out of the source system, creating columns in Power Query, or DAX Measures are usually preferred to calculated columns. See these references:
Calculated Columns vs Measures in DAX
Calculated Columns and Measures in DAX
Storage differences between calculated columns and calculated tables
SQLBI Video on Measures vs Calculated Columns

[qbarnes]

Thanks @edhans

I apreciate all of your help, and the solution!!!.  👌

[edhans]

Glad to assist @qbarnes. Hope your project moves forward smoothly.