i've upgraded test (onebox) environment to Platform update 32 and i cannot start Microsoft Dynamics 365 Unified Operations: Batch Management Service, there is a warning message that says:
In event viewer i see the following:
What i've tried so far:
1) Synchronized and built application from Visual Studio - fine
2) Checked if system is in maintenance mode - it is not
3) Tried to play with "Log on" tab of the service (on behalf of which user service is running) - didn't help
4) Checked if event log is full, cleared, extended allowed space for log twice and let it overwrite itself if it's full - didn't help
P.S. I suggest there is something with database (maybe any issue is enabled/disabled) but i cannot understand which one exactly (cannot find ScaleUnitFeature from event log anywhere).
I cannot restore/delete/replace database because it's important to keep all the data/set up on it
I have a Windows service written in VB.NET 2.0 which connects to an IBM AS/400 server. Queries work fine, but when I try to do something like deleting a spool file, I get errors. For example:
CPYSPLF FILE(PO630A) TOFILE(MPLCDATPAR/PO630APF) JOB(083064/ARUSER/POASYNCMON) SPLNBR(80) MBROPT(*REPLACE)
Running this command with ExecuteNonQuery yields:
CPF3342 - Job not found 083064/ARUSER/POASYNCMON
However, if I run that same command locally in AS/400, it works just fine. We already checked permissions. What else could be causing the command to fail this way? How can I get more information about the error, or go about troubleshooting this?
EDIT: This problem (and a lot of other ones) appeared when we migrated our server (where the .NET service runs) from Windows Server 2003 to Windows Server 2008.
How can I get more information about the error, or go about troubleshooting this?
The first thing is to verify that the IBM AS/400 server [what OS Version Release and Modification level, Technical Refresh (TR) level (if instead IBM i), Cumulative PTF level were all omitted.?.?] used for the connection is the same server used to perform the command-line invocation; i.e. on the server where the command-line invocation will be made to verify the command is functional, find the active server job in which the CPF3342 is still visible in the log.
The second thing to do is to get the spooled joblog showing the full details of the CPF3342 [and possibly any preceding message(s) that might be related]. If for example the message is not actually that message or is not sent by the expected program QSPCPYF, then immediately the direction of investigation probably would change. What is shown is apparently what is presented at the client, not what came from the server joblog; the USEnglish formatting I believe is "Job &5/&4/&3 not found." for which the formatting "CPF3342 - Job not found &5/&4/&3" is suspect.
To ensure the most appropriate comparison to the request made from the client:
• the local user that is signed-on to perform the same request should be the same user as the Current User of the active job found to be servicing the client request
• the local user should establish the same System Library List as the active job found to be servicing the client request
If such an incident recurs or even if the same incident persists, then verify the once again the re-create is still possible using the same interface [i.e. the condition\failure persists] and again verify the command-line request is successful [i.e. the circumvention is confirmed, that the same request is possible to be performed at the command-line]; and according to my earlier comment, first ensuring the same server by finding the active job that logs the CPF3342. Immediately afterward:
• Collect a job trace for the Copy Spooled File (CPYSPLF) request; for the failing case, review for any exception\interrupt conditions [with or without a message as accompanying trace data] that precede the program flow for the issuance of the msg CPF3342.
• Review the audit log for any T-AF or anything odd\unexpected at very close to the time of the failing request; expansive auditing should have been established since before the connection to the server.
• Contrast those data collections of the failing case with the same data taken from the successful processing.
Although the symptom [as lightly described, without the full joblog] the possibility of command-exits seems remote, the trace would reveal if the command in either scenario were intercepted by the Command Exit points; these can be reviewed separately [rather than looking in the trace] for any Exit Program, using the Work With Registration Information (WRKREGINF) to review any QIBM_QCA* entries in the repository for what exit programs might impact the CL Command request. But IIRC the trace-data shows which command was invoked, so the trace would also reveal if the unqualified command requests resolved to different *CMD objects.
I'm new to dealing with cookies and not sure if my code or maybe Indy version is the problem based on researching other posts.
Using Delphi 2010 and Indy 10.5.5.
Have set up a cookiemanager at design time. I can send an initial login request (using the POST method) to the server that is successful (get a "success" code back from the server app) and the cookie manager shows that it has accepted a cookie from the server.
When I try to reply to the server (again using POST) to get the next set of information, I get an error code back from the server app which indicates an authorization failure and I'm being told by the server tech support people to check the cookie being sent with the reply.
How can I check the contents of the cookie header that is being sent back to the server?
Also, in another post I saw that Indy 10 IdCookieManager.pas and IdCookie.pas have been updated in 2011. Should I update my Indy to the latest version as this might be my problem?
Thanks in advance.
Here is some more info:
Thank you for your previous assistance; I appear to be getting closer to reinstalling Indy10.
I purged my system of all Indy stuff except the most recent version (10.5.8) which I downloaded yesterday. [Actually I just moved the old stuff into a directory with an unusual name.]
Now I get a clean compile on all 5 packages.
I was able to add the two main packages (the ones starting with dcl) to my program's project list.
But I get "[DCC Fatal Error] E2202 Required Package IndyCore not found." when I try to compile my main program.
I tried removing and reinstalling the dcl packages to my project. When I removed them, I got the message that IndyCore and 3 other packages would also be removed - so it seems to know that dclIndyCode140 uses IndyCore140.
I've added some directories to my search path and tried placing the 5 bpl's in different directories. None of that had any effect and at this point I am stumped.
Ideas? Suggestions?
Steve
Upgrading to the latest release is definate recommended. Links are on Indy`s website. Yes, cookie support was broken in earlier Indy 10 releases but it working again now.
As for your other question, to see what TIdHTTP is sending, you have a few choices:
Look at the TIdHTTP.Request.RawHeaders property after sending a request.
Attach one of Indy's TIdLog... components to TIdHTTP, such as TIdLogFile, and look at the output.
Use an external packet sniffer, such as Wireshark.
I have a set of legacy Delphi 6 aplications that are out of process COM servers. In attempting to run these programs as a normal domain user on Windows I see them when running up (without any command line arguments or switches) attempting to update chunks of HKEY_CURRENT_CLASSES. this fails due to lac of permission to the HKCR hive. It appears that the act of running a Delphi 6 COM server causes it to attempt to register its embedded COM types with the system registry.
I do not want this behavior normally. We would do this once during install under and adminatrative account to initalise the COM registry, but would not want to do this under normal running conditions of a non adminastrative account. (if you moniroy the system with sys internals process monitor you can see the failed registry key access attempts).
Is there a command line switch I can pass to a Delphi 6 COM server to prevent this automatic COM registrtion logic?
I don't think you're actually seeing what you think you are...
Delphi only tries to install COM servers if they haven't already been installed. I suspect what you're seeing is your application checking to see if it's registered yet or not. The reason you're seeing the failures is because back in Delphi 6 the registry key would have been opened with ALL_ACCESS rights (D6 was prior to XP/Vista/Win7), and I think that's what's causing your failed registry access attempts.
In answer to your question, though: No, there's no command line switch to prevent the automatic registration logic.
It will always try to register the server from TComServer.Initialize unless the startup parameter is /UNREGSERVER which will remove the registry settings. If the startup parameter is /REGSERVER you will get an exception if the registration failed otherwise it will just swallow the exception. Automatic registration of out-proc COM servers has been removed in later version of Delphi. The only option you have to remove this behavior in Delphi 6 is to modify TComServer.Inititalize to only register the server when FStartMode is smRegServer or smUnregServer.
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.
Resolved by adding option /INT15=32768 to HIMEM.SYS.