This is an IBM Automation portal for Cloud Platform 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.
See this idea on ideas.ibm.com
In the CQ Designer, the schema properties include specifying the Unix and Windows scripting languages. Implement a tab for the schema property “ALLOWED_DBNAMES” to enable/disable SQL reserved word checking and list the allowed reserved words.
This will allow us to continue using our CQ schemas initially designed over twenty years ago and still in use and maintained as we upgrade to CQ 10.0.x.
Up until CQ 9.0.1.10 CQ did not check for SQL reserved words used in designs, or at least the reserved word “query”. The 9.0.1.10 release added SQL reserved word checking, preventing the use of any SQL reserved words from all the CQ supported database vendors. This breaks backwards compatibility with existing schema designs that used what is now considered a reserved word.
We have to keep a version of CQ 9.0.1.6 for use to maintain our schemas. This prevents us from fully upgrading to CQ 10.0.0.x. CQ 9.0.1.x is End of Support (EOS) and may fail to work in our upgraded Windows environments.
The issue is that the reserved word list is a combined superset of all reserved words from all database venders, not just the reserved words for the selected CQ database type for deployment.
Consider one of our sites.
The Software Configuration Management (SCM) team created a common CQ schema called “CQ_BASE” over twenty years ago and maintains it. One of the stateless recordtypes contains a field with the CQ and SQL name of “query”. We deploy to SQL Server.
The latest “CQ_BASE” schema version is 152. SCM makes a change resulting in version 153. SCM uses “cqload exportschema” to create a file “CQ_BASE_v153_Full” and “cqload exportintegration” to create a file “CQ_BASE_v153_Delta”.
When a new program starts, they create a CQ DB set using the exported schema “CQ_BASE_v153_Full”.
For existing programs, they are all updated using the exported integration “CQ_BASE_v153_Delta.”
There are over 200 programs using over 400 CQ DBs (each uses one CQ Schema DB and at least one CQ User DB).
When using CQ 9.0.1.6 to perform this deployment to SQL Server everything worked fine.
We upgraded to CQ 10.0.0.5 and the deployments fail with the error that the field “query” is a SQL Reserved word. We tested previous versions of CQ including 9.0.2.x and 9.0.1.x until we discovered the change in 9.0.1.10.
Research determined that “query” is a reserved word in DB2 but not SQL Server. Therefore, it being considered a reserved word is not appliable to us. We should be able to continue using “query”, understanding the negligible risk to us. If we ever change the database type in the future we will address the issue then.
The CQ Help Desk shared with us that we can edit the exported schema files to include the following statement which allows continued use of the reserved word “query”.
ADD property ("ALLOWED_DBNAMES", "", "", "query")
This shows that the schema import and export functionality to allow continued use of reserved words is already implemented. What is needed is an easier way to permanently define this property rather than having to edit each exported schema. The manual edit step introduces the opportunity for human error and risk.
Adding the additional designer schema property to enable/disable SQL reserved word checking and to define the list of reserved word exceptions provides an easier, permanent method for this feature and removes the risk of human error. The property values can be used by the export commands to add the required statement that is already supported. The implementation effort should be minor.
Idea priority | Medium |
By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.