Developer forum

Unfortunately, this cannot be turned off. But are your dev, live and acceptation-databases not located on different sql-servers? In that case, naming them the same name would not be a problem. 

We run into the same issue again and again and again. Sometimes we need to spin up multiple instances of the same solution for testing purposes. Each time we have to modify data in these tables to make everything work.

Lars, I'm sure that someone could find a way to handle this in a more elegant way.

My suggestion is that you make it possible to connect to the "system" database, which will be the database of the current instance of DW. Instead of storing a connectionstring, you store some reserved name, e.g. "__system__". You then know that if the connection is named "__system__", you should use the database settings from global settings when creating the connection.

Any thoughts?

I even dare to challenge if there are any users of dw who store the form tables in a different database then DW.
It has to be supported now.

Not a big problem but can be annoying when moving to different environments.

+1 to storing connection information that refers to the system database. That resolves 99.9 of the cases!

@Martijn: can you create a thread in the Feature Requests forum for this?

Imar

Hi Guys

Thanks for all the response.
The issue is added to the Feature Requests.

Please give it some +1's there ;-)

Gr
Martijn

Hi Martjin,

A workaround would be to create an update statement in your migration scripts, daily copy, etc., that is what we have done when we faced that issue :-) As most of the "Areas" also have domainlock and you may want to have "disallow: /" in robots, you can also modify the Area table while you are at it.

Regards

Søren

Hi Søren

That's a good workaround.
Thanks!

Gr
Martijn