...
- SQL Parser only applies to changes that are:
- Packaged using the DIRECT, DDL_DIRECT, or SQLFILE method
- Created in the ChangeSet Wizard as 'Execute a SQL script file using JDBC'/'Custom SQL (External File)'. NOTE: Changes created as 'Custom SQL' will NOT be processed by SQL Parser.
- Created in the ChangeSet Wizard as 'Execute with SQLPlus'
- SQL Parser does not change how these scripts are ultimately executed during a Deploy operation. The following package methods all result in execution of a SQL script:
- DIRECT packaging method
- DDL_DIRECT packaging method
- SQLFILE packaging method
- changes created as 'Execute a SQL script file using JDBC'/'Custom SQL (External File)'
- changes created as 'Execute with SQLPlus'
- SQL Parser does not validate SQL statements. Instead, SQL Parser simply parses provided SQL scripts and models them into Datical's object model for subsequent validation with rules and forecast.
- In the event the SQL Parser is unable to parse a statement that is included in a provided SQL script:
- The Forecast Report will include a warning for the statement(s) that cannot be parsed. The warning will read: "WARNING - Will Changes in this script will not be forecastsimulated in Forecast. Custom rules will still apply"
SQL Parser will continue parsing the provided SQL script and attempt to parse all other statements
Warning SQL Parser is unable to handle parsed changesets that are dependent on unparsed changesets in the same Forecast.
- In the event the SQL Parser is unable to parse the provided SQL script file or otherwise encounters an error:
- The Forecast Report will include a warning that will read: `SQL Parser could not parse sql script file <script>`
- In the event the SQL Parser is unable to parse a statement that is included in a provided SQL script:
- We recommend that you do not put large DML scripts with many insert or update statements in folders that have SQL Parser enabled.
...
There were fixes and improvements to SQL Parser for Oracle in Liquibase Enterprise/Datical DB version 7.12. Please upgrade to version 7.12 or higher if you are using SQL Parser.
In the GUI, navigate to the Deployment Settings section of the project settings (Settings tab), then check the checkbox next to 'Enable Parser'. NOTE: As a project-level setting, checking the checkbox for 'Enable Parser' will enable SQL Parser globally for the entire project.
The setting is represented in thedatical.project
file byenableSqlParser=true.
Code Block enableSqlParser=[true | false]
Disabling SQL Parser
You can selectively disable the SQL Parser after it has been enabled, either at the folder level or on the change set level.
At the Folder level
You can disable SQL Parser at the folder level either temporarily or permanently in the metadata.properties file for that folder:
Set disableSqlParser=true
in the metadata.properties
file for any folders that you do not want SQL Parser to process.
Code Block |
---|
disableSqlParser=[true | false] |
At the Change Set level
You can disable SQL Parser for a specific change set by manually editing the changelog.xml to add disableSqlParser="true":
...
To work around the problem, turn off SQL Parser temporarily using disableSqlParser=true
in metadata.properties
for the folder where the script failed, and then run deployPackager again.
...
If you have a directory hierarchy for SQL scripts remember that metadata.properties
effects affects the directory it is in and all subdirectories. Set the property in the directory that is most local to the script that causes the packaging error. The directory hierarchy root is as follows:
...
Note |
---|
Selectively disabling the SQL Parser using the |
Additional Files Produced
When SQL parsing is enabled, a file is produced after any of the following operations:
...