|
|
|
When moving a copy of applications and databases to the new Ingres installation, you must do the following:
|
|
|
A database cannot be built on an Ingres installation until reserved keyword conflicts are corrected.
Check for and fix reserved word conflicts. Also, check for reserved word conflicts in application code, specifically in dynamically created tables and views.
The additional reserved keywords in Ingres are mostly to support additions to SQL. If words like level, key, or comment are used as column names, you must change them.
The SQL parser recognizes most reserved keywords from context, and usually resolves keyword conflicts without error, so you may not have to change reserved words used as names. If time permits, however, we recommend that you avoid SQL reserved words.
For a complete list of reserved words, see the appendix "Keywords."
|
|
|
In Ingres 2006, the data descriptor used throughout the Ingres system changed because of the introduction of the column-level collation specification feature. This data descriptor is also compiled into imaged Applications-By-Forms (ABF) applications.
After upgrading, all ABF applications should be re-imaged. Delete the contents of the ABF object directory, $ING_ABFDIR/database-name/app-name, and then re-image.
|
|
|
When upgrading from 6.4, to support new Report-Writer syntax, a space is required after all dot-commands. For example, ".NL3" must be changed to ".NL 3".
UNIX: To fix such occurrences automatically, you can use the following "sed" commands:
sed -e 's/\([<space><tab>]\.[a-zA-Z][a-zA-Z]*\)\([0-9]\)/\1 \2/' foo.rw | \
sed -e 's/^\(\.[a-zA-Z][a-zA-Z]*\)\([0-9]\)/\1 \2/' >newfoo.rw 
Compare the old and new files (foo.rw and newfoo.rw) to ensure that only the expected changes occurred. For example, you want to avoid an unwanted "fix" to a literal string.
An alternative to altering Report-Writer files is to sreport them into a database, then copyrep the reports back out.
|
|
|
If string parameters that contain quotes are passed to Report-Writer, runtime errors may occur. These errors may be caused by a change to the UNIX command parameter control file utexe.def.
If such an error occurs, you can change the command parameter back to the Ingres 6.4 utexe.def settings. After saving the changed file, retest and see whether the error still occurs.
This problem only occurs with application systems developed under Ingres 6.4. However, you may need to check for the problem even if you are upgrading from a more recent version. Generally, the utexe.def file is replaced with every release of Ingres. Therefore, even if you have resolved this issue during a prior upgrade, you will have to check for it again each time you upgrade.
|
|
|
To change the command parameter back to the Ingres 6.4 utexe.def settings:
|
|
|
As of Ingres 2006 Release 2, the ANSI date and time data types DATE, TIME, TIMESTAMP, and INTERVAL are supported. In previous releases, Ingres supported one date data type that could store dates, times, intervals, and time stamps. The previous date type is renamed to INGRESDATE.
The configuration parameter date_type_alias controls whether the keyword DATE used for column data type refers to INGRESDATE or ANSIDATE data type. If this parameter is not set then the DATE keyword cannot be used in SQL statements.
When migrating from an earlier version of Ingres, the existing date data in the database is not affected. The data is still a valid INGRESDATE data type.
If you use the new date format (ANSIDATE), existing scripts and database procedures with the old DATE column definitions may need to be changed.
Note: When installing or upgrading Ingres using a non interactive install and no value for II_DATE_TYPE_ALIAS is provided in the response file, the value defaults to INGRESDATE.