Ispirer Ispirer
 

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

sqlways:command-line:sqlways-ini:ddl-section [February 08, 2019, 12:06:07 PM]
darya.prikhodkina
sqlways:command-line:sqlways-ini:ddl-section [May 28, 2019, 02:20:07 PM] (current)
alexandr.kirpichny
Line 22: Line 22:
 | **DROP_TABLE_CASCADE_CONSTRAINTS** | If Yes is specified, the CASCADE CONSTRAINTS option is generated in the DROP TABLE statement. Currently this option is supported by Oracle only. \\ This option is available only if the target database is Oracle and GENERATE_DROP_TABLE is set to Yes. The default value is No. | | **DROP_TABLE_CASCADE_CONSTRAINTS** | If Yes is specified, the CASCADE CONSTRAINTS option is generated in the DROP TABLE statement. Currently this option is supported by Oracle only. \\ This option is available only if the target database is Oracle and GENERATE_DROP_TABLE is set to Yes. The default value is No. |
 | **GENERATE_DROP_INDEX** | If Yes is specified, the DROP INDEX statement is generated before each CREATE INDEX statement. The default value is No. Possible values - Yes, No. \\ This option can be helpful when scripts for indexes are re-executed without recreating the table. | | **GENERATE_DROP_INDEX** | If Yes is specified, the DROP INDEX statement is generated before each CREATE INDEX statement. The default value is No. Possible values - Yes, No. \\ This option can be helpful when scripts for indexes are re-executed without recreating the table. |
-| **OUTSCHEMA** | Outputs schema name. | +| **OUTSCHEMA** | This option can be used only when "EMPTY_SCHEMA" option is set to "No". In this option user can specify a schema name that will be used in the generated target code, instead of original one. When this option is empty, used original schema names. \\ Empty  by default. | 
-| **EMPTY_SCHEMA** | for /EMPS option. Possible values - Yes, No. |+| **EMPTY_SCHEMA** | This option defines whether the schema names should be used in the generated target script. If it is set to "Yes" - schema names will be removed. If set to "No" - schema names will be left as in the generated target code\\ Possible values - Yes, No. |
 | **COLUMN_NAME_CASE** | This option specifies the case of column names in SQL statements. Possible values - Upper, Lower. If no value is specified, the case of the column names is not changed and column names are used as they are provided in the source database. | | **COLUMN_NAME_CASE** | This option specifies the case of column names in SQL statements. Possible values - Upper, Lower. If no value is specified, the case of the column names is not changed and column names are used as they are provided in the source database. |
 | **USE_CONSTRAINT_NAMES** | If Yes is specified, constraint names of the source database will be used in generated DDL scripts. Otherwise, constraint names will be skipped. The default value is No. Possible values - Yes, No. | | **USE_CONSTRAINT_NAMES** | If Yes is specified, constraint names of the source database will be used in generated DDL scripts. Otherwise, constraint names will be skipped. The default value is No. Possible values - Yes, No. |
Line 83: Line 83:
 | **EXPORT_CONSTRAINTS_FOR_QUERIES** | This option controls whether the constraints should be converted when performing conversion using the queries. \\ Possible values - "Yes", "No". \\ Default value - "Yes". | | **EXPORT_CONSTRAINTS_FOR_QUERIES** | This option controls whether the constraints should be converted when performing conversion using the queries. \\ Possible values - "Yes", "No". \\ Default value - "Yes". |
 | **CONVERT_MM_TAB** | This option defines how multi-member tables will be converted from DB2 AS 400 into Microsoft SQL Server database. If this option is set to "SINGLE", our tool will try to extract the data from all the members created on this table in DB2 database and load all the extracted data into one table in MSSQL. In that case table in MSSQL will have the same name as original table in DB2. If this option is set to "MULTIPLE", our tool will extract information about the table and data from each member and will create separate tables in MSSQL for each member with the same structure as the original table. It means that in the target database we will have multiple tables with data and with the same name as the corresponding member. \\ Possible values - "SINGLE" or "MULTIPLE". \\ Default value - "SINGLE". | | **CONVERT_MM_TAB** | This option defines how multi-member tables will be converted from DB2 AS 400 into Microsoft SQL Server database. If this option is set to "SINGLE", our tool will try to extract the data from all the members created on this table in DB2 database and load all the extracted data into one table in MSSQL. In that case table in MSSQL will have the same name as original table in DB2. If this option is set to "MULTIPLE", our tool will extract information about the table and data from each member and will create separate tables in MSSQL for each member with the same structure as the original table. It means that in the target database we will have multiple tables with data and with the same name as the corresponding member. \\ Possible values - "SINGLE" or "MULTIPLE". \\ Default value - "SINGLE". |
-| **ORACLE_PKG_TO_FN** | This option allows to change package conversion structure logic for Oracle to Greenplum migration direction. By default Oracle packages are converted to sets of Greenplum functions corresponding to source package routines. Package global variables are converted using temporary tables. If the option is set to 'Yes', Oracle package will be converted into one function which takes 1 parameter to pass package routine name and branches package routines logic via IF...ELSE structures.Package global variables in that case will be converted to function local variables.\\ Possible values - "Yes", "No". \\ Default value - "Yes". |+| **ORACLE_PKG_TO_FN** | This option allows to change package conversion structure logic for Oracle to Greenplum migration direction. By default Oracle packages are converted to sets of Greenplum functions that correspond to source package routines. Package global variables are converted using temporary tables. If the option is set to 'Yes', Oracle package will be converted into one function which takes 1 parameter to pass package routine name and branches package routines logic via IF...ELSE structures. In this case package global variables will be converted to function local variables.\\ Possible values - "Yes", "No". \\ Default value - "Yes". | 
 +| **APP_PARAMS_IN_SQL** | This option defines whether the application parameters are used in source Sybase ASE sql code. If this option is set to "yes" parser will try to find such parameters and leave them as is. \\ Possible values - "Yes", "No" or Empty. \\ Default value - "No" or Empty. | 
 +| **VARCHAR_PAR_LEN** | When migrating from Oracle to MySQL, you can specify your own length for VARCHAR parameters in procedures and functions. Specified number will be used as a length of VARCHAR parameters in MySQL procedures and functions. | 
 +| **FK_SELECTED_TABLES_ONLY** | This option defines whether to generate Foreign Key constraints that references tables that were not selected for conversion. If this option is set to "Yes" then Foreign Keys will be generated only for tables that were specified for current conversion process. If this option is set to "No", then will be generated all the Foreign Key created on selected tables, even if they refers to the tables that were not selected for conversion. \\ Possible values - "Yes", "No" or Empty. \\ Default value - "No" or Empty. |
  
  
sqlways/command-line/sqlways-ini/ddl-section.1549627567.txt.gz · Last modified: February 08, 2019, 12:06:07 PM by darya.prikhodkina
 
© 1999-2019, Ispirer Systems Ltd.
All Rights Reserved.  Privacy Statement