I am attempting to fire up ISQL 4.10DC1 on MS-DOS 6.22, but cant seem to get PSTARTSQL.EXE to load, it says DOS16M Error[6]: Not enough memory.. I have DEVICE=C:\DOS\HIMEM.SYS as my first line in CONFIG.SYS and properly set all environment variables, including DOS16M=3. Anyone have any experience with this version of ISQL?..Does anyone have additional documentation for this legacy version?
====================
RELEASE NOTES
FOR
INFORMIX 4.10.DC1 PRODUCT RELEASE
=============================================================================
TABLE OF CONTENTS
I. OVERVIEW OF RELEASE NOTES
II. PRODUCTS CONTAINED IN THE 4.1 DOS CLIENT RELEASE
III. GENERAL DATABASE SERVER CONCERN
IV. SPECIAL CONSIDERATIONS FOR DEVELOPERS USING '4.1' RELEASE SOFTWARE
A) Un-bundling Of Database Server
B) Application Tool Compatibility
C) Compatibility Of Application Tools And Database Engines
D) Compatibility Items For Existing Applications
E) Changes From .02 & .06 In Cursor Manipulation With Transactions
F) Cursor Manipulation in the 4.1 Release
G) Impact of MODE ANSI Databases On Applications
H) Additional Documentation Information
I) C Functions In ACE And PERFORM
J) STORES & STORES2 Demonstration Databases
V. ISSUES FOR ALL PRODUCTS
A) Installation Memory Requirements
B) 932 Error using UNIX 4.1 SE Or 4.1 OnLine Engines
VI. INFORMIX-SQL SPECIFIC ISSUES
A) ISQL Real Mode Memory Requirements
B) ISQL Demonstration Programs
C) Use Of User Menu With Mode ANSI Database
D) The INFORMIX-SQL Menu AND SERIAL COLUMNS
E) Change In Terminology
VII. KNOWN PROBLEMS
11945 - 826: FORK SYSTEM CALL FAILED Message Using ISQL under
Low Memory Conditions
1896 - With ";", PAGE Trailer Prints on Wrong Page
2277 - SPERFORM Does Not Recognize All DBA Privileges
3448 - Extra Blank Line is Printed at the End of ACE Reports.
4318 - ACE Will Not Allow a Column Name to be the Same as a
Table Name in ORDER BY
4518 - ALTER TABLE With No Permission Allows Alter Then
Giving Errors at Build
12082 - Incorrect Output Using PISQL.EXE if Redirected to a File
12221 - The "OUTPUT TO PIPE" SQL Statement Generates Error 809
============================================================================
I. OVERVIEW OF RELEASE NOTES
The purpose of these release notes is to make you aware of
changes in products that might affect existing applications.
The release notes contain information on changes from previous
releases, known problems, and workarounds. Problem IDs are assigned
to known problems to assist you in identifying the problems in
discussions with Client Services personnel.
Release notes are not intended to be all-inclusive;
it is a tool to assist you in the update process. Please consult
Informix product manuals for additional information on product
features and for clarification of product behavior.
II. PRODUCTS CONTAINED IN THE 4.1 DOS CLIENT RELEASE
The following products are contained in the '4.1' version of this
DOS Client Release:
Product Name
------------
INFORMIX-SQL
INFORMIX-ESQL/C
INFORMIX-NET PC
III. GENERAL DATABASE SERVER CONCERN
It is particularly important to run the UPDATE STATISTICS command
occasionally. YOu should use it frequently when there is a great deal
of data manipulation occurring. This command updates the statistics
used by the query optimizer. The query optimizer determines the most
effective method for retrieving data from the database. Because the
optimizer is cost-based, the statistics it uses (number of rows,
minimum or maximum value in an index column, and so on) should be as
up-to-date as possible.
IV. SPECIAL CONSIDERATIONS FOR DEVELOPERS USING '4.1' RELEASE SOFTWARE
A) UN-BUNDLING OF DATABASE SERVER
==============================
Starting with the 4.1 release of the DOS products, all application
development tools (for example, INFORMIX-SQL), embedded language
products (for example, INFORMIX-ESQL/C), and database servers (for
example, INFORMIX-SE) are available as separate products. Therefore,
the DOS database server (Informix-SE) is no longer included with each
application tool. Please see the next section, "Compatibility of
Application Tools and Database Engines," for additional information.
B) APPLICATION TOOL COMPATIBILITY
==============================
Application tools labelled with a version number of X.10.06 do not work
with 4.10 I-Net-PC; the 06 products use a different communication
mechanism than the 4.1 products. Since different mechanisms are used,
it is not possible for an application built with an .06 application tool
to communicate with the 4.1 I-Net-PC.
If you want to use an application based on one of the .06 products
with 4.1 I-Net-PC, you must recompile the application with the 4.1
version of the application tool.
C) COMPATIBILITY OF APPLICATION TOOLS AND DATABASE ENGINES
=======================================================
The 4.1 DOS/Windows application tools can use either a remote 4.1 or 5.0
database engine via Informix-Net PC. No change isrequired in the 4.1
application to access a 5.0 database engine. However, some functionality
available in the 5.0 database engine will not be available to the
4.1-based application. For example, even though the 5.0 database engine
supports stored procedures, the 4.1 application tools do not have the
capability to use stored procedures. The general rule is that all
functionality available to the application tool in the 4.1 release is
available to the tool in the 5.0 database engine, but that functionality
available to 5.0 application tools cannot be taken advantage of by the
4.1 application tools.
D) COMPATIBILITY ITEMS FOR EXISTING APPLICATIONS
=============================================
Some of the changes, bug fixes or enhancements made in the 4.1
release could potentially require changes to existing applications.
We expect that incompatibilities will be rare; however, we are
providing the information so you can determine if you have any
applications that may require updating. Many of the following
items have references to additional information contained in the
documentation.
1. A change was made in the behavior of an ANSI-compliant database
so that cursors not explicitly declared "FOR UPDATE" are still
treated as update cursors. This is correct ANSI behavior. However,
if the cursors are not declared for update, no update lock is put on
the row when it is read. As a result, users may get lock errors when
they try to update the row. See the DECLARE statement in the
"Informix Guide to SQL: Reference" for further information.
2. For ANSI-compliant databases, if any statement fails to access rows,
the return code is now 100, instead of 0 as it is for databases
that are not MODE ANSI. See the section "SQLNOTFOUND and ANSI
Compliant Databases in Chapter 2 of the INFORMIX-ESQL/C Programmer's
Manual for further discussion.
3. The ANSI standard requires that all identifiers, including
owner names and login names, be in uppercase letters. In MODE
ANSI, you must enclose lowercase and mixed-case identifiers
in quotes if you want to preserve the case. Otherwise, all
owner and login names (except Informix and public) will be
shifted to uppercase. See the "Identifier" segment in Chapter 6 of
the "Informix Guide to SQL: Reference" for further information.
4. A new variable, SQLCODE, is available in INFORMIX-ESQL/C, and is
automatically set to return the same value as sqlca.sqlcode. This
variable was added for ANSI compliance. If an ESQL/C application
defines a variable called SQLCODE, then there will be conflicts with
the new, included SQLCODE variable. See the section "Using the
SQLCODE Variable" in chapter 2 of the INFORMIX-ESQL/C Programmer's
Manual for further information.
E) CHANGES FROM .02 & .06 IN CURSOR MANIPULATION WITH TRANSACTIONS
===============================================================
Following is an overview of the differences in the way that cursors
can be manipulated between 2.10.02 and 2.10.06 applications and 4.1
applications.
Note about DECLARE
------------------
The DECLARE statement establishes a relation in the application
tool between a cursor name and an SQL statement (INSERT or SELECT).
It declares and initializes the necessary application tool structures
to accommodate the sending and retrieval of data through subsequent
statements involving that cursor. It does not itself communicate
with the database engine. The only restriction placed upon location
of the DECLARE statement is that it must be within the same source
code module and prior to all other references to the cursor name.
For the rest of this discussion, be aware that the DECLARE statement
will not be considered as a cursor manipulation statement, and
therefore is not required to be within a transaction.
DOS 2.10.02 versions
--------------------
In DOS 2.10.02, Informix introduced the concept of INSERT cursors.
For databases that log transactions, all manipulation of INSERT
cursors (OPEN, PUT, FLUSH) must occur within explicit transactions.
DOS 2.10.06 versions
--------------------
Starting with the .06 version, both UPDATE and INSERT cursors needed
to be opened within transactions. Read-only SELECT cursors could
still be manipulated outside of transactions. COMMIT WORK still
closed all cursors.
.06 also marked the introduction of comprehensive release notes.
One statement in these release notes warned customers that Informix
Software would require all cursor manipulation to be inside
transactions in the next release. Subsequently, Informix Software
decided NOT to require all cursor manipulation to reside within
transactions.
Instead, the current release will allow cursors to be manipulated
in the same fashion as in .06, with the addition of the WITH HOLD
option so that cursors remain open and current positions maintained
even after a COMMIT WORK is issued.
DOS 4.1 version
---------------
The only change from .06 to 4.1 is the introduction of WITH HOLD
syntax in the DECLARE statement.
The use of the WITH HOLD keyword in 4.1 applications will have the
following effects:
- No WITH HOLD cursors will be closed when a COMMIT WORK is executed.
Instead, such cursors will be closed by a close cursor call or by
the exit of the program.
- WITH HOLD insert cursors can be manipulated totally outside of a
transaction.
- WITH HOLD update cursors can be opened and fetched outside of a
transaction. However, an UPDATE/DELETE WHERE CURRENT OF
cursor-name and its associated FETCH must occur within an explicit
BEGIN WORK / COMMIT WORK transaction block.
All other cursor capabilities from .06 remain the same.
See the discussion of the DECLARE statement in Chapter 6 of the
"Informix Guide to SQL: Reference" for further information.
Migration Implications
----------------------
Any 2.10.02 applications that use update cursors may need to be
modified to work with .06 and later releases. Essentially, if the
update cursor is manipulated (using an OPEN, FETCH, UPDATE, or DELETE
statement) outside of a transaction, it will receive an error. The use
of the WITH HOLD keywords in the declare statement should allow these
programs to achieve equivalent functionality within transactions as they
had with cursor manipulation outside of transactions.
F) CURSOR MANIPULATION IN THE 4.1 RELEASE
=======================================
The following rules are adhered to in the 4.1 release and will
be in effect for all later releases.
CLOSE CURSOR
------------
1. Cases that should result in an error:
a. Closing a cursor that has been declared but never opened.
b. Closing a closed cursor in a MODE ANSI database.
2. Cases that should NOT result in an error:
a. Closing an already closed cursor in a non-MODE ANSI database.
FREE CURSOR/STATEMENT ID
------------------------
1. Cases that should result in an error:
a. Closing a freed cursor.
2. Cases that should NOT result in an error:
a. Freeing a cursor or statement-id twice.
b. Freeing a cursor that has been declared but never opened.
In addition to the preceding rules, the following rules also apply:
A statement-id that has been FREEd needs to be
PREPAREd again in order to be used again.
A cursor that has been FREEd needs to be
DECLAREd again in order to be used again.
G) IMPACT OF MODE ANSI DATABASES ON APPLICATIONS
=============================================
The 4.1 Release offers support for MODE ANSI databases. One of the
features of the ANSI specification is that all objects (e.g., tables,
views, etc.) are associated with a specific owner, and permissions
are granted with respect to that object. This is commonly referred
to as the ANSI owner.object feature. One implication of this feature
is that a previously built application may encounter errors when
interacting with a MODE ANSI database. The database will expect
that all referenced objects be prefaced with a user name if
a user other than the object owner is attempting to access the
object, while the application would have been constructed without
user names. It is important that old applications be examined before
being used with a MODE ANSI database.
Additional differences that are introduced if you change a database
to MODE ANSI include:
- the BEGIN WORK statement is not needed, since transactions
are implicit
- the default system action upon a runtime error is CONTINUE,
rather than STOP
In a non-MODE ANSI database, the default is to grant all table-level
access privileges (except ALTER) to all users (PUBLIC). In a MODE
ANSI database, no default table-level privileges are granted. You
must explicitly grant these privileges. If you use START DATABASE
to convert your database to MODE ANSI, however, the existing
privileges remain in effect
If you set the new DBANSIWARN environment variable to test at runtime
for compliance with ANSI syntax, the BEGIN WORK statement can produce
an error, and other Informix extensions to the ANSI standard for SQL
syntax produce warnings.
H) ADDITIONAL DOCUMENTATION INFORMATION
====================================
Additional information and documentation updates for ISQL, I-NET PC,
and ESQL/C is available in the "documentation notes" files. This
documentation can be found in the RELEASE subdirectory where the
product(s) have been installed. Please review the following files
for information that is not in the printed publications.
ISQL - DOCISQL.410
I-NET PC - DOCINET.410
ESQL/C - DOCESQLC.410
I) C FUNCTIONS IN ACE AND PERFORM
==============================
For the 4.1 release, the capability of customizing ACE
reports and PERFORM forms (ACE and PERFORM are in the INFORMIX-SQL
product) with C language routines was removed from INFORMIX-ESQL/C
and has been incorporated into the INFORMIX-SQL product. This
capability is described in the INFORMIX-SQL Reference Manual.
J) STORES & STORES2 DEMONSTRATION DATABASES
========================================
The STORES demonstration database used in the x.10.06 release has been
replaced. The new name of the demonstration database is STORES2.
V. ISSUES FOR ALL PRODUCTS
A) INSTALLATION MEMORY REQUIREMENTS
===============================
User's must have at least 450K of conventional memory available on
their PC before installing any of the DOS 4.1 products. The
INSTALL program may give the user a runtime error in certain
situations where memory is less than 450K. If users encounter
this problem, they will need to "free-up" conventional memory
and re-run the installation program.
B) 932 ERROR USING UNIX 4.1 SE OR 4.1 ONLINE ENGINES
=================================================
There is a known problem with some ports of the 4.1 UNIX engines
(both SE and OnLine) that will occur when trying to select an existing
database from ISQL. If a new database is created, it can be accessed
during the ISQL session in which it was created. However, error number
932 may occur when the database is selected during a new ISQL session.
This problem has been fixed in the 4.1 & 5.0 engines. Customers
experiencing this problem should contact Informix to request the
status of a software patch.
VI. INFORMIX-SQL SPECIFIC ISSUES
A) ISQL REAL MODE MEMORY REQUIREMENTS
==================================
The following chart shows the minimum memory requirements (in KBytes)
for running ISQL 4.1 in DOS Real Mode. Additional memory would be
required to compile a form or report.
------------------------------------------------------------------------
| |IPX| |PCTCP| |NFS| |StarGroup| |Pathway|
------------------------------------------------------------------------
| Actual Protocol Driver Requ.:* 60 103 85 178 33 |
| I-NET PC Memory Requ.: 65 70 71 55 79 |
| ISQL 4.1 Memory Requ.: 380 380 380 380 380 |
| --- --- --- --- --- |
| Total: 505 553 536 613 492 |
------------------------------------------------------------------------
* The following versions were used to compute these figures:
Novell's IPX/SPX ver. 3.11, FTP's PC/TCP ver. 2.05PL4,
SUN's PC-NFS ver. 3.5, AT&T's StarGroup ver. 3.4,
Wollongong's Pathway Access ver. 2.0.
B) ISQL DEMONSTRATION PROGRAMS
===========================
The ISQLDEMO program for ISQL can only be used by customers
that have installed the protected mode version of ISQL on their
workstation. See the DOCISQL.410 file for more information.
C) USE OF USER MENU WITH MODE ANSI DATABASES
=========================================
Because of the owner identification of objects in MODE ANSI databases,
the person who first creates the user menu by choosing the Modify
option is the only user who will be able to change the menu. All
others attempting to modify the user menu will receive an error
message.
D) The INFORMIX-SQL Menu AND SERIAL COLUMNS
========================================
Prior to the 4.1 release, INFORMIX-SQL allowed a user to modify the
indexing of a serial column through its menu. This was incorrect usage
of the menu and is no longer allowed. However, a change to the indexing
status of a serial number may still be achieved through the use of a
query-language script.
E) CHANGE IN TERMINOLOGY
=====================
All references to the RDSQL language in 4.1 documentation have been
changed to SQL.
VII. KNOWN PROBLEMS
Bug # 11945: 826: "FORK SYSTEM CALL FAILED" MESSAGE USING ISQL UNDER
LOW MEMORY CONDITIONS.
-----------------------------------------------------------------------
Under certain low-memory conditions, ISQL will not present the user
with the standard "Out Of Memory" message. Instead, error message
"826: fork system call failed " will be displayed.
WORK AROUND: Free more conventional memory for use.
Bug # 1896: WITH ";", PAGE TRAILER PRINTS ON WRONG PAGE
-----------------------------------------------------------------------
In ACE, if the last line of your PAGE TRAILER control block
suppresses the line feed (That is, the last PRINT statement ends with
a ';'), then the text prints at the top of the following page.
WORK AROUND: There is no good reason to end a PAGE TRAILER without
a line feed. Add a PRINT "" statement at the end, or remove the ';'.
Bug # 2277: SPERFORM DOES NOT RECOGNIZE ALL DBA PRIVILEGES.
-----------------------------------------------------------------------
SPERFORM does not recognize that a DBA has all table level access.
WORK AROUND: GRANT {DBA-user} ALL ON {table-name}
Bug # 3448: EXTRA BLANK LINE IS PRINTED AT THE END OF ACE REPORTS.
-----------------------------------------------------------------------
SACEGO appends a blank line to the end of reports when the statements
OUTPUT TO "file-name" or OUTPUT TO PIPE "program-name" are used.
WORK AROUND: Use the "quiet" option with SACEGO which suppresses the
banner. Example: Use "sacego -q {report-name}"
Bug # 4318: ACE WILL NOT ALLOW A COLUMN NAME TO BE THE SAME AS A TABLE
NAME IN ORDER BY
-----------------------------------------------------------------------
A SELECT statement of the type
SELECT * FROM xyz
ORDER BY xyz.xyz
causes syntax errors when trying to compile with ACE, even
if xyz is a valid column in the table, xyz.
WORK AROUND: Use the column number in its place or leave of the
"xyz." part.
Bug # 4518: ALTER TABLE WITH NO PERMISSION ALLOWS ALTER THEN GIVES
ERRORS AT BUILD TIME
-----------------------------------------------------------------------
If you use the Alter option from the TABLE menu on a table for
which you do not have permission, INFORMIX-SQL lets you go ahead and
perform your alterations, and then notifies you that you have no
permission when you attempt to Exit or Build the table. You have done
nothing permanent. However, ideally, you would be notified before you
performed the alterations.
WORK AROUND: There is none needed, because ISQL does not modify the
table.
Bug # 12082: INCORRECT OUTPUT USING PISQL.EXE IF REDIRECTED TO A FILE
-----------------------------------------------------------------------
When you run INFOMRIX-SQL from a command line and redirect the output
to a file an extra blank line will be added to the end of the file.
WORK AROUND: None
Bug # 12221: THE "OUTPUT TO PIPE" SQL STATEMENT GENERATES ERROR 809.
-----------------------------------------------------------------------
"OUTPUT TO PIPE" command is not supported in DOS environment.
WORK AROUND: None, this is unsupported in the DOS environment.