Testing changes requires saving/commiting

[JuanSombrero23]

Hi,

Claude just created a new measure throught the MCP. I then wanted to test it. Few findings/thoughts:

Deploy before test

I want to test that. My preferred way is through TE's native Pivot Grid feature. Reason for this is that it does not only allow me to eyeball what it produces, it also allows me to step into the debugger by right clicking, and from there try to understand what it does. For obvious reasons, the newly created measure is not available for the pivot grid, as the changes are still uncommitted/unsaved. On the other hand, this means deploying (ctrl+s) before being able to test is. I understand why this is what it is, but it feels strange on the other hand. Especially as saving disables the undo, and I would have to turn to version control (if enabled) or the agent to revert stuff. In my example for a single measure this is overseeable, however, if I have stacked up many changes at that point, the inconvenience will be bigger. I understand that this is not MCP related. Same goes for measures created through the CLI, or basically any newly created measure. Is this a known limitation or am I missing out on some kind of 'hybrid' approach where I can use this non-committed measure against the model? I realize version control, branching, proper CI/CD techniques should be able to catch this, yet feel like overkill in simple cases like the one I have at hand. How do you guys deal with this when facing this?

MCP creating a Pivot Grid

I noticed the MCP can open tabs in TE3, like a DAX query tab or a C# script tab. I would think it's really cool if it could also open a Pivot Grid tab parametrized in such a way that the agent can prefill certain fields. I could then add a skill or rule to Claude to teach it how to create a test environment for me whenever it creates a measure (aka a pivot grid in my case), or even go one step further and put in there the old vs the new measure (in cases where we are working on a measure, updating it, well aware that that would require 2 measures rather than editing an existing one, yet still a very cool idea I believe, smth I can let my agent manage, in case he can build me a Pivot Grid)

MCP dax query screen bug

From my 'debugger' approach, and given the MCP cannot create a Pivot Grid, I was glad to find it could build a DAX query, also allowing me to enter the debugger. The next best thing so to speak. When the MCP open a dax query pane, it is by definition not executable. The play button is greyed out, F5 won't work, despite the tab being colored blue as if it's the one focused on. In the screenshot you can see the tab it opened, and the menu buttons clearly indicate it's still in 'pivot grid' mode. Clicking another tab, the coming back, solves the trick.

Pretty verbose thread this one, sorry up front.
Reach out of smth would be unclear. Any typo's are intentional, put in here to prove this was written by a human, not AI and are by no means me being sloppy ;-)

Regards,
Jan

[mlonsk]

Hi @JuanSombrero23
Thank you for the detailed suggestions.
To start with the last first. I have spun the bug into its separate issue #1591, and I have confirmed it has a bug. We are working on a fix for that.

I understand your desire to use the Pivot Grid, but for the workflow that you describe, I would, in any case, recommend using DAX Queries instead.
The Pivot Grid is MDX engine, like a Pivot Grid in Excel, against the live database. It is therefore not possible to have and run non-deployed measures in it. This is a limitation of the Pivot Grid component we use and not something we can change.

A DAX query, on the other hand, can use DEFINE to create temporary query-scoped calculations that you can test before committing them to the model, and you can just ask your agent to create a new measure like that instead of making them in the model first.

When you have tested the query and the new measure, you can use the "Apply" command to commit it to the model:

This would precisely allow you to have two version of the same measure, the old and the new (with a new name):

Could you see yourself using this type of workflow instead of a Pivot Grid going forward?

[JuanSombrero23]

Hi, I think I could do that indeed. So that implies rather than an agent actually writing the measure, it would write a define statement, which, once I hit apply, then creates it. That would break some other stuff, like the fact my agent puts a list of annotations to everything it creates, but there are solution for that.

Thx for the suggestion, enough inspiration to give certain things a try and find a workflow that suits me.

[mlonsk]

Yes, that is the workflow that I have laid out above.

If you want to have the agents' annotations, the agent will need to persist the measure in the model first. But you could do a workflow where the agent adds the measure and then writes a DAX Query to test it. In my testing, the agent itself notices that it needs to write a Define statement to test the measure, as it is not yet committed to the model.
This means that you have botht he measure in your model (unsaved) and can test it. If you make any changes to the DEFINE measure in the DAX query you can just press Apply to get the changes applied to that, unsaved, measure.

In this example I have done just this. Had my agent write a new YTD Gross Sales measure and write a query to test it.

As you can see from the agent conversation it did it all without being explicitely told to use the DEFINE statement