System default settings versus production settings
I'd like to have production specific settings for different environments (OTAP). I have set the system default settings on my production to override the default settings. However, this does not seem to work. It is my understanding that the system default settings override the settings I have set on the production (I thought I heard my Sales Engineer say this). However, reading the documentation I am not sure of this reading either. However, when I clear the values for the adapters on my production my system default settings are still not apply.
Are the system default settings supposed to override my adapter settings I have applied on my production (i.e. the screen with the green bulbs)??
I got it to work. Clearing the values from the production didn't work because an empty string was left behind in the production file. So I went to studio and deleted the parameter settings there.
When I then viewed the production (and reloading it) via the management portal the settings specified in the system default settings then turned green. Apparently there is some color coding going on:
Setting name:
Green -> provided via class definition
Blue -> Provided via system default settings
Black -> Provided as production setting (in xml that extends ens.production )
John,
If you haven't already done so, please contact the WRC to let them know how important it is to get the Production Class UI to respect source control hooks (I am with you all the way on this one, but Product Management needs to hear it from customers).
Thanks,
Ben
Maybe I'm missing something but with the way we have our code and data split our, we're only mirroring our data. So an advantage of using the System Default Settings is the change made on the primary is already updated on the secondary. Is there a best practice on this type of setup when dealing with having to fail over to a secondary and needing the existing business host values the same? I do agree that it would be nice if we could use the Sytem Default Settings to be available to multiple namespaces.
Settings stored in the XData block of the production class (e.g. values entered through Portal) trump any System Default Settins values.
In Portal there's this button to get you to a page that may help you understand what's going on:
For a long time I've complained that the Portal UI makes it too easy to override a System Default Settings value (which is namespace-specific) with a value that gets stored in the production class (which you might migrate from one namespace to another). Add to this the fact that Portal ignores source control when altering the production class
Ben - Product Management have been hearing us at George James Software nag about this for years. Meanwhile we've devised some ways that our Deltanji source control tool can mitigate the issue.
Chris, I'm interested to know why you're not mirroring your code as well. What do you do to make sure that if the secondary takes over from the primary it'll be running exactly the same code as was running on the primary? Or don't you want it to do that?
John,
We have entertained the idea of doing this and probably will be soon, but we always push our code CACHE.DAT to both the primary and secondary servers and then switch our namespace to use the new DAT files. While it becomes more cumbersome with additional servers, for now it has been an easy approach with minimal downtime.
John - if you haven't already done so, please contact the WRC and let them know how important it is to get the Production Class UI to respect source control hooks (I am with you all the way on this one, but Product Management needs to hear it from customers)
Social networks
InterSystems resources
Log in or sign up
Log in or create a new account to continue
Log in or sign up
Log in or create a new account to continue
Log in or sign up
Log in or create a new account to continue