| Author |
Message
|
| zpat |
 Posted: Tue Jun 04, 2013 1:42 am Post subject: RFE to allow granular ODBC data source configuration in WMB |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Jun 04, 2013 5:27 am Post subject: Re: RFE to allow granular ODBC data source configuration in |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I can see where it would make sense in a development environment where everything is in flux, and different people need to play with different parms. I would no like to see this moved up to the other more stable environments. Especially as there is usually a number of changes involved per environment... So I am of 2 minds with that RFE... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 04, 2013 5:41 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Why would having more granular control ever be a bad thing?
It would be optional to use, but offer the chance to get away from having everything in a single ODBC ini file.
Reduces the risk of regression, provides isolation between applications, allow updates from the command line.
I can only see upsides here.
To give an example - every time some project asks me for a change to their ODBC ini configuration - I groan, because it means updating a common file that affects many applications.
I therefore have to explain to many business areas that this change is not for them, but might affect them if it went wrong and so the change management effort is a nightmare for even the smallest change. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jun 04, 2013 5:49 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And you would happily accept the nightmare of having 16 definitions for 8 flows (each using the definition twice with slightly different parameters) ?
Now multiply that by the number of egs and you see why a single db odbc configuration eases admin quite a bit. Never mind about trouble shooting when all of a sudden flow 1 stops working... or forgetting to switch the parms from dev to qa / prod for one of the flows....
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 04, 2013 5:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Configurable Services are overrideable.
In the same way that DSN names are.
What the RFE is about, fundamentally, is moving the ODBC configuration from being a system wide mechanism to being a broker mechanism.
Or at least of providing a method where a broker mechanism can override a system mechanism...
Nothing in this change will change the needs of specific applications in regards to their use of data sources. So moving from odbc.ini to a configurable servcie should be entirely transparent to an app developer, and would fundamentally be a choice made by the broker/data source administrator for the relevant runtime. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 04, 2013 6:32 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Indeed.
Switching ODBC files around is making a virtue out of a necessity.
However I would hope IBM would implement any new feature in a way that does not invalidate existing approaches for those who actually like them.
But one key point about moving to command line configuration is that you can automate and script it.
Also currently there is a disconnect between the way that DB credentials are updated (command line) and DB host info is updated (flat file edit). |
|
| Back to top |
|
|
|
|
