Change Power Apps SQL data connection while moving from dev to production

[SidhharthM]

Hi Everyone,

I have below SQL server environments (Not the Power Apps environment):

Dev Environment: Server A -> '[DevDBName].[SourceTableName]'

Pre-Prod Environment: Server A -> '[ProdDBName].[SourceTableName]'

Prod Environment: Server B-> '[ProdDBName].[SourceTableName]'

If you observer above,

1. Table name SourceTableName and its schema is same in all environments. 
2. Dev and Pre-Prod reside in same Server A and Prod is in different Server B.

3. Both Pre-Prod and Prod have same DB name ProdDBName.

Below is what I am currently doing:

1. When I migrate Power Apps from Dev to Pre-Prod, I have to visit each formula in Power Apps and change the DB Name.

2. I am yet to plan for migration of Power Apps from Pre-Prod to Prod and yet to decide on keeping both the Power Apps on same power apps environment or keep them in separate environment.

Below are my queries:

1. What is the best possible way to avoid manual db name change in all the formulas from DevDBName to ProdDBName?

2. If I move from Pre-Prod to Prod, and if they are in same Power Apps environment, do I still have to go everywhere and change it manually as both db names are same?

3. If I plan to keep Pre-Prod and Prod in different Power Apps environment,  do I still have to go everywhere and change it manually as both db names are same?

Thanks in Advance,

Sidhharth M.

[edguerre]

@SidhharthM : I hope I understood this correctly, if not please rephrase the question if possible.

Even though the DB and table names and schemas are the same, you might need to manually select the new connection. This is because it does not only go by name, but by ID as well.

1. You could export the app as a package and edit the JSON, but this might break the app and is unsupported.

 For 2 and 3, my opinion is that you might have to change any connection/selection that points at a different location than where the original app pointed.

[SidhharthM]

 @edguerre Thanks for the input. Yes, of course we need to change the connection when connecting to different data source. But my main issue is manually going everywhere in Power Apps formulas and changing db name. Is there any better approach for this?

PS: I have tried changing db name in json file,  but still I had to change the db name manually everywhere.

[WoLe98]

Is there any update on this? manually updating every time there is an update seems a bit frustrating?

[SidhharthM]

Well, there is a way, especially when we use Data verse or SharePoint. We can use Solutions for migrating from one environment to other, all the db tables get automatically created:

[AbeNewton]

Is this real? We're pretty far into developing a PowerApp and I'm trying to move it from Dev to Test for UAT and then to Prod. Source info is in an Azure SQL Database. I'm having a hell of a time getting this to work. I've resigned myself to creating new tables and manually changing the formulas to point to the new tables, but even that is not working well as I can't always add or delete a table. Just does nothing or spins most of the time. So not way to port from Dev to test to prod unless you used Dataverse tables?

[WoLe98]

Hi @AbeNewton ,

I had the same issue and kind of figured a way to do this, not sure if it suitable for your needs as well.

What I did was create a second "development" environment, a sandbox in Microsoft Admin. In this environment I copied the whole PowerApps project. This has to be done manually but is not that much of a hassle. Then I also created a copy of the production Azure SQL database into a "development" database. I've connected this development environment to this azure sql development database and then you are, in some way, in a "Development" env. From here you can change whatever you like and when you want to publish to production, just export and import the Power Apps project again and you have to make sure the PowerApps connection is set to production then it will work. 

Let me know if this helps and if you need more help!

I think you can also create a third environment for testing.

Regards,

Wouter

[AbeNewton]

@WoLe98  Were your tables Metaverse tables (it sounds like they were AzureSQL) My app is setup with Metaverse but we are not using it. Only using AzureSQL. I started with AzureAD Integrated Security on SQL Connector since that was the recommended best practices on the MS Tech docs but have reverted to SQL Auth since the AzureAD seemed to have issues with migration that are worse than SQL Auth

I've exported and imported the AzureAD based app from dev to test PowerApps environment. Seemingly no way to change the connections for AzureAD Auth so I started recreating the data sources as AzureSQL. However I don't seem to be able to delete all of the old data sources. Some just spin and then error out when I click delete. Very frustrating. This is not a gigantic app either. Hits about 15 tables.

[AbeNewton]

I did figure out the path forward on this with Azure SQL Server Data Sources and Dev / Test / Prod environments. It's finicky to setup and not well documented by Microsoft at all and you may have to rebuild some apps to get it into the correct path going forward. The key is creating a "PowerPlatform Solution" and then creating a new App within the solution. You may have to play with these steps. It seemed like slight deviations would cause the whole thing to not work in then end.

1. In your Dev PowerApps Workspace go to solutions and Create a solution
2. Add a new PowerApp to the solution
3. Open the PowerApp (before adding any data sources) and go to settings and turn on the general feature to automatically create variables when data sources are added.
4. Save the app to the cloud (basically publish)
5. Close the app
6. Reopen the app
7. Add a SQL Server Data Source using SQL Auth (Azure AD Auth while advertised as the best practice doesn't seem to work in most cases like this and seems to not be ready for prime time use).
   1. You may have to add a single Data source table to your app as well.
8. Publish the app and close
9. There's a solution menu to add additional items. Use this to add a "Data  Source Reference" (not variable) if you don't already see it.
10. Set the reference to use the Data Source that you added (if dev environment then this should point to your dev Azure SQL Database)
11. Click the button at the top solution menu to "Export the Solution" not just the app.
12. It will ask you if you want to publish changes. Select publish and then finish the export
13. It may or may not popup the download but you will so see a zip in your downloads
14. Go to your Test Power Apps Environment and create a SQL connection to your Test Data Source. Use SQL Auth again.
15. Go to your Solutions portion of your Test PowerApps environment and select import solution and import this solution
16. During the import process it should pickup the connection and reference and ask you to tie a Data Source Connection to it. Tie it to your Test Source.
17. You should now have a solution with an app. Open it and it should be pulling from your Test Data Source.
    1. There were some instances where it didn't import saying it didn't have all components and I had to go back to the dev solution and click the button to get all dependencies and re-export. (maybe because I deleted a reference?)
18. The above steps should get you going on a new app. However if you already created an using the recommended Azure AD Auth for the SQL Connector, there seems to be some real issues trying to convert it over. I don't know if it's possible without rebuilding the entire app. I can delete a few of the Datasources and then it just stops removing them or I get failed to delete resource or just a forever spinning circle, or failed to save app. Maybe I'll have to create all the new sources under new name that it gives it (Datasource becomes Datasource1. doesn't seem to be a way to rename them), then hand fix any code reference to the old datasource. Then maybe I can delete them. I suspect the deletes don't work because there are too many references to them that it has to figure out and it bogs down the No-Code environment and stops.

[sfarr91]

Thank you @AbeNewton for your insights and @SidhharthM for posting the original question!

I've come across the same problem...

Funny that over a year later Power Platform still haven't sorted out Azure AD Auth functionality with ALM - two 'best practice' principles that are seemingly incompatible with one another 😕