This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Thank you for raising this RFE. In concept we understand and have sympathy with the complaint that because ODBC configuration is centralised in a single file, there is potential for syntax mistakes to have wider implication than a single ODBC connection. Editting a single file for the benefit of multiple ODBC connections might also seem unecessarily cumbersome, and make it more difficult to isolate the potential impact of changes. These motivations were in mind when we introduced the conept of policies in policy projects as a replacement for configurable services in ACEv11. Of course, currently ACEv11 still centralises ODBC configuration in a similar file structure as we have done in the past in IIBv10 and earlier versions. This has some advantages in terms of back-compatability and familiarity for existing users, but also some disadvantages as the RFE notes. Long term we may consider making this enhancement suggestion to make ODBC definitions more granular, or in a file system structure that complements the policy approach. One thing which we would need to factor in is the degree to which this might be possible with the internal UNIX ODBC Driver Manager component which the ACE product utilises. This might therefore bring other aspects to the problem space which would need solving - such as potentially having to store this information in more than one file and deal with keeping the two in sync with one another. Thank you for the RFE suggestion. Status is updated to Uncommitted Candidate.
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - WebSphere
Product family - Integration
Product - IBM Integration Bus (WebSphere Message Broker) - IIB
For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Connectivity and Integration
Product - IBM Integration Bus (WebSphere Message Broker) - IIB
Execution group specific odbc.ini files would be yet another way to reduce the scope of these definitions to avoid inadvertant impact from a change to one application affecting another.
It would be nice to see all configutation moved to config services, including ODBC
Although the odbc.ini file is a placeholder, yes its true that any foreign chars within can cause great upheaval and is not apparent in diagnostics when db connections don't work! Yes, definitely need the type of data source configurable service within the configurable service and this should serve to override odbc.ini just like other configurable services which override msgFlow parms.
I am of 2 minds with this one. Whose job is this RFE supposed to make easier: the developers, or the admin? Also there is no "standard" content as each database type seems to have different relevant parameters...
This is indeed much needed functionality to be deveoploed as configurable service.