Oracle to Informix

IBM Software Group IBM Information Management

Version 1.6 1

Oracle to IBM Informix Server Porting Guide A discussion of porting issues and Informix Server 11 Prepared By:

Business Partner Technical Enablement Competitive Technologies and Enablement IBM Data Servers, IBM Software Group June 2012


Version 1.6 2

Copyright IBM Corporation 2012. All Rights Reserved.

Trademarks IBM, AIX, DB2, DB2 Universal Database, Informix, and iSeries are trademarks of the International Business Machines Corporation in the United States, other countries or both. UNIX and Unix-based trademarks and logos are trademarks or registered trademarks of The Open Group. Intel and Intel-based trademarks and logos are trademarks or registered trademarks of Intel Corporation. Windows is a trademark of Microsoft Corporation in the United States, and other countries, or both. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other company, product or service names may be the trademarks or service marks of others.

Disclaimer References in this publication to IBM products or services do not imply that IBM intends to make them available in all countries in which IBM operates.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

The use of this information or the implementation of any of these techniques is your responsibility and depends on your ability to evaluate and integrate them into your operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

The information in this white paper is provided AS IS without warranty. Such information was obtained from publicly available sources, is current as of December 2011, and is subject to change. Any performance data included in the paper was obtained in the specific operating environment and is provided as an illustration. Performance in other operating environments may vary. More specific information about the capabilities of products described should be obtained from the suppliers of those products.


Version 1.6 3

Document History Revision History

Authoring Original Document (May 2000) Glen Black, Frank Martino & Tim Tobey Informix Software Incorporated, Partner Engineering Organization Revisions for Informix Dynamic Server.2000, Version 6 (July 2000) Tim Tobey Informix Software Incorporated, Partner Engineering Organization Updated to IBM Informix Dynamic Server Database Version 9, Release 4. (February 2004) Christine Normile Informix Dynamic Server Product Manager IBM Software Group, Information Management Updated material for Sequence Objects (December 2004) Sam Marino DB2 Business Partner Technical Enablement IBM Information Management Solutions, IBM Software Group Updated to IBM Informix Dynamic Server Database Version 10.00 (January 2006) Sam Marino Business Partner Technical Enablement Data Services IBM Information Management, IBM Software Group Updated to IBM Informix Dynamic Server Database Version 11.10 (December 2007) Sam Marino IBM Business Partner Technical Enablement Data Services IBM Information Management, IBM Software Group Updated material for delimited identifiers, metadata extraction, type conversion, and miscellaneous (June 2012) Chris Golledge IBM Information Management, IBM Software Group

Contributions Technical Reviewers Keshava Murthy IBM Informix Database Server Development IBM Software Group, Information Management Lakshman Sakaray IBM Database Migration Toolkit IBM Software Group, Information Management


Version 1.6 4

Table of Contents

C H A P T E R 1 : INTRODUCTION ............................................................................................ 8

PURPOSE ........................................................................................................................................ 8 PRODUCT OVERVIEW ....................................................................................................................... 8 ORGANIZATION ................................................................................................................................ 8 CONVENTIONS ................................................................................................................................ 9

C H A P T E R 2 : DEFINING THE PROBLEM SPACE ............................................................ 11

EXTRACTING THE OBJECTS TO BE MIGRATED .................................................................................. 11 Working With Oracle Dump Files ............................................................................................ 11

C H A P T E R 3 : DATA DEFINITION LANGUAGE ................................................................. 15

IDENTIFIERS .................................................................................................................................. 15 Delimited identifiers ................................................................................................................. 15 Explicit versus implicit schema/owner names ......................................................................... 17 Reserved words or keywords .................................................................................................. 18 Summary ................................................................................................................................. 19

DATABASES .................................................................................................................................. 19 Databases, database names and instances ........................................................................... 19 ANSI vs. non-ANSI .................................................................................................................. 20

TABLESPACES AND DBSPACES ....................................................................................................... 20 TABLES ......................................................................................................................................... 21

Attributes and general syntax .................................................................................................. 21 Lock mode ............................................................................................................................... 21 Storage .................................................................................................................................... 21 Constraints .............................................................................................................................. 22 ALTER TABLE ......................................................................................................................... 22 Data Partitioning ...................................................................................................................... 23

DATA TYPES .................................................................................................................................. 25 Numeric ................................................................................................................................... 25 CHAR, VARCHAR and LVARCHAR ....................................................................................... 26 Date and Time ......................................................................................................................... 27 Interval ..................................................................................................................................... 27 Raw data and Large Objects ................................................................................................... 28 ROWID .................................................................................................................................... 28 User-defined types .................................................................................................................. 29 Complex data types ................................................................................................................. 30

SEQUENCE OBJECTS ..................................................................................................................... 30 Oracle sequences.................................................................................................................... 30 Informix sequences ................................................................................................................. 30

INDEXES ....................................................................................................................................... 30 Composite indexes .................................................................................................................. 30 Maximum key size ................................................................................................................... 31 Index fragmentation ................................................................................................................. 31 General index information ....................................................................................................... 31

VIEWS .......................................................................................................................................... 32 STORED PROCEDURES AND TRIGGERS ........................................................................................... 32 ORACLE EXTENSIONS .................................................................................................................... 33

C H A P T E R 4 : DATA MANIPULATION LANGUAGE .......................................................... 34

SQL ............................................................................................................................................. 34 Labels using keywords ............................................................................................................ 34 Inequality operations ............................................................................................................... 34 Selects ..................................................................................................................................... 34 Optimizer directives ................................................................................................................. 34


Version 1.6 5

External optimizer directives .................................................................................................... 35 Inserts ...................................................................................................................................... 36 Temporary tables ..................................................................................................................... 36 Outer joins ............................................................................................................................... 36 Sorts ........................................................................................................................................ 36 Exceptions ............................................................................................................................... 37 Correlation names ................................................................................................................... 37 Aliases ..................................................................................................................................... 37 Hierarchical queries ................................................................................................................. 37 Truncate .................................................................................................................................. 39

HOST VARIABLES ........................................................................................................................... 40 DATE AND TIME FUNCTIONS ........................................................................................................... 41

SYSDATE ................................................................................................................................ 41 Number formats ....................................................................................................................... 41 Date formats ............................................................................................................................ 42 The RR date format element ................................................................................................... 43

USER-DEFINED ROUTINES .............................................................................................................. 43 COMPATIBLE SQL FUNCTIONS ....................................................................................................... 43 AGGREGATE FUNCTIONS ................................................................................................................ 43 MATHEMATICAL FUNCTIONS ........................................................................................................... 44 STRING FUNCTIONS ....................................................................................................................... 44

LENGTH .................................................................................................................................. 44 LTRIM and RTRIM .................................................................................................................. 44 Oracle Extensions ................................................................................................................... 44

OTHER ORACLE FUNCTIONS .......................................................................................................... 44 MACROS ....................................................................................................................................... 45

%ISOPEN and %NOT FOUND ............................................................................................... 45 %ROWTYPE ........................................................................................................................... 45 %TYPE .................................................................................................................................... 45

PSEUDO-COLUMNS ........................................................................................................................ 45 LEVEL ..................................................................................................................................... 46 ROWID .................................................................................................................................... 46 ROWNUM ................................................................................................................................ 46

UPDATE USING CURSORS ............................................................................................................... 49 SYSTEM TABLES ............................................................................................................................ 50 STORED PROCEDURES .................................................................................................................. 50

Size limit .................................................................................................................................. 50 Parameter limit ........................................................................................................................ 50 Packages ................................................................................................................................. 51 Routines .................................................................................................................................. 51 Exceptions ............................................................................................................................... 51 Error handling .......................................................................................................................... 52 Cursors .................................................................................................................................... 52 Variable declaration and assignment ...................................................................................... 53 Boolean ................................................................................................................................... 53 Binary data types ..................................................................................................................... 53 Dynamic SQL .......................................................................................................................... 53 Compiler .................................................................................................................................. 53

TRIGGERS ..................................................................................................................................... 54 CONSTRAINTS ............................................................................................................................... 55 DUAL TABLE ................................................................................................................................. 55

C H A P T E R 5 : EMBEDDED SQL......................................................................................... 57

HOST VARIABLES ........................................................................................................................... 57 Declaration override ................................................................................................................ 57 Arrays ...................................................................................................................................... 57 Formatting ............................................................................................................................... 58

SQL STRUCTURES ........................................................................................................................ 59


Version 1.6 6

SQLCA .................................................................................................................................... 59 SQLDA .................................................................................................................................... 60 ORACA .................................................................................................................................... 61

PRE-COMPILER OPTIONS................................................................................................................ 61 EMBEDDED PL/SQL ...................................................................................................................... 61 ORACLE CALL INTERFACE .............................................................................................................. 61

Database library calls .............................................................................................................. 62 Global area processing ............................................................................................................ 62 Fetch cycle .............................................................................................................................. 62 RAW binary data type processing ........................................................................................... 62 Parameter bindings ................................................................................................................. 62

EMBEDDED SQL FOR C ................................................................................................................. 63 VARCHAR ............................................................................................................................... 63 Host variables .......................................................................................................................... 63

EMBEDDED SQL FOR COBOL ....................................................................................................... 63 VARCHAR ............................................................................................................................... 63 Level 88 ................................................................................................................................... 64 SQLDA .................................................................................................................................... 64 REDEFINES ............................................................................................................................ 64 Tips .......................................................................................................................................... 64

ODBC .......................................................................................................................................... 64

C H A P T E R 6 : APPLICATION ARCHITECTURE ................................................................ 65

TRANSACTION PROCESSING ........................................................................................................... 65 Autonomous Transaction ......................................................................................................... 66 Savepoints ............................................................................................................................... 67

CONCURRENCY ............................................................................................................................. 67 Row Level Locking .................................................................................................................. 67 Transaction Isolation Level ...................................................................................................... 68

C H A P T E R 7 : SECURITY ................................................................................................... 70

USER AUTHENTICATION ................................................................................................................. 70 Operating system security ....................................................................................................... 70 Non-operating system security ................................................................................................ 70

ROLE BASED AUTHORITY ............................................................................................................... 71 COLUMN-LEVEL ENCRYPTION ......................................................................................................... 71

Passwords and hints ............................................................................................................... 71 Encrypting a column ................................................................................................................ 72 Querying an encrypted column................................................................................................ 72 Performance impact of encryption ........................................................................................... 73 Storage considerations ............................................................................................................ 73 Compliance regulations ........................................................................................................... 73

C H A P T E R 8 : ENVIRONMENT ........................................................................................... 74

SCRIPTS ....................................................................................................................................... 74 SQL script substitution variables ............................................................................................. 74

UTILITIES ...................................................................................................................................... 75 SYSTEM CATALOG ......................................................................................................................... 75

C H A P T E R 9 : USING BLADELETS .................................................................................... 76

WHAT IS A BLADELET? .................................................................................................................. 76 INFORMIX EXEC BLADELET FOR DYNAMIC SQL ............................................................................... 77 SQLLIB DATABLADE MODULE (SQLLIBC.1.1 / SQLLIBJ.1.1) ............................................................ 78

A P P E N D I X A: PLANNING GUIDE ..................................................................................... 79

A P P E N D I X B: SYNTAX COMPARISON ............................................................................ 82


Version 1.6 7

A P P E N D I X C: DATABASE CONCEPTS ........................................................................... 84

A P P E N D I X D: SAMPLE CODE .......................................................................................... 85

DATE ARITHMETIC ......................................................................................................................... 88 UNITS Keyword ....................................................................................................................... 88 Using EXTEND function .......................................................................................................... 88

STRING REPRESENTATION OF DATE AND TIME ................................................................................. 88 Day and date ........................................................................................................................... 88 Abbreviation of day of week .................................................................................................... 88

USING AN INFORMIX COLLECTION DATA TYPE .................................................................................. 89 A collection data type as a VARRAY ....................................................................................... 89 Using MULTISET and ROW to replace PL/SQL TABLE and RECORD types ........................ 91

A P P E N D I X E: COUNTING SYSTEM OBJECTS ............................................................... 93

USING THE SYSTEM CATALOG ........................................................................................................ 93 System catalog ........................................................................................................................ 93

USING SQL CODE ......................................................................................................................... 94 Built-in function references ...................................................................................................... 94 Object types and counts .......................................................................................................... 95

A P P E N D I X F: DATA TYPE MAPPING .............................................................................. 97

DOUBLE ................................................................................................................................ 101 VARCHAR ............................................................................................................................. 101 NUMBER ............................................................................................................................... 101 National language types ........................................................................................................ 102 ROWID .................................................................................................................................. 102 %TYPE .................................................................................................................................. 102 %ROWTYPE ......................................................................................................................... 102 FLOAT ................................................................................................................................... 102 XMLType ............................................................................................................................... 103


Version 1.6 8

C H A P T E R 1 : Introduction

This document is a technical document describing the differences between Oracle and Informix Dynamic Server (IDS) functionality and syntax. . This porting guide details differences between Oracles 10g release 1 (10.1) and 10g release 2 (10.2) and Informix Dynamic Server (version 11.10). In addition, it can be a useful reference for all migrations between the two database servers regardless of version. In addition to DDL, DML and overall SQL syntax, this document explores the differences between Oracle and Informix with regards to object technology through the use of large objects, user defined types, and user defined routines. It also looks at the differences between Oracles table partitioning and Informixs table fragmentation. Part of the explanation is a discussion on what needs to be changed to make an application running on an Oracle database run on an Informix database. If there is more than one way to port some piece of functionality, alternatives and recommendations are also discussed. This document is intended to be a living document. Missing items, better ways of implementing Oracle functionality in Informix other than what is documented here, examples to better illustrate a point, and other suggestions should be sent to Chris Golledge ([email protected]) so they may be included with future revisions.

Purpose This document should be used as a guide to assist in porting applications that run on an Oracle database server to run on an Informix database server. Regardless of whether a porting effort will be completely manual or if tools will be utilized, this document can provide value. Obviously, if the port is performed manually, this guide will provide the most value. If the port will utilize tools, then analysis can be performed using this guide to determine how much of the application the tools will convert, and how much must be converted manually. In any case, this guide is intended to be used to both visualize the scope of a porting effort and to aid in the porting effort by addressing the technical issues. This document will be refined based on users experiences to identify as many of the porting issues as possible at the beginning of a project.

Product overview IBM Informix Server provides high performance and scalability with legendary reliability and nearly hands-free administration of databases of all size. IDS is industry proven on UNIX, Linux, or Windows platforms with online transaction processing (OLTP) systems, data marts, data warehouses, and e-business applications. The IDS 11 release features significant additions over prior versions. It supports the services-oriented architecture (SOA) model for application integration and offers many new features for data replication, continuous availability and hands free database administration.

Organization This document is broken into sections to logically discuss the different database concepts. Some of the sections may contain the same sub-sections; for example, stored procedures and triggers


Version 1.6 9

are discussed in the DDL and DML sections. This allows separate discussions on the issues facing the same item in each area. For example, the issues surrounding creating a stored procedure are discussed in the DDL section, and the issues surrounding the stored procedure language are discussed in the DML section. Among the other references, the Planning Guide appendix contains a quick reference of most of the differences between Oracle and Informix along with the degree of difficulty to port each difference. This reference is intended for use in the planning process to illustrate the scope and the effort required to perform the porting project. Some of the stored procedure logic used to convert Oracle functions is included in the appendix Sample code.

Conventions The conventions used in this document include:

Courier Text Distinguishes a logic example

from regular text.

Example Illustrates a point. In most cases an Oracle example will be followed by an Informix example.

Italicized Text Signifies a substitution; in other words, substitutes for the italicized word, the actual object the word is describing, for example: table_name, column_name, and so on.

UPPER CASE TEXT Signifies database vendor reserved words or statements such as INTEGER, CREATE TABLE, and so on

Bold example text highlights the item that is being explained.


Version 1.6 10


Version 1.6 11

C H A P T E R 2 : Defining the Problem Space

It is important to define the set of objects to be migrated, and it is better if effort is put into this prior to beginning the actual migration. This is true if you are the responsible for both the database in general and its migration from one supporting DBMS to another, but it is particularly true that there be a clear agreement on the scope of what is to be migrated if the migration is to be performed by a party other than the one with long term responsibility for the database. Defining the scope will involve extracting a representation of the objects to be migrated out of the Oracle system catalogs and representing them in some format that can be manipulated into constructs that can be used in Informix.

Extracting the objects to be migrated It is possible to represent the objects in more than one language. Using the SQL language is the most common method, and it will be the only one discussed at length in this document (in its current revision). However, it is also possible to express database objects in XML, SQL has the advantage that the standard, common grammars are widely understood in the context of defining tables, indexes, etc. XML would have an advantage of not requiring parsing that is sensitive to the minor differences in ways of expressing essentially the same object.

Working With Oracle Dump Files

There exist 3rd

-party tools for reading system catalogs, but it is doubtful that any can read the Oracle catalogs more reliably than Oracles own tools. There are two, incompatible, export and import tool sets used by Oracle. The older tools are imp and exp and the newer ones are impdp and expdp, where '..dp' stands for Data Pump. Oracle has encouraged the use of the newer tools instead of the older ones since the newer ones were introduced at version 10. Nonetheless, there are many Oracle users still using imp and exp. In the discussions below, only the metadata will be extracted into a dump file. That is because any data in the dump file will be in a proprietary format, and very likely some of the data will have to go through a type conversion process before being loaded into an Informix system. Oracle exported data generally cannot be used to load a database in Informix. Export and Import

If someone has given you a dump file created with the older export tool, there exist tools such as The DDL Wizard, by Net 2000 Limited, which can be used to extract viable DDL. The contents of the dump file contain the SQL for re-creating the database, but they are not in a readily usable format. The older export and import tools are also more sensitive to the layout of the tablespaces than impdb. The ability to extract DDL from the dump file in a usable form, segmented by whatever grouping you choose, is limited compared to what can be achieved through the Data Pump versions..


Version 1.6 12

It may be tempting to feed the dump file into the IBM Migration Toolkit (MTK) or other tool that works on SQL flat files. This will not work. MTK works on flat text SQL files, and the dump file is binary. If you open it up, you can see what may be a large number of SQL statements, but there are also binary codes within the same file. That binary data will prevent MTK from being able to process it. Getting SQL statements

If you want to get the SQL statements out of the dump file, as they would be executed on the server, there is an option available from the import tool itself, 'show=y'.

imp 'myID/myPWD as sysdba' file=myFile.dmp

full=yes show=y > dmp_show.txt

This will produce a file which contains the statements, but they are wrapped in quotes. The contents will look something like:

"ALTER SESSION SET CURRENT_SCHEMA= "SYSTEM"" "CREATE UNDO TABLESPACE "TBSPC1" BLOCKSIZE 8192 DATAFILE 'D:\ORACLE\ORADA" "TA\SCHEMA1\CHUNK.DBF' SIZE 387973120 AUTOEXTEND ON NEXT 5242880 MAXS" "IZE 32767M EXTENT MANAGEMENT LOCAL "

which makes them strings instead of SQL statements. Fixing this is a two-step process

-- removes quotes from the start of lines

sed 's/^ "//g' dmp_show.txt > step1.txt

-- removes quotes from the end of lines

sed 's/"$//g' step1.txt > dmp_step2.sql

The statements are still not correctly formatted because they have been truncated to a fixed length and line-endings inserted. However, at this point it is possible to get a count of how many of each object type there is using the script in the appendix Getting an initial count of database objects.

Data Pump Export and Import

These newer tools provide better performance and more capabilities than their predecessors. Please refer to documentation on Oracle for a complete description; searches for Data Pump Import and Data Pump Export should return relevant results quickly. Below is enough information to get started on defining and extracting the objects to be migrated. Metadata can be filtered through the use of the export mode clause, and INCLUDE and EXCLUDE parameters. However, any dependent object of an included or excluded object is likewise included or excluded. For example, if you include an index, then the table associated with the index will also be included, and if you exclude a table, then any associated indexes will also be excluded. The SQL that will generate all the objects in the dump file can be created by the impdp command with the SQLFILE parameter. If the output file is very large, you might want to break it into smaller pieces. There are a couple of ways to do this, and the one that is best for you somewhat depends


Version 1.6 13

on how you intend to proceed with the conversion. Data definition language (DDL) SQL for all the objects can be put into one file, or the INCLUDE or EXCLUDE parameters can be added to direct Data Pump to filter on the types of objects. If you put all the objects into one file, then you can break that into smaller files by object type fairly easily because the objects are sorted by type in the SQL file. So, it is just a matter of cutting the file into smaller pieces. This method may be preferred because it allows for you to do things like, create all tables, load the data, and then create the indexes and triggers. If the data set is large, creating the indexes after loading the data can yield substantial performance improvements. However, this is less useful if you want to convert sets of objects according to dependencies; in which case the filtering option is likely to be more useful. Just to illustrate a difference between these two methods, in one customer case, the metadata dump file was about 18MB, and putting all objects in one SQL file resulted in a file that was about 15MB. The table definitions occupied a little under 300KB of the 15MB. The output file generated by filtering on objects of type TABLE was just over 1MB. The addition content was mostly GRANT, INDEX, and TRIGGER creation statements. There were no differences in the CREATE TABLE statements themselves. Examples

Prerequisite The Data Pump tools require the use of an Oracle DIRECTORY object. This is basically a mapping between a name that exists within the DBMS and a system path. It can be a tripping point, but it provides an abstraction layer that, for instance, allows the same commands to work across systems with different disk layouts or different operating systems. Creating a DIRECTORY on a Windows system from SQLPlus:

SQL>connect / as sysdba;

SQL>CREATE OR REPLACE DIRECTORY dumpDir AS 'c:\temp';

Note: Make sure this directory is not read-only. There also could be problems if the directory is a network drive on Windows; these can be related to there being different users between the Oracle executable and the current user, and those users having different permissions on the network drive.

SQL>GRANT read, write ON DIRECTORY dumpDir TO userID;

Creating a dump file of the entire database:

expdp 'userName/userPwd as sysdba' FULL=Y dumpfile=DB_full.dmp

LOGFILE=LG_expdp.log CONTENT=METADATA_ONLY DIRECTORY=dumpDir

Creating a dump file of just one schema:

expdp 'userName/userPwd as sysdba' SCHEMAS=hr DIRECTORY=dumpDir

DUMPFILE=hr .dmp LOGFILE=hr .log CONTENT=METADATA_ONLY

Creating a dump of just the tables and their dependents:

expdp 'userName/userPwd as sysdba' SCHEMAS=hr INCLUDE=TABLE

DIRECTORY=dumpDir DUMPFILE=hr.dmp LOGFILE=hr.log

CONTENT=METADATA_ONLY

Creating a dump of just one table:

expdp 'userName/userPwd as sysdba' SCHEMAS=hr

INCLUDE=TABLE:\"LIKE \'COUNTRIES\'\" DIRECTORY=dumpDir

DUMPFILE=hr.dmp LOGFILE=hr.log CONTENT=METADATA_ONLY


Version 1.6 14

Creatinge an SQL file from a dump file:

impdp 'userName/userPwd as sysdba' DIRECTORY=dumpDir

DUMPFILE=hr.dmp SQLFILE=dumpDir:hr.sql

The INCLUDE and EXCLUDE options are also valid when used with impdb; so, it may be easier to get a complete dump of everything to be migrated, then use these options to create subsets of objects it smaller SQL files, than it would be to create separate dump files. It is easier to divide objects than to merge them together if they are not divided initially as wanted. There is a caveat when using this impdp to generate an SQL file; the object names will all be delimited identifiers. Example:

CREATE TABLE "HR"."COUNTRIES"... Because of differences between how Informix handles these and how Oracle handles these, case-sensitivity issues could occur. See the chapter on Delimited Identifiers, and, in particular, the description of default shift problems. If it can be determined that there are no name collisions if regular identifiers are used, removing the quotation marks as part of the conversion might avoid many problems. In other words, if there are no objects whose names only differ in case, like foo and FOO, then changing every occurrence of FOO to FOO in the DDL could eliminate case-sensitivity issues in the application DML. It depends on if the application code uses the delimited form of the name predominantly or not.


Version 1.6 15

C H A P T E R 3 : Data Definition Language

Identifiers An identifier specifies the simple name of a database object such as a table name, column name, index name, view name, stored procedure name, and so on. The maximum length of an Oracle identifier is 30 characters and can contain letters, numbers, _, $, and #, although Oracle highly recommends that $ and # should not be used. In contrast, Informix identifiers have a maximum length of 128 characters and may contain letters, numbers, _ and $ (as long as $ is not the first character). See the Delimited Identifiers section below for information. This means that all Oracle identifiers containing a # anywhere in the identifier or a $ as the first character must be replaced or modified to remove those characters from the identifier.

Delimited identifiers

Delimited identifiers are also known as quoted identifiers and sometimes as escaped identifiers. They have been part of the SQL standard since SQL/92, but existed in various database management systems (DBMS) prior to that time. In a nutshell, they are a way to preserve case sensitivity in object names as well as to allow objects to have names outside of the conventions of SQL regular identifiers. Prior to the behavior of identifiers in general being standardized, different DBMS vendors implemented different means of achieving case-insensitivity for object names; some converted all regular identifiers to uppercase, and some converted regular identifiers to lowercase. By SQL/99 the concept of case normal form was standardized to mean, simply stated, that if there exists an uppercase equivalent of any character in a name, then the uppercase version is stored in the system catalogs and used for comparison purposes. See the SQL/99 standard, chapter 5, section 2, and in particular, items 21 and 22, for a formal description of case normal form and how it applies to identifier comparisons. Delimited identifiers can be used to specify names for database objects that are otherwise identical to SQL reserved keywords, such as TABLE, WHERE, DECLARE, and so on. The only database object for which delimited identifiers cannot be used is a database name. Database administrators and application programmers do not always communicate to each other with 100% efficiency, and there is no guarantee that within either of these pools, every member codes by the standard practice of the other members. After describing how delimited identifiers work in Informix, there will be a description of how any inconsistency of usage and the differences between Oracle and Informix can introduce some migration hurdles. DELIMIDENT Environment Variable

To use delimited identifiers with Informix, you must set the DELIMIDENT environment variable. While DELIMIDENT is set , strings enclosed in quotation marks ( ) are treated as identifiers of database objects, and strings enclosed in apostrophes ( ) are treated as literal strings. If the


Version 1.6 16

DELIMIDENT environment variable is not set, strings enclosed in quotation marks are also treated as literal strings. When you set the DELIMIDENT environment variable, you cannot use quotation marks ( ) to delimit literal strings. If DELIMIDENT is set, the database server interprets all strings enclosed in quotation marks as SQL identifiers, not string literals. Commonly within Informix systems, DELIMIDENT is set or not on the client side, according to the design of the application. However, if you are converting a database and all applications accessing it from a system where every occurrence of quotation marks (objectName) indicates an identifier and not a string literal, you may want to consider setting it in the server environment in order to avoid any inconsistency between clients where it is set and where it might not be. Using Quotes in Strings The apostrophe ( ) has no special significance in string literals delimited by quotation marks. Conversely, double quote ( ) has no special significance in strings delimited by apostrophes. For example, these strings are valid: "Nancys puppy jumped the fence" Billy told his kitten, "No!" A string delimited by quotation marks can include a double quote character by preceding it with another double quote, as the following string shows: "Enter ""y"" to select this row." When the DELIMIDENT environment variable is set, quotation marks can only delimit identifiers, not strings. Use of Uppercase Characters You can specify the name of a database object with uppercase characters, but the Informix server shifts these to lowercase characters unless the DELIMIDENT environment variable is set and the name of the database object is enclosed in quotation marks. In this case, the database server treats the name of the database object as a delimited identifier and preserves the uppercase characters in the name. Delimited Identifiers By default, the character set of a valid SQL identifier is restricted to letters, digits, underscore, and dollar-sign symbols. If you set the DELIMIDENT environment variable, however, SQL identifiers can also include additional characters from the codeset implied by the setting of the DB_LOCALE environment variable. See the Identifier section of the Informix Guide to SQL: Syntax for more information. Storage Object Names In Informix, delimited identifiers can be used to specify non-alphanumeric characters in the names of database objects. However, delimited identifiers can not be used to specify non-alpha characters in the names of storage objects such as dbspaces and blobspaces. To use delimited identifiers, DELIMIDENT must be set both at compile and run times. For example, to set DELIMIDENT environment variable with sh or ksh, issue the following at the command line prompt:

export DELIMIDENT=

Note: You do not need to assign a value to the environment variable, and counter-intuitively, setting DELIMIDENT=n has the same effect as DELIMIDENT=y. Also, in a Windows environment:

set DELIMIDENT=

effectively undefines the variable. Default shift problems

Any direct access of system catalog information involving names will cause problems when migrating from a system, like Oracle, where system catalog names are stored in uppercase to a system, like Informix, where the catalog names are stored in lowercase. For example:

CREATE TABLE foo (c1 int);


Version 1.6 17

Within Oracle, the following will return information about the table:

select * from sys.all_objects where object_name = 'FOO';

and the following will not:

select * from sys.all_objects where object_name = 'foo';

Conversely, in Informix:

select * from systables where tabname = 'foo';

will be successful, and the same with 'FOO' will not be. A similar, if not more common, problem can occur when the table has been created without the name being delimited, but is sometimes delimited when accessed by the application. Per the standard, foo == FOO == FOO, but in Informix, foo == FOO == foo. In Oracle, the following SELECT statement will be successful:

SELECT * FROM FOO;

but within Informix, this will result in an error, 206: The specified table (FOO) is not in the database. Likewise, if the name is delimited in its definition, such as

CREATE TABLE "SCHEMA1"."TABLE1"...

this creates a table that can be referenced in Oracle without the name being delimited. The statements

SELECT * FROM schema1.table1;

and SELECT * FROM SCHEMA1.TABLE1;

will be successful in the Oracle system, but will fail in the Informix one. In theory, whether on object name is delimited or not should be the same in the database and at every occurrence within the application, but this is not always the case. It may be beneficial to examine whether delimited identifiers or regular identifiers are most commonly used in application code, and use whichever is most common as a naming convention when translating the DDL.

Explicit versus implicit schema/owner names

Another complication to keep in mind is that when the log mode is ANSI, implicit and explicit owner names are treated differently between the Oracle and Informix servers. In Oracle, there is no difference in the case handling of an implicit owner name and an explicit one. For example, if connected to Oracle as scott the following CREATE TABLE statements

create table foo1(c1 int); create table scott.foo2(c1 int); create table SCOTT.foo3(c1 int);

all result in tables owned by SCOTT. The following select statements, in various forms that may be in application code, will all run without error.

select * from foo1; select * from scott.foo1;


Version 1.6 18

select * from SCOTT.foo1; select * from foo2; select * from scott.foo2; select * from SCOTT.foo2; select * from foo3; select * from scott.foo3; select * from SCOTT.foo3;

These statements will also run without error within a non-ANSI mode Informix database, but not all of them will run successfully within an ANSI mode database. This is because Informix does not uniformly fold the case of owner names, and handles implicit names differently from explicit names; so, there will always be some combination of DDL and DML usage patterns that work within an Oracle system that do not work in an Informix one. You can set ANSIOWNER before starting your Informix server, but that will merely change which combinations do not work. You may want to examine usage patterns within the applications and choose a naming convention when translating the DDL that matches the most common naming convention used in the applications. Note: This behavior of Informix forces a tradeoff between using an ANSI mode database, which most closely matches the transaction behavior of Oracle, and a non-ANSI mode database, which has the least mismatch in identifier case sensitivity.

Reserved words or keywords

Oracle and Informix both allow identifiers to be reserved words as long as they are delimited. However, Oracle and Informix reserved words differ. In addition, both systems have keywords, like FROM, that are not always reserved in the sense that using them as an identifier will always generate a syntax error. There should be few problems with reserved words or keywords if identifiers that are delimited in the original database remain delimited in the destination database. The appendix Keywords of SQL for IBM Informix in the Guide to SQL: Syntax contains more information about Informix keywords. Also, one word, non-delimited identifiers should be verified against the Informix reserved words list to ensure that they do not need to be delimited or renamed. Although almost any word can be used as an identifier in Informix, syntactic ambiguities can result from using reserved words as identifiers in SQL statements. Delimited identifiers provide a way to use a reserved word as an identifier without causing syntactic ambiguities. However, doing this changes a case-insensitive name into a case-sensitive one, and that means that every reference to the object has to be checked for issues related to case-sensitivity. Essentially, this is not much less work than changing the name of the object because, in essence, it is changing the name of the object. Examples

The following example shows how to create an Informix table with a case sensitive table name:

CREATE TABLE "My_Customers" ()

The following example shows how to create a table whose name includes a space character. If the table name were not in quotation marks ("), a space character or any other non-alpha character, except an underscore ( _ ) or dollar sign ($) (see special conditions above), could be used in the name.

CREATE TABLE "My Customers" ()


Version 1.6 19

The following example shows how to create a table that uses a keyword as the table name:

CREATE TABLE "TABLE" ()

To include a double-quote (") within a delimited identifier, the double-quote (") must be preceded with another double-quote ("), as shown in the following example:

CREATE TABLE "My""Good""Data" ()

Summary

The main points to keep in mind when deciding about any questions on how identifiers should be translated are:

Oracle always has delimited identifiers enabled, and Informix does not.

Oracle folds regular identifiers to uppercase, and Informix folds to lowercase.

Informix has behavioral differences between an ANSI mode database and a non-ANSI mode one.

It is beneficial to consider the most common usage patterns within the existing application code prior to deciding default identifier translation patterns.

Databases

Databases, database names and instances

Oracle and Informix implement databases and instances differently. Oracle considers a database to be a set of data files, control file(s) and log files, while an instance is a set of background processes and memory structures accessing database data. Oracle instances are also known as servers. Each Oracle instance or server runs against one database, but through the use of Oracle Parallel Server, a database may have multiple instances accessing it. An Oracle database is named at initialization and the name has a limit of 8 ASCII characters. Informix databases are defined as a collection of information contained in tables that are useful to a particular organization or used for a specific purpose. Informix database names may be up to 128 characters in length. An Informix instance is a set of processes, memory and disk allocations that manage data and will contain at least two and in most cases many databases. Informix instances are also referred to as servers. Informix databases may share disk allocations (dbspaces) with other databases within an Informix instance. Oracle databases cannot share disk allocations (tablespaces). Informix databases should be created in a dbspace other than the root dbspace. The root dbspace holds data for the system, configuration information for the engine, and so on. If user-defined objects are created in this dbspace, then the dbspace may become unmanageably large, and during backup, the system information may also get backed up unnecessarily. The CREATE DATABASE statements of Informix and Oracle have differences which may require modification to routines responsible for database creation. Informix will accept the same minimal syntax required by Oracle (e.g. CREATE DATABASE myDB) however issuing the command will implicitly accept the creation of a database without transaction logging enabled and establish the default location for all database objects as the instances default storage location. The instances default storage location, or root dbspace, should not contain user-defined objects. The root dbspace holds data for the system and some configuration information for the engine. If user-


Version 1.6 20

defined objects are created in this dbspace it may become unmanageable and result in the system contending with user objects for the available space.

ANSI vs. non-ANSI

Informix supports both ANSI and non-ANSI databases. Informix non-ANSI databases are most common, but there are some advantages of ANSI databases when porting from Oracle:

Oracles transaction behavior is more or less like that of an ANSI database. Applications ported on Oracle are always in a transaction. In Oracle and ANSI databases, transactions begin implicitly with the first of a series of SQL statements and will end immediately after a commit or rollback statement. Therefore, unlike a non-ANSI database, a COMMIT WORK statement does not need to be preceded with a BEGIN WORK statement.

In ANSI databases, database object references must be prefixed by the owners name, unless the owner is the one referencing the object. If Oracle applications reference database objects with a both parts of the object name, prefixing the object name with schema, using an ANSI database may ease modifications necessary when porting to Informix.

The grant to PUBLIC concept provide by Informix database security does not apply to ANSI databases. Every database object is private and privileges must be explicitly granted to each user.

If an Informix ESQL/C or 4GL application was developed to run on a non-ANSI Informix database (including BEGIN WORK statements), the application could run on an ANSI Informix database in one of two ways:

By placing the BEGIN WORK statement in a pre-processor directive, such as IFDEF object_name, and omitting the proper preprocessor compile options, such as -D object_name

By compiling the application normally and ignoring the resulting warning messages

Additionally, the LOG MODE ANSI clause must be added to the CREATE DATABASE statements. ANSI mode databases cannot have buffered logging. Applications written to use an open API, like ODBC or JDBC, are compiled without awareness of the database and these APIs are written with the intent to abstract specific database behavior. For instance, in one of these, the application developer would call a function to begin or end a transaction rather than execute a BEGIN and COMMIT or ROLLBACK. The API would execute these statements internally, or not, as necessary for the database connection. See the Transaction Processing section in Application Architecture for more information on how an application running on a non-ANSI Informix database can simulate Oracle transaction behavior.

Tablespaces and dbspaces Oracle tablespace names need to be replaced with Informix dbspace names. Unlike the Oracle tablespace, the Informix dbspace cannot be created using DDL (SQL) scripts. It must be created using the Informix onspaces utility before any DDL (SQL) scripts are executed. Therefore, Oracles CREATE TABLESPACE statements should be removed from the DDL (SQL) scripts. The user interface for accomplishing these tasks is onmonitor. The command line utility is onspaces. Therefore, the onspaces commands can be placed in shell or batch scripts. After successfully executing the onspaces commands, the DDL (SQL) scripts may be called through the same shell or batch scripts. For example:


Version 1.6 21

onspaces onspaces dbaccess database_name DDL_script_file_name dbaccess database_name DDL_script_file_name

Tables

Attributes and general syntax

When creating tables, the Oracle CREATE TABLE statement must be converted to Informix, taking advantage of the Informix options IN, EXTENT, NEXT, and LOCK MODE.

IN specifies the dbspace in which the table will reside.

EXTENT specifies the amount of space that will initially be allocated to the table (16K default on most platforms).

NEXT specifies the amount of space that will be allocated when additional space is needed (16K default on most platforms.

Lock mode

LOCK MODE specifies whether to use row or page locks for the table. In Oracle, the default is row level locking; in Informix the default setting is page level locking. However it can be changed by using one of the following methods: (resolved in the following order of precedence)

1. LOCK MODE specified using an attribute of the CREATE TABLE or ALTER TABLE command syntax

2. IFX_DEF_TABLE_LOCKMODE environment variable setting 3. DEF_TABLE_LOCKMODE parameter setting in the ONCONFIG file

NOTE: If the DEF_TABLE_LOCKMODE parameter cannot be found in the ONCONFIG file it can be added to make the specification for every database within the instance. The Informix instance must be restarted for this parameter to take effect. The new default LOCK MODE will apply to all tables created after the parameter has been changed. To change the LOCK MODE of existing objects use the ALTER TABLE statement.

Storage

The Oracle STORAGE INITIAL and STORAGE NEXT clauses must be changed to the Informix EXTENT SIZE and NEXT SIZE clauses, respectively. In Oracle the STORAGE clause options MINEXTENTS, MAXEXTENTS and PCTINCREASE should be removed. For example: Oracle:

CREATE TABLE dept(

deptno NUMBER(2),

dname VARCHAR2(14),

loc VARCHAR2(13)

)

STORAGE (INITIAL 100K NEXT 50K MINEXTENTS 1 MAXEXTENTS 50

PCTINCREASE 5);

Informix: CREATE TABLE dept (

deptno SMALLINT,

dname VARCHAR(14),

loc VARCHAR(13)

);


Version 1.6 22

EXTENT SIZE 200 NEXT SIZE 50;

When an Oracle CREATE TABLE statement does not include a STORAGE clause, the table will be created using the tablespace STORAGE clause by default. If an Oracle tablespace is created specifying a STORAGE INITIAL of 100KB and a STORAGE NEXT of 50KB, then all tables created within that tablespace will have a default value of STORAGE INITIAL 100KB and STORAGE NEXT 50KB. Oracle tables cannot be created with smaller STORAGE clause values than the tablespace default they are created in. Informix dbspaces do not have storage clauses attached to them. As stated earlier, the default Informix EXTENT and NEXT sizes are 16KB on most platforms. The minimum EXTENT and NEXT sizes are 4 times the page size.

Constraints

The Oracle constraint syntax must be changed to the Informix syntax for primary keys, foreign keys, unique, and so on. For example:

Oracle: CONSTRAINT PK_NUMBER PRIMARY KEY(CUST_NUM)

CONSTRAINT CK_EMP_CODE CHECK (EMP_CODE > 100)

Informix: PRIMARY KEY(CUST_NUM) CONSTRAINT PK_NUMBER

CHECK (EMP_CODE > 100) CONSTRAINT CK_EMP_CODE

An Oracle check constraint statement may contain functions that are not available in Informix. In this circumstance it may be necessary to code the combination of a trigger and a stored procedure to emulate the same functionality. A trigger based on an insert or update event can execute a stored procedure which tests the constraint condition and if necessary raise an exception to reject the row data which violates the constraint. The Oracle PARALLEL clause, which specifies parallel execution of an operation, must be removed from any SQL statements (such as CREATE TABLE and ALTER TABLE). In Informix there are ways to accomplish this parallel execution depending on the context in which these SQL statements are called (shell script file, batch file, and so on.).

ALTER TABLE

Informix offers a rich set of ALTER TABLE features: adding and dropping columns (rename by using the RENAME statement), changing column data types, altering the next size, and changing the lock mode. Informix will choose one of three algorithms when executing an ALTER TABLE statement depending upon the operation to be performed. For certain conditions, the database server uses either a slow, in-place" or fast alter algorithm to modify the table. Informix provides in-place alter table support for adding or dropping a column anywhere in the table, changing the column length, and changing the column data type without an exclusive lock on the table. An in-place alter will modify the tables definition without changing the existing rows or unloading and reloading the data. After the ALTER TABLE operation, the database server inserts rows using the latest definition. Informix will not change the row structure until a data row is touched by a user operation. Once a query accesses a row that is not yet converted, there can be a slight degradation in the performance because the database server reformats each row in memory before it is returned. Informix uses the slow alter algorithm when the ALTER TABLE statement makes column changes that it cannot perform in place. This type of alter would be:

Adding or drop a column created with the ROWIDS keyword

Dropping a column of the TEXT or BYTE data type


Version 1.6 23

Converting an INT or a SMALLINT column to SERIAL or SERIAL8

Modifying the data type of a column so that some possible values of the old data type cannot be converted to the new data type

For example, if you modify a column of data type INTEGER to CHAR(n), the database server uses the slow ALTER algorithm if the value of n is less than 11. An INTEGER requires 10 characters plus one for the minus sign for the lowest possible negative values.

Modifying the data type of a fragmentation column in a way that value conversion might cause rows to move to another fragment

Adding, dropping or modifying any column when the table contains user-defined data types or smart large objects

When the database server uses the slow alter algorithm to process an ALTER TABLE statement, the table can be unavailable to other users for a long period of time because the database server will lock the table exclusively for the duration of the operation, make a copy of the table to convert the table to the new definition and convert the data rows. This type of ALTER TABLE processing can encounter the scenario of a statement being a long transaction and abort it if the Long Transaction High Water Mark (LTXHWM) threshold is exceeded. Informix will use the fast alter algorithm when the ALTER TABLE statement changes attributes of the table but does not affect the data. The database server uses the fast alter algorithm when you use the ALTER TABLE statement to make the following changes:

Change the next-extent size

Add or drop a constraint

Change the lock mode of the table

Change the unique index attribute without modifying the column type

With the fast alter algorithm, the database server holds a lock on the table for a very brief period. In some cases, the database server will lock the system catalog tables but only long enough to change the attribute. In either case, the table is unavailable for queries for only a short time.

Data Partitioning

Informix Table Fragmentation is the counterpart to Oracles Table Partitioning and allows the user to control where data is physically placed at the table level. Table Fragmentation or Data Partitioning is typically done to large tables, but Informix and Oracle implement fragmentation and partitioning for different reasons and with different results. Informix recommends using table fragmentation to improve single-user response time, concurrency, data availability, backup / restore characteristics, and data-load performance. While Oracle does state that table partitioning may improve the performance of queries, and that the Oracle optimizer takes partitioning into account, the primary goal of partitioning in Oracle is improving database maintenance. Partitioning strategies in Oracle include range partitioning as well as hash and composite partitioning. Composite partitioning combines range and hash partitions through the use of sub-partitions. Tables incorporating Oracle LOBs (large objects) cannot be partitioned. Informix fragmentation strategies include expression-based and round robin. Basic expression-based fragmentation can replace Oracle range partitioning. Unlike Oracle LOBs, Informixs Smart Large Objects can be fragmented. Examples of creating tables with Oracle range partitioning and Informix fragmentation by expression are shown below: Oracle range partitioning:

CREATE TABLE dept


Version 1.6 24

(

deptno NUMBER(2),

dname VARCHAR2(14),

loc VARCHAR2(13) )

partition by range (deptno)

(partition PART1 values less than (11)

tablespace PART1_TS,

partition PART2 values less than (21)


partition PART3 values less than (31)


partition PART4 values less than (MAXVALUE)

tablespace PART4_TS);

Informix expression based fragmentation: CREATE TABLE dept(

deptno SMALLINT,

dname VARCHAR(14),

loc VARCHAR(13)

)

FRAGMENT BY EXPRESSION

deptno < 11 IN dbspace1,

deptno >= 11 AND deptno < 21 IN dbspace2,

deptno >= 21 AND deptno < 31 IN dbspace3,

REMAINDER IN dbspace4;

Oracle uses MAXVALUE for values not found in the specified range while Informix uses the REMAINDER keyword for values that fall outside the specified expression or expressions. Prior to IDS version 10.00, each table fragment had to go into a separate dbspace. Now tables can be fragmented within a single dbspace. You can create partitions within a dbspace that can each support a table fragment. It is better to have one chunk per disk drive, and now it is not necessary to create a dbspace just to facilitate fragmentation. This feature can simplify the management of dbspaces. The benefits gained through this new development include:

It reduces the total number of dbspaces needed for a fragmented table.

Storing multiple table fragments in a single dbspace improves query performance over storing each fragmented expression in a different dbspace.

For example, Informix partition fragmention in a single dbspace:

CREATE TABLE dept(

deptno SMALLINT,

dname VARCHAR(14),

loc VARCHAR(13)

)

FRAGMENT BY EXPRESSION

PARTITION part1 (deptno < 11) IN dbspace1,



PARTITION part4 REMAINDER IN dbspace1;

Partitions of an Informix fragmented table can be manipulated using the ALTER FRAGMENT statement which supports attaching, detaching, adding, modifying, and dropping, as well as initializing the distribution strategy.


Version 1.6 25

For example, the following SQL removes a partition fragment and places the contents into a new table:

ALTER FRAGMENT ON TABLE dept DETACH PARTITION part3 dept_part3;

Making use of ALTER FRAGMENT to detach fragments can be an effective way of deleting large quantities of rows from a table, quickly and easily. After the above statement completes, the table will no longer contain rows with a deptno greater than 21 and less than 31. Refer to the Informix Guide to SQL: Syntax for a complete description on how to use the ALTER FRAGMENT statement to change the distribution strategy or the storage location of an existing table or index.

Data types

Numeric

Oracles NUMBER data type needs to be replaced with one of the following Informix equivalent data types, depending on the size of the column. The Informix numeric data types are listed below.

SMALLINT (-32,767 to 32,767)

INTEGER (-2,147,483,647 to 2,147,483,647)

BIGINT (-9,223,372,036,854,775,807 to 9,223,372,036,854,775,807)

INT8 (-9,223,372,036,854,775,807 to 9,223,372,036,854,775,807)

The BIGINT type is more efficient in terms of space and speed; there are few reasons to use INT8 now that BIGINT is available.

DECIMAL (floating point up to 32 significant digits -10-130

to 10124

)

In an ANSI database, there is an implied scale of 0 when no scale is given; so, this is not strictly speaking a floating point type within an ANSI database.

NUMERIC (floating point up to 32 significant digits -10-130

to 10124

)

FLOAT (double precision, like double data type of C)

SMALLFLOAT (single precision, like float data type of C)

REAL (same as SMALLFLOAT)

DOUBLE (same as FLOAT)

LONG (same as long data type of C)

Oracles NUMBER data type is used to store zero, positive and negative fixed size, and floating point numbers with magnitudes between 1.0 x 10

-130 and 9.9...9 x 10

125 (38 9s followed by 88 0s)

with 38 digits of precision. A fixed-point number is specified by NUMBER(p, s) where p is the precision, or the total number of digits, and s is the scale, or the number of digits to the right of the decimal point. For example, a column defined as NUMBER(10,4) would contain numbers in the format 999999.9999. In Oracle, the scale can range from -84 to 127. If the scale is 0, or not mentioned, then the data type can be converted into Informixs SMALLINT, INTEGER, or BIGINT depending on the precision, or FLOAT, SMALLFLOAT, DOUBLE or REAL, depending on usage in the application. When the scale is positive, the data type should be converted to Informixs DECIMAL or NUMERIC. A floating-point data type in Oracle is declared using the type NUMBER without mentioning scale and precision. In Informix this can be replaced with FLOAT, SMALLFLOAT, REAL, DOUBLE PRECISION, or DECIMAL(p) in an non-ANSI database.


Version 1.6 26

Oracle allows a negative scale. If the scale is negative, the actual data is rounded to the specified number of places to the left of the decimal point. For example, a specification of NUMBER (10, -2) means to round to the hundred. If the general form for any number is:

mantissa X 10exponent

then precision is the number of digits in the mantissa, and scale is the negative exponent. Example:

select cast( '987654321' AS NUMBER(10,-2) ) from dual;

returns

987654300

Informix does not support a negative scale. If precision - scale is less than the maximum precision of an integer type, then that is the most efficient type to use. Failing that, and if the database is non-ANSI, a floating point DECIMAL can be used. If that is not sufficient, then it may be necessary to define a user type and associated functions. Oracle also allows the scale to be greater than the precision. Precision is just the number of digits that will be preserved. A NUMBER(3, 5) might have the value 0.00123. If the Oracle scale is less than the Informix maximum precision, then the Oracle scale can be used for both the Informix precision and scale. A NUMERIC(5,5) column could also store the value 0.00123. You may need to take into consideration not only the minimum and maximum values but the default size for data types. For example, when the size of the NUMBER data type is absent, Oracle will default to NUMBER(38), while Informix defaults to NUMERIC(16). Oracle and Informix support the ANSI DECIMAL data type. Therefore, in the case of an ANSI data type, the Oracle data type can be converted to the same Informix data type. There are differences between conversions based on theory versus those based on practice. For instance, it is very common to see an undecorated NUMBER declaration where the customer database and applications are using integer data. When converting NUMBER declarations, it may be necessary to consider how the data is being used in order to determine the best type mapping.

CHAR, VARCHAR and LVARCHAR

In Oracle, the default for a CHAR column is one character, and the maximum allowed is 255 characters. In Informix, the maximum length of CHAR and LVARCHAR columns is 32,767. Therefore, Oracles CHAR columns can always be converted to an Informix CHAR column. The CHAR data type columns can only contain printable characters, tabs, and spaces. The CHAR columns store leading and trailing spaces. In Oracle, a zero-length string can be inserted into a CHAR column, but the column is padded with one blank character when it is used in comparisons. Also, in Informix, a zero-length string can be inserted into a CHAR column; however, the column is padded with enough spaces to fill the column. In the case of inserting NULL into an Informix CHAR column, no padding occurs. Oracles VARCHAR and VARCHAR2 are currently synonymous and have a maximum data length of 4,000 bytes while the maximum length for the Informix VARCHAR data type is 255. Informixs CHAR and LVARCHAR data types have a maximum length of 32,767 and 32,739, respectively, measured in bytes. These should be used to replace Oracles VARCHAR, VARCHAR2, LONG and LONG VARCHAR if the data length is between 256 and the maximum. If the data length exceeds the maximum, use Informixs TEXT, BYTE, BLOB or CLOB data types. See the Raw Data section below for more information on TEXT, BYTE, BLOB and CLOB data types.


Version 1.6 27

Empty Oracle VARCHAR2 strings are considered NULL. Empty Informix VARCHAR and LVARCHAR strings are not considered NULL; rather, they contain at least one space. Oracle

compares VARCHAR2 values using non-padded comparison semantics. Therefore, BOB BOB . Informix ignores trailing blanks. Therefore, BOB = BOB or = . Hence, checks for NULL within the application must be replaced with checks for an empty string (such as or ) whenever an empty string is inserted into the column. If NULL is truly inserted into the column, checking for NULL is appropriate (for example, SELECT * FROM WHERE IS NULL). In Oracle, LONG columns store variable length character strings containing up to 2 gigabytes, or 2

31-1 bytes. Informix LONG columns store numeric data. Oracles LONG columns have many of

the characteristics of VARCHAR2 columns. They can be used in a SELECT list, in the SET clause of an UPDATE statement, and in an INSERT statement, but they cannot be used in a WHERE clause, a GROUP BY clause, or an ORDER BY clause, and they cannot be indexed. Oracles LONG columns should be converted to an Informix Smart Large Object or SLOB (BLOB, CLOB) column.

Date and Time

Oracles DATE data type contains date and time components, from year down to second. It can be to be replaced most directly with Informixs DATETIME YEAR TO SECOND. Some analysis may be necessary to determine whether the time is really necessary. In other words, does the application reference the date and time portions of the values? If the application only references the date portion, then replace Oracles DATE with Informixs DATE and change the host variable to X(10) or char(10), accordingly. The Informix DATE default display format is MM-DD-YYYY, although the DATE data type stores the calendar date. The Informix DATE data type requires 4 bytes, which is stored internally as an integer value equal to the number of days since December 31, 1899. The default display format can be changed with the environment variable DBDATE. If the application uses different date formats, then using DBDATE is not a solution. Sometimes it might be necessary to write small subroutines to emulate Oracles DATE representations. See the Informix Guide to SQL, Reference manual for details on DBDATE and also, DBCENTURY. If the application only references the time portion of the values, replace Oracles DATE with Informixs DATETIME using the EXTEND function to specify precision. In addition, Informix provides the data type INTERVAL for use while performing DATE and DATETIME calculations. In Oracle, the DATE data type is used to store date and time information. Although date and time information can be represented in both CHAR and NUMBER data types, the DATE data type has special associated properties. For each DATE value the following information is stored:

century

year

month

day

hour

minute

second

Also regarding the Oracle DATE data type, if a date value without a time component is specified, the default time is 12:00:00a.m. If a DATE value without a date is specified, the default date is the first day of the current month.

Interval

Within Informix there are two classes of interval types, YEAR-MONTH and DAY-FRACTION. There are different numbers if days in different months; so, the MONTH-DAY boundary cannot be crossed without creating ill-defined results. Within each of these classes, Informix allows you to declare columns or variables as any subset of the start and end fields. Oracle has one INTERVAL


Version 1.6 28

type for each of the two classes, YEAR(p) TO MONTH and DAY(p) TO SECOND(s). The Oracle scale on the SECOND field is logically equivalent to the Informix scale on the FRACTION field.

Raw data and Large Objects

Oracles support of large blocks of raw, unstructured data (such as graphic images, video clips, and sound waveforms) in binary or character format is provided by the large object (LOB) data types BLOB, CLOB, NCLOB, and BFILE. Traditional Oracle data types MLSLABEL (used with Trusted Oracle), RAW and LONG RAW are also used for data that is not to be interpreted by the engine and converted when moving data between different systems. Informix supports two types of large objects (LOBs; Simple Large Objects and Smart Large Objects. Simple LOBs consist of the TEXT and BYTE data types and can be 2

31 bytes or 2

Gigabytes in size. Smart LOBs include both Character Large Object (CLOB) and Binary Large Object (BLOB) data types and may be up to 4*2

40 bytes or 4 Terabytes in size. Simple LOBs can

be stored either in-line with table data

Documents

Oracle to Informix