Determine Whether Reversion Is Possible

This will make all necessary modifications to disk structures so that the Informix Dynamic Server space will be compatible with Informix Dynamic Server Version 7.31 Beginning process of reverting system to 7.31 ... ... Reversion complete. Install Informix Dynamic Server Version 7.31 before reinitializing. Do you wish to continue (y/n)? qaonmode -b 7.31: passed

Table 22. Reversion Restrictions
7.x	9.2x	9.30	9.40	Restriction
x	x	x	x	Column-level encryption: If your tables contain encrypted data, you should not revert to a version of the server that does not contain encryption support (any version prior to Version 10.0) because you will not be able to interpret column data without writing a custom DataBlade module that is equivalent to the facilities provided by Dynamic Server. Dynamic Server does not record whether encrypted data is stored in a database.
x	x	x	x	DataBlade User-Defined Routines (UDRs) that Have the EXTERNAL Clause: The database server administrator (DBSA), user informix by default, must revoke the "extend" role from all users to whom the role has been granted.
x	x	x	x	Built-in UDRs: Many system catalog tables use built-in UDRs. If you changed the definition of a built-in UDR, you must drop the UDR before reverting.
x	x	x	x	Multiple INOUT Parameter Support: You must drop any new UDRs that were created using INOUT parameters before reverting.
x	x	x	x	Default Roles: During reversion, the defrole column is dropped from the sysusers table. You must revoke default roles from users before reverting.
x	x	x	x	Tables and Indexes that Use Fragment Partition Syntax: If you created tables using the new fragment partition syntax, you must drop the tables or you must use the ALTER FRAGMENT INIT statement to change the syntax before reverting to a pre-10.0 version of Dynamic Server. Dynamic Server drops the partname column from the sysfragments table during reversion.
x	x	x	x	External Optimizer Directives: You cannot revert if external optimizer directives have been created.
x	x	x	x	New Configuration Parameters: These cannot be reverted.
x	x	x	x	Non-default Page Size: If you specified the page size for a standard or temporary dbspace, instead of using the default dbspace page size, you must drop all non-default-size dbspaces before you revert to a pre-10.0 version of Dynamic Server.
x	x	x	x	IPv6 Addresses: If you used an IPv6 address in the SQLHOSTS file during reversion, you must replace the IPv6 address with either the machine name or IPv4 address assigned to the machine.
x	x	x	x	UDRs and Applications That Use TRUNCATE Syntax or the am_truncate() Method: You cannot revert these to a pre-10.0 version of Dynamic Server. Dynamic Server.
x	x	x	x	Procedures and Triggers Created with Version 9.40 or 10.0: You must drop all triggers and procedures created with the new version before reverting.
x	x	x	x	JAVA UDRs That Have Been Compiled Using JDK 1.4.x. These must be recompiled with older JDK versions. For details, see Recompile Java UDRs That Have Been Compiled Using JDK 1.4.x.
x	x	x	x	No in-place ALTER TABLE statement performed in Version 10.0 should be outstanding against any table. If a user table has an incomplete new in-place ALTER operation, then you need to ensure that the in-place ALTER operation is complete by running a dummy UPDATE statement against the table. If the reversion process does not complete successfully because of in-place ALTER operations, it lists all the tables that need dummy updates. You need to perform a dummy update on each of the tables in the list before you can revert to the older database server. If an in-place ALTER operation is incomplete against a system table, run the following script while connected to the database for reversion to a 7.3x or 7.24 database server from Dynamic Server 10.0: $INFORMIXDIR/etc/dummyupds7x.sql Note: Any in-place alter performed in a Dynamic Server Version prior to Version 10.0 will successfully revert and dummy updates are not necessary for them. However, any new in-place alter that you performed in Version 10.0 must be completed before reversion.
x	x	x		Dbspaces cannot have chunks larger than 2 GB or in the new chunk format, chunks that extend further than 2 GB into their device or file, or contain more than 2047 chunks. For more information, see Chunk Format.
x	x	x		No files larger than 2 GB should be stored in or in use by the database server.
x	x	x		The TAPESIZE or LTAPESIZE configuration parameters cannot be set to 0.
x	x	x		The ALARMPROGRAM configuration parameter cannot be set to the alarmprogram.sh file.
x	x	x		The LRU_MAX_DIRTY or LRU_MIN_DIRTY configuration parameters must not be set to a value of type FLOAT. To revert, set them to integers. (These configuration parameters have been removed in Version 10.0.)
x	x	x		UDRs should not use multiple IN or OUT parameters. Drop all such UDRs before reversion.
x	x	x		UDRs and stored procedures should not use named return parameters.
x	x	x		Sequence objects should not be in use. Drop all sequences before reversion.
x	x	x		No triggers created with the INSTEAD OF clause should be in use. Drop all such triggers before reversion.
x	x	x		Multiple collations among indexes, stored procedures, triggers, and constraints should not be in use.
x	x	x		Functional indexes cannot contain more than 16 parameters.
x	x	x		High-Data Availability Replication and Enterprise Replication cannot co-exist on the same database server.
x	x	x		The LVARCHAR(n) data types should not be in use if n is not equal to 2042.
x	x	x		You cannot revert to an earlier database server from a database server that has had extensions added unless you remove the extensions. You need to remove any new data types or routines that you created either explicitly or by registering a different version of a DataBlade module. To be able to revert, you need to downgrade any DataBlade module to the version that was registered prior to reversion and explicitly drop any data types and routines that were created outside of any DataBlade registration. For information on how to use DataBlade modules, see the DataBlade documentation.
x	x	x		No new user-defined or SPL routines should have been created in the converted databases (either implicitly or explicitly). If you plan to use dbexport to export a database containing existing user-defined or SPL routines, you must drop these routines prior to reversion.
x	x	x		No new triggers should have been defined in the converted databases.
x	x	x		No fragment expressions or check constraints created on the 9.40 or 10.0 database server should exist in the databases. To revert, convert fragmented tables to nonfragmented tables by detaching fragment expressions. You cannot use ALTER TABLE or ALTER INDEX statements to change fragment strategies that existed before the conversion to Dynamic Server 9.40.
x				Indexes created with Dynamic Server 10.0 and an opclass that supports nearest-neighbor search cannot be reverted to the earlier database server.
x				Reversion fails if, for an index, the value of item_nvarchar is `255` or higher.
x				If Dynamic Server uses a newly added log file, you cannot reset the status of the file to "newly added" after reversion to the earlier database server.
x				A DataBlade module that uses the PER_STMT_EXEC or PER_STMT_PREP memory duration cannot be used with the earlier database server.
x				You cannot revert a database that was created with the database server from which you are reverting. Drop the database before you attempt reversion.
x				Select triggers should not be in use.
x				User-defined statistics should not be in use.
x				No long identifiers or long usernames should be in use. Before reversion, make sure that the R-tree indexes do not use long identifiers as indexed column names, opclass names, or opclass function names. Also, make sure that the following disk structures do not use long identifiers: Database tablespaces (owner and database name length) Tablespace tablespaces (owner and tablespace name length) Dbspaces (owner and dbspace name length) and chunks (path length)
x				No storage space should have a name more than 18 characters long.
x				No new routine languages should be defined in the converted databases.
x				No new language authorizations must have been done in the converted databases.
x				No new operator classes, casts, or extended types should be defined in the 10.0 database server.
x				No semidetached indexes should be in the databases.
x				The databases cannot have tables whose primary access method is a user-defined access method.
x				Databases cannot have typed tables.
x				Tables cannot have any user-defined type columns.
x				Tables cannot have named row types with default values.
x				All indexes must be B-tree indexes with a total key length less than or equal to 255.
x				Tables cannot have any functional or VII indexes.
x				Databases cannot use any extensibility features, including user-defined access methods, user-defined types, aggregates, routine languages, language authorizations, trace messages, trace message classes, operator classes, errors, type and casts.

Table 22. Reversion Restrictions

7.x

9.2x

9.30

9.40

Restriction

Column-level encryption: If your tables contain encrypted data, you should not revert to a version of the server that does not contain encryption support (any version prior to Version 10.0) because you will not be able to interpret column data without writing a custom DataBlade module that is equivalent to the facilities provided by Dynamic Server. Dynamic Server does not record whether encrypted data is stored in a database.

DataBlade User-Defined Routines (UDRs) that Have the EXTERNAL Clause: The database server administrator (DBSA), user informix by default, must revoke the "extend" role from all users to whom the role has been granted.

Built-in UDRs: Many system catalog tables use built-in UDRs. If you changed the definition of a built-in UDR, you must drop the UDR before reverting.

Multiple INOUT Parameter Support: You must drop any new UDRs that were created using INOUT parameters before reverting.

Default Roles: During reversion, the defrole column is dropped from the sysusers table. You must revoke default roles from users before reverting.

Tables and Indexes that Use Fragment Partition Syntax: If you created tables using the new fragment partition syntax, you must drop the tables or you must use the ALTER FRAGMENT INIT statement to change the syntax before reverting to a pre-10.0 version of Dynamic Server. Dynamic Server drops the partname column from the sysfragments table during reversion.

External Optimizer Directives: You cannot revert if external optimizer directives have been created.

New Configuration Parameters: These cannot be reverted.

Non-default Page Size: If you specified the page size for a standard or temporary dbspace, instead of using the default dbspace page size, you must drop all non-default-size dbspaces before you revert to a pre-10.0 version of Dynamic Server.

IPv6 Addresses: If you used an IPv6 address in the SQLHOSTS file during reversion, you must replace the IPv6 address with either the machine name or IPv4 address assigned to the machine.

UDRs and Applications That Use TRUNCATE Syntax or the am_truncate() Method: You cannot revert these to a pre-10.0 version of Dynamic Server. Dynamic Server.

Procedures and Triggers Created with Version 9.40 or 10.0: You must drop all triggers and procedures created with the new version before reverting.

JAVA UDRs That Have Been Compiled Using JDK 1.4.x. These must be recompiled with older JDK versions. For details, see Recompile Java UDRs That Have Been Compiled Using JDK 1.4.x.

No in-place ALTER TABLE statement performed in Version 10.0 should be outstanding against any table.

If a user table has an incomplete new in-place ALTER operation, then you need to ensure that the in-place ALTER operation is complete by running a dummy UPDATE statement against the table. If the reversion process does not complete successfully because of in-place ALTER operations, it lists all the tables that need dummy updates. You need to perform a dummy update on each of the tables in the list before you can revert to the older database server.

If an in-place ALTER operation is incomplete against a system table, run the following script while connected to the database for reversion to a 7.3x or 7.24 database server from Dynamic Server 10.0:

$INFORMIXDIR/etc/dummyupds7x.sql

Note:

Any in-place alter performed in a Dynamic Server Version prior to Version 10.0 will successfully revert and dummy updates are not necessary for them. However, any new in-place alter that you performed in Version 10.0 must be completed before reversion.

Dbspaces cannot have chunks larger than 2 GB or in the new chunk format, chunks that extend further than 2 GB into their device or file, or contain more than 2047 chunks. For more information, see Chunk Format.

No files larger than 2 GB should be stored in or in use by the database server.

The TAPESIZE or LTAPESIZE configuration parameters cannot be set to 0.

The ALARMPROGRAM configuration parameter cannot be set to the alarmprogram.sh file.

The LRU_MAX_DIRTY or LRU_MIN_DIRTY configuration parameters must not be set to a value of type FLOAT. To revert, set them to integers. (These configuration parameters have been removed in Version 10.0.)

UDRs should not use multiple IN or OUT parameters. Drop all such UDRs before reversion.

UDRs and stored procedures should not use named return parameters.

Sequence objects should not be in use. Drop all sequences before reversion.

No triggers created with the INSTEAD OF clause should be in use. Drop all such triggers before reversion.

Multiple collations among indexes, stored procedures, triggers, and constraints should not be in use.

Functional indexes cannot contain more than 16 parameters.

High-Data Availability Replication and Enterprise Replication cannot co-exist on the same database server.

The LVARCHAR(n) data types should not be in use if n is not equal to 2042.

You cannot revert to an earlier database server from a database server that has had extensions added unless you remove the extensions.

You need to remove any new data types or routines that you created either explicitly or by registering a different version of a DataBlade module.

To be able to revert, you need to downgrade any DataBlade module to the version that was registered prior to reversion and explicitly drop any data types and routines that were created outside of any DataBlade registration. For information on how to use DataBlade modules, see the DataBlade documentation.

No new user-defined or SPL routines should have been created in the converted databases (either implicitly or explicitly). If you plan to use dbexport to export a database containing existing user-defined or SPL routines, you must drop these routines prior to reversion.

No new triggers should have been defined in the converted databases.

No fragment expressions or check constraints created on the 9.40 or 10.0 database server should exist in the databases. To revert, convert fragmented tables to nonfragmented tables by detaching fragment expressions.

You cannot use ALTER TABLE or ALTER INDEX statements to change fragment strategies that existed before the conversion to Dynamic Server 9.40.

Indexes created with Dynamic Server 10.0 and an opclass that supports nearest-neighbor search cannot be reverted to the earlier database server.

Reversion fails if, for an index, the value of item_nvarchar is 255 or higher.

If Dynamic Server uses a newly added log file, you cannot reset the status of the file to "newly added" after reversion to the earlier database server.

A DataBlade module that uses the PER_STMT_EXEC or PER_STMT_PREP memory duration cannot be used with the earlier database server.

You cannot revert a database that was created with the database server from which you are reverting.

Drop the database before you attempt reversion.

Select triggers should not be in use.

User-defined statistics should not be in use.

No long identifiers or long usernames should be in use.

Before reversion, make sure that the R-tree indexes do not use long identifiers as indexed column names, opclass names, or opclass function names.

Also, make sure that the following disk structures do not use long identifiers:

Database tablespaces (owner and database name length)
Tablespace tablespaces (owner and tablespace name length)
Dbspaces (owner and dbspace name length) and chunks (path length)

No storage space should have a name more than 18 characters long.

No new routine languages should be defined in the converted databases.

No new language authorizations must have been done in the converted databases.

No new operator classes, casts, or extended types should be defined in the 10.0 database server.

No semidetached indexes should be in the databases.

The databases cannot have tables whose primary access method is a user-defined access method.

Databases cannot have typed tables.

Tables cannot have any user-defined type columns.

Tables cannot have named row types with default values.

All indexes must be B-tree indexes with a total key length less than or equal to 255.

Tables cannot have any functional or VII indexes.

Databases cannot use any extensibility features, including user-defined access methods, user-defined types, aggregates, routine languages, language authorizations, trace messages, trace message classes, operator classes, errors, type and casts.