Ken, will be interested to see what info you get here. I have been trying to figure the best way (or if there really is a way) to conveniently use the development slots on Azure. I have not figured out an easy or effective way to use them yet.

Each DNN install needs its own database. No sharing.

to solve your current situation without resetting the whole second install, you may clone the database and adjust the connection string in web.config file. You will need to adjust users and content according to your needs.

Take the learning - this was a mistake in cloning on a Azure set up. Azure suports cloning, and while experimenting, it was possible to make a change to data on one and it came up on the other. Change users picrure or details for example.  However, too risky to use for real. Clone was bined.

Hi Alex,

just been through a painful failure recovery on Azure, Mr Microsoft set out that slots to a web service are 'only' for preparing the production environment.  Its a bit quirky but works fine and manages alphas to beta to live easily.  

Beware though that backing up slots is problematic I found. Its problematics with web services period as some of my other recent posts testify.

 

Just to add my 2 cents. Officially Dnn does support multiple instances on the same database and it has done so for a very long time when it was expansive to host multiple databases. This used an objectQualifier string in front of each object (table, view, stored procedure, etc.) But, many modules did not test this properly and caused issues and we have removed the option to set the objectQualifer during installation in recent versions. So long story short, don't do it :)

Posted By Daniel Valadas on 10 Nov 2019 01:56 AM
Just to add my 2 cents. Officially Dnn does support multiple instances on the same database and it has done so for a very long time when it was expansive to host multiple databases. This used an objectQualifier string in front of each object (table, view, stored procedure, etc.) But, many modules did not test this properly and caused issues and we have removed the option to set the objectQualifer during installation in recent versions. So long story short, don't do it :)

In my experience, using Object Qualifiers in general is not a great idea.  We've run into many issues with this in the past.  Longer term, you'll have to de-couple this feature anyway and it's time-consuming to do so.  :(

 

 

Well, to give my two cents: I use object qualifiers a lot in my dev and testing environments, but not on productive installations.

Happy DNNing!
Michael