Because of the REST style URL navigation, the primary key is part of the URL for row pages. The side effect of this is that when changing the primary key, the current URL becomes invalid because the location has changed. This was not an issue originally because query strings were used (and still are, internally, but REST paths now override)
The correct solution for this is to detect this case and then close and navigate to the new URL.
In the meantime, a cryptic error is now displayed after making the change:
Because of the REST style URL navigation, the primary key is part of the URL for row pages. The side effect of this is that when changing the primary key, the current URL becomes invalid because the location has changed. This was not an issue originally because query strings were used (and still are, internally, but REST paths now override)
The correct solution for this is to detect this case and then close and navigate to the new URL.
In the meantime, a cryptic error is now displayed after making the change:
Supplied/returned row mismatch. Expected 1 rows, got 0If nothing else, there should at least be a descriptive error so the user knows what is going on.
Bug in RapidApp v0.99020