Easily find issues by searching: #<Issue ID>
Example: #1832
customer reported issue with extraction of his procedure:
CREATE OR REPLACE PROCEDURE "nulla"() RETURNS INTEGER EXECUTE AS OWNER LANGUAGE NZPLSQL AS BEGIN_PROC BEGIN return(1); END END_PROC GO
It would appear that the objType string is stored as 'procedure' in customers catalog table. A non-modified catalog table would store this string as 'PROCEDURE' but the catalog data can be modified. We need to enhance extraction so that modification to the catalog tables in this way will not affect our extraction. Data is still case sensitive.
Documentation on how to modify catalog data: link
| Field | Old Value | New Value |
|---|---|---|
| Status | New | In Progress |
| Field | Old Value | New Value |
|---|---|---|
| Description | customer reported issue with extraction of his procedure: CREATE OR REPLACE PROCEDURE "nulla"() RETURNS INTEGER EXECUTE AS OWNER LANGUAGE NZPLSQL AS BEGIN_PROC BEGIN return(1); END END_PROC GO It would appear that the objType string is stored as 'procedure' in customers catalog table. A none modified catalog table would store this string as 'PROCEDURE' but the catalog data can be modified. We need to enhance extraction so that modification to the catalog tables in this way will not affect our extraction. Data is still case sensitive. Documentation on how to modify catalog data: link |
customer reported issue with extraction of his procedure: CREATE OR REPLACE PROCEDURE "nulla"() RETURNS INTEGER EXECUTE AS OWNER LANGUAGE NZPLSQL AS BEGIN_PROC BEGIN return(1); END END_PROC GO It would appear that the objType string is stored as 'procedure' in customers catalog table. A non-modified catalog table would store this string as 'PROCEDURE' but the catalog data can be modified. We need to enhance extraction so that modification to the catalog tables in this way will not affect our extraction. Data is still case sensitive. Documentation on how to modify catalog data: link |
| Field | Old Value | New Value |
|---|---|---|
| Fixed Build | v19.0.0-alpha-18 |
| Field | Old Value | New Value |
|---|---|---|
| Fixed Build | v19.0.0-alpha-18 | v19.0.0-alpha-18, v18.0.13-2 |
| Resolution | Fixed | |
| Resolved Date | May 30, 2017 9:18 PM | |
| Status | In Progress | Resolved |
| Field | Old Value | New Value |
|---|---|---|
| QA Assignee | SachinPrakash (Sachin Prakash) | tariqrahiman (Tariq Rahiman) |
| Field | Old Value | New Value |
|---|---|---|
| Status | Resolved | Verified |
Verified in ADS v18.0.13-4 and in 19.0.0-alpha-19
| Field | Old Value | New Value |
|---|---|---|
| Status | Verified | Closed |
Code changes have been made so that when checking catalog table, comparisons against system data that represents constant strings will now be compared against both its lower and upper casing. There is no situation where these strings will be mixed casing.
This will solve the customers issue; this does add a minimal increase in to the query plan scan but should be unnoticeable.
Code has been checked in to v18 source with Committed revision: 54532
Code has been checked in to US trunk with Committed revision: 54523
Code changes have been made so that when checking catalog table, comparisons against system data that represents constant strings will now be compared against both its lower and upper casing. There is no situation where these strings will be mixed casing.
This will solve the customers issue; this does add a minimal increase in to the query plan scan but should be unnoticeable.
Code has been checked in to v18 source with Committed revision: 54532
Code has been checked in to US trunk with Committed revision: 54523
Issue #15276 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| Fixed Build v19.0.0-alpha-18, v18.0.13-2 |
| No time estimate |
Verified in ADS v18.0.13-4 and in 19.0.0-alpha-19