VAX_Rdb/VMS_________________________________________
Release Notes for Version 4.0B
March 1992
This document contains the Release Notes for VAX
Rdb/VMS Version 4.0B and describes the problems fixed
in this release, additional known problems not fixed,
and additional restrictions.
Revision/Update Information: This manual is a
revision and supersedes
previous versions.
Operating System: VMS
Software Version: VAX Rdb/VMS Version
4.0B
Digital Equipment Corporation
Maynard, Massachusetts
________________________________________________________________
The information in this document is subject to change
without notice and should not be construed as a commitment
by Digital Equipment Corporation. Digital Equipment
Corporation assumes no responsibility for any errors that
may appear in this document.
The software described in this document is furnished under
a license and may be used or copied only in accordance with
the terms of such license.
No responsibility is assumed for the use or reliability
of software on equipment that is not supplied by Digital
Equipment Corporation or its affiliated companies.
Restricted Rights: Use, duplication, or disclosure by the
U.S. Government is subject to restrictions as set forth in
subparagraph (c)(1)(ii) of the Rights in Technical Data
and Computer Software clause at DFARS 252.227-7013.
© Digital Equipment Corporation 1992.
All Rights Reserved.
The postpaid Reader's Comment form at the end of this
document requests your critical evaluation to assist in
preparing future documentation.
The following are trademarks of Digital Equipment
Corporation: ACMS, ALL-IN-1, CDD/Plus, CDD/Repository, CI,
DEC, DECdecision, DECdtm, DECforms, DECintact, DECnet,
DECtp, DECtrace, DECwindows, HSC, MASSBUS, MicroVAX,
PATHWORKS, RA, Rdb/VMS, ULTRIX, UNIBUS, VAX, VAX Ada,
VAX BASIC, VAX C, VAX CDD, VAX COBOL, VAX DATATRIEVE,
VAX DBMS, VAX DOCUMENT, VAX FMS, VAX FORTRAN, VAX Pascal,
VAX Performance Advisor, VAX RALLY, VAX Rdb/ELN, VAX RMS,
VAX SCAN, VAX 6000, VAX SPM, VAX TEAMDATA, VAX Xway,
VAXcluster, VAXELN, VAXset, VAXstation, VIDA, VMS, VT,
and the DIGITAL logo.
AppleTalk and Macintosh are registered trademarks of Apple
Computer, Inc. MPW is a trademark of Apple Computer, Inc.
Motorola and 68000 are registered trademarks of Motorola,
Inc. MS-DOS and Microsoft are registered trademarks of
Microsoft Corporation. OS/2 is a trademark of International
Business Machines Corporation.
This document is available on CDROM.
This document was prepared using VAX DOCUMENT, Version 2.0.
_________________________________________________________________
Contents
Preface................................................... ix
1 Software Problems Fixed in Rdb/VMS V4.0B
1.1 General Information........................... 1-1
1.1.1 Privileges Required to Execute the
RMU/DUMP, RMU/OPEN, and RMU/CLOSE
Commands.................................. 1-1
1.2 Software Problems Fixed That Apply to All
Interfaces of Rdb/VMS V4.0B................... 1-2
1.2.1 Total Relation Boolean Was Not Generated
Properly in a Leaf Strategy............... 1-2
1.2.2 ALTER STORAGE MAP Statement Caused Rdb/VMS
to Bugcheck When Combined with Disabling
Compression............................... 1-2
1.2.3 SQL or RDO Hung During INTEGRATE
Operation................................. 1-3
1.2.4 Optimizer Did Not Recognize That an Index
Segment Was Compressed.................... 1-3
1.2.5 Defining a Remote Logical Name Denied
Access to the Local Node.................. 1-4
1.2.6 Transfer of Large Blocks of Data over the
Network Resulted in an Error.............. 1-4
1.2.7 COBOL Lines Generated That Did Not Comply
with the ANSI Standards................... 1-5
1.2.8 Optimization of Constraint Processing Was
Limited................................... 1-5
1.2.9 NOWAIT Transactions Started During a
Recovery Process Caused an RDMS-F-AREABUSY
Fatal Error............................... 1-5
1.2.10 DACCESS Audit Event Required a Minimal Set
of Privileges for Auditing to Occur....... 1-6
iii
1.2.11 UPDATE Privilege Access for Table with
DACCESS Audit Event Was Not Captured...... 1-7
1.2.12 Virtual Memory Increased with Some Fourth
Generation Languages...................... 1-7
1.2.13 Collating Sequence Problems............... 1-7
1.2.14 Improper Error Displayed When Exporting
and Importing to Use a Different Collating
Sequence.................................. 1-8
1.2.15 Multisegmented Index Was Not Selected When
a Not-Equal Predicate Was Specified....... 1-8
1.2.16 Privilege Violation in Batch-Update Caused
Database Corruption....................... 1-9
1.2.17 A Join Query Matched a Null Aggregate
or Expression to a Column with Zeros or
Blanks and Produced Incorrect Results..... 1-9
1.2.18 Bugcheck Occurred with an Exception at
RDMS$$RSS$ASN_FOR_RSS$NDX................. 1-10
1.2.19 Incorrect Results Returned on Join
Operations Using Partitioned Indexes...... 1-10
1.2.20 Arithmetic Exception Resulted When Joining
Integer Columns........................... 1-11
1.2.21 Query with Computed-By Field and OR
Returned Incorrect Results................ 1-11
1.2.22 CHANGE DATABASE Statement Resulted in Bad
Parameter Error Message................... 1-12
1.2.23 Defining a Partitioned Hashed Index
Resulted in Corruption.................... 1-12
1.2.24 Change in Operation of Index Deletion..... 1-13
1.2.25 Rdb/VMS Monitor Failed When the Last User
Finished on a Particular Database......... 1-14
1.2.26 Comparing Integer and Text Fields Caused
Problems.................................. 1-14
1.3 SQL Problems Fixed in Rdb/VMS V4.0B........... 1-15
1.3.1 REORGANIZE Clause Caused a Bugcheck....... 1-15
1.3.2 Updating the Cardinality of a Relation
Caused a Bugcheck......................... 1-15
1.3.3 Memory Lost Between Database Attaches..... 1-15
1.3.4 Incorrect Conversion of Numeric Data Types
Caused Erroneous Values for Scales........ 1-16
1.3.5 Using the IGNORE CASE Option of the LIKE
Clause Sometimes Resulted in a Query That
Incorrectly Returned No Rows.............. 1-16
iv
1.3.6 Record Parameters Could Not Be Used Where
Values Were Expected...................... 1-17
1.3.7 Certain Trigger Definitions Caused a
Bugcheck.................................. 1-17
1.3.8 SQLTYPE Value Fixed in the SQLDA.......... 1-18
1.3.9 Bugcheck Returned by System When User with
Incorrect Privileges Showed Protection on
a Schema.................................. 1-18
1.3.10 SQL Incompatibilities in Rdb/VMS V4.0 That
Are Fixed in Rdb/VMS V4.0B................ 1-18
1.3.10.1 Incompatibilities Between Object
Modules................................. 1-18
1.3.10.2 Incompatibilities Between TABLE and LIST
Cursors................................. 1-20
1.3.10.3 Incompatibilities Between Cursors and
COMMIT or ROLLBACK Statements........... 1-20
1.3.11 Message Vector Contained Erroneous
Information About the Number of Longwords
Used...................................... 1-20
1.3.12 Common Data Dictionary (CDD/Plus) Fields
with Scales Were Not Always Properly
Translated................................ 1-20
1.3.13 UNION Queries Returned Incorrect Data on
Numeric Data Types........................ 1-21
1.3.14 Modules That Used the DECLARE TRANSACTION
Statement Were Ignoring TXN Attributes.... 1-21
1.3.15 Embedded SQL Ada Programs Could Not Use
LIST Cursors.............................. 1-21
1.3.16 Views That Selected Dbkeys Caused a
Bugcheck.................................. 1-21
1.3.17 Dynamic SQL Statements with Indicator
Arrays Were Not Correctly Handled Prior to
Rdb/VMS V4.0B............................. 1-21
1.3.18 SQL Allocated More Memory Than Necessary
During a Dynamic SET TRANSACTION
Statement................................. 1-22
1.3.19 Preparing a Statement with D-float
Parameters Caused a Bugcheck.............. 1-22
1.4 SQL/Services Problems Fixed in Rdb/VMS V4.0B.. 1-22
1.4.1 Unpredictable Results Occurred When Trying
to Store Segmented Strings from the
Macintosh Environment Using DECnet........ 1-22
v
1.4.2 Certain Calls to the sqlsrv_fetch_many
Routine Caused Problems................... 1-23
1.4.3 Authorization Failure Occurred When SYSUAF
Flag LOCKPWD Was Set...................... 1-23
1.4.4 Column Limit Raised to 500................ 1-23
1.4.5 SQL/Services Failure Did Not Produce a
Bugcheck File............................. 1-24
1.4.6 VMS Application Programming Interface
(API) Installation Failed Without Rdb/VMS. 1-24
1.4.7 SQL$STARTUP.COM Startup File Contained an
Error in the SQL/Services Startup Logical
Name...................................... 1-24
1.4.8 SQL/Services MS-DOS API Installation
Failed.................................... 1-25
1.4.9 Macintosh API Installation Failed......... 1-25
1.4.10 Node Names Containing Numeric Characters
Were Improperly Made Uppercase in OS/2
API....................................... 1-25
1.5 RDO, Callable RDO, RDBPRE, and RDML Problems
Fixed in Rdb/VMS V4.0B........................ 1-25
1.5.1 Incorrect Value Was Stored During an RDO
STORE or MODIFY Operation................. 1-25
1.5.2 Multiple RDO Commands in a FOR Loop Caused
Unpredictable Results..................... 1-26
1.5.3 A Query Using Static OR and a Common
Subexpression in Two or More OR Legs
Produced Incorrect Results................ 1-27
1.5.4 RDB$INTERPRET Now Fully Supports VS
(Varying String) Descriptors.............. 1-28
1.5.5 Query with a FOR Loop and MODIFY Statement
Followed by a PRINT Statement Returned
Incorrect Results......................... 1-29
1.5.6 Bugcheck Returned Because CHANGE FIELD Had
No VALID IF............................... 1-29
1.5.7 Shared Fields in a Relation and a View
Caused a Bugcheck......................... 1-30
1.5.8 Changing Records in CDD/Plus Caused an
Error..................................... 1-30
1.6 RMU Problems Fixed in Rdb/VMS V4.0B........... 1-31
1.6.1 RMU/VERIFY Reported False MINGTRSIZ Error
Messages ................................. 1-31
1.6.2 RMU/VERIFY Reported False AIPENTMBZ
Warning Messages.......................... 1-31
vi
1.6.3 Index Cardinality Not Maintained When
an Application Performed Only a Few
Insertions or Deletions................... 1-32
1.6.4 RMU/CLOSE/CLUSTER/WAIT Hung the Database
in a Cluster Environment.................. 1-32
1.6.5 SPAM Threshold Calculations Resulted in
Errors Reported by the RMU/VERIFY Command. 1-33
1.6.6 Hashed Index Verification Caused Buffer
Flushing Problem.......................... 1-33
1.6.7 RMU/COPY or RMU/MOVE Command Incorrectly
Copied Area Inventory Pages (AIP)......... 1-33
1.6.8 TA90E and TA91 Tape Drives Were Not
Recognized in Rdb/VMS V4.0B............... 1-33
2 Known Problems, Restrictions, and Other Notes for
Rdb/VMS V4.0B
2.1 General Problems, Restrictions, and Notes..... 2-1
2.1.1 Singleton Subselect Statement Returning
Incorrect Results Partially Fixed in
Rdb/VMS V4.0A But Not Fixed in V4.0B...... 2-1
2.1.2 VMS Lock Remastering Changed in VMS V5.4.. 2-1
2.2 Problems, Restrictions, and Notes for All
Interfaces.................................... 2-2
2.2.1 Queries Using LIKE Predicate Run Slowly... 2-2
2.2.2 Sequential Retrieval Causes Problems with
Dynamic Optimizer......................... 2-3
2.2.3 Anomalous Update Occurs with Subqueries... 2-3
2.2.4 INSERT Command to Double the Contents of a
Table Results in an I/O Loop.............. 2-4
2.2.5 A Problem in PSII$DELETE_EMPTY_NODE Causes
an Error.................................. 2-5
2.2.6 Range Query Returns Unexpected Results.... 2-5
2.2.7 Cannot Correctly Import a Database That
Contains Computed-By Fields That Reference
Other Computed-By Fields.................. 2-6
2.2.8 Using Quoted Threshold Values for
Binary Data Types for Partitioning Data
or Indexes Results in Data or Index
Corruption................................ 2-7
2.2.9 Problem Comparing Different Data Types.... 2-8
2.2.10 RDB$REMOTE Account That Has SYSTEM as
Owner Creates Installation Problems....... 2-9
vii
2.2.11 Read/Write Query with Multiple Range
Predicates on an Index Column Performs
Poorly.................................... 2-10
2.2.12 Synchronization Problem for an Empty
Sorted Index.............................. 2-10
2.2.13 Query Optimizer Does Not Choose Index-Only
Retrieval When the Dbkey Is Selected...... 2-12
2.2.14 Rdb/VMS Hangs on a SELECT Statement When a
Column Data Type Is Changed from INTEGER
to CHARACTER to DATE...................... 2-14
2.2.15 Triggers That Affect Subject Table Rows
Can Cause Loops or Inconsistent Results... 2-15
2.2.16 Relation Name Must Match Dictionary Record
Name...................................... 2-16
2.2.17 NOWAIT Transactions Have Their Buffers
Invalidated at Commit Time................ 2-16
2.3 SQL Problems, Restrictions, and Notes......... 2-16
2.3.1 SQL Deprecated Features and Incompatible
Changes for VAX Rdb/VMS V4.1.............. 2-16
2.3.2 SQL to Support Error Code Values in
Rdb/VMS V4.1.............................. 2-19
2.3.3 An SQL SELECT Statement Results in an
Invalid BLR Error......................... 2-19
2.4 RDO, RDBPRE, and RDML Problems, Restrictions,
and Notes..................................... 2-20
2.4.1 An Incompatible Change for RDO
Applications: New Update Rules Will Be
Enforced by Default in Rdb/VMS V4.1....... 2-20
2.4.2 Aggregate Expressions in RDO Return an
Error..................................... 2-22
2.4.3 Certain Reserved Words Cannot Be Used as
Database Handles for RDBPRE or as Aliases
for SQL$PRE and SQL$MOD................... 2-23
2.4.4 Wrong Number of Records Returned by a
Query in an Inner FOR Loop................ 2-23
2.4.5 RDO IMPORT Statement Does Not Save All SQL
Defined Attributes........................ 2-24
2.4.6 RDO CONVERT Statement on V3.0 Databases
Causes Database Corruption When the
Database Is Converted to V4.0B............ 2-24
2.5 Rdb/VMS Management Utility (RMU) Problems,
Restrictions, and Notes....................... 2-25
viii
2.5.1 Do Not Delete After-Image Journal (.AIJ)
Backup Files if the AIJ Backup Fails or Is
Terminated................................ 2-25
2.5.2 Concealed Logicals Are Supported but No
Longer Recommended for Use After V4.0..... 2-26
2.6 Problems and Restrictions Related to the
Common Data Dictionary (CDD/Plus)............. 2-26
2.6.1 RDO or SQL INTEGRATE Statement Fails with
a NO_META_UPDATE Error.................... 2-27
2.6.2 Restriction with CDD/Plus V4.3............ 2-27
2.7 Rdb/VMS Documentation Errors and Omissions in
V4.0.......................................... 2-27
2.7.1 Undocumented SQL ALTER DOMAIN and RDO
CHANGE FIELD Statement Restriction........ 2-27
2.7.2 Documentation Error Regarding Microsoft
C Compatible Assembler Required for
the SQL/Services MS-DOS Application
Programming Interface (API) Installation.. 2-28
2.7.3 Incorrect Reference in V4.0 VAX Rdb/VMS
SQL Reference Manual, Chapter 3........... 2-28
2.7.4 Printing Error in V4.0 VAX Rdb/VMS SQL
Reference Manual, Chapter 4............... 2-28
2.7.5 Documentation Error in V4.0 VAX Rdb/VMS
SQL Reference Manual, Appendix D.4........ 2-29
2.7.6 SQL/Services Error Documentation.......... 2-29
2.7.7 RDMS$BIND_VALIDATE_CHANGE_FIELD Logical
Name Was Not Documented in V4.0........... 2-30
2.7.8 RDMS$BIND_VM_SEGMENT Logical Name Was
Misnamed in the V3.1 Documentation and Was
Not Documented in V4.0.................... 2-31
2.8 SQL/Services Troubleshooting Suggestions...... 2-31
2.8.1 Common SQL/Services Network Errors........ 2-31
2.8.2 Common SQL/Services Fatal Execution Server
Errors.................................... 2-32
2.8.3 Common SQL/Services API Installation
Failures.................................. 2-33
2.8.4 SQL/Services Compatibility Issues......... 2-34
2.8.4.1 SQL/Services V4.0B Server Uses
Proxy-Like and Default Access to
ix
Authorize V3.0 or V3.1 Client
Applications............................ 2-34
2.8.4.2 SQL/Services V4.0B Server Error -2031
Returned to V3.1 Client APIs............ 2-35
2.8.4.3 Queue Manager Must Be Started for the
SQL/Services IVP to Work................ 2-35
3 Optional ECO Patches for VAX Rdb/VMS V4.0B
3.1 Optional ECO Patches That Can Be Applied to
Rdb/VMS V4.0B................................. 3-1
3.1.1 RDMSHRP ECO 30: Poor OR Optimization
Performance on Read/Write Transactions.... 3-1
Tables
2-1 SQL/Services Network Errors............... 2-30
x
_________________________________________________________________
Preface
VAX Rdb/VMS software is a general-purpose database
management system based on the relational data model.
This manual describes new and changed features, problems
fixed in the VAX Rdb/VMS Version 4.0B release, current
problems, additional restrictions, optional ECO patches,
and other notes.
Intended Audience
These release notes are intended for all users of Rdb/VMS
Version 4.0B, and should be read to supplement information
contained in the Rdb/VMS Version 4.0 documentation set and
the Mandatory Update for VAX Rdb/VMS Versions 3.1B and 4.0.
To get the most out of this manual, you should be familiar
with Rdb/VMS, data processing procedures, and basic
database management concepts and terminology.
A Note on the Terminology
When the SQL and RDO interfaces use different terms to
describe the same entity or concept, this manual uses
the SQL term, unless the discussion is specifically about
RDO or RDML. (This is also true of most other manuals in
the Rdb/VMS documentation set.) For example, this manual
normally uses table instead of relation, column instead of
field (of a relation), and row instead of record.
The VAX Rdb/VMS Introduction and Master Index contains a
more detailed list of SQL terms and their RDO equivalents.
ix
Operating System Information
The version of VMS running on your system must be at least
Version 5.3 for Rdb/VMS V4.0B. Other information about the
versions of the operating system and related software that
are compatible with this version of Rdb/VMS is included in
the Rdb/VMS media kit and the V4.0 VAX Rdb/VMS Installation
Guide.
For information on the compatibility of other software
products with this version of Rdb/VMS, refer to the System
Support Addendum (SSA) that comes with the Software Product
Description (SPD). You can use the SPD/SSA to verify which
versions of your operating system are compatible with this
version of Rdb/VMS.
Structure
This manual contains information pertaining to Rdb/VMS
Version 4.0B.
Chapter 1 Describes known software errors that are
fixed in VAX Rdb/VMS Version 4.0B.
Chapter 2 Describes current problems, additional
restrictions, and workarounds known
to exist for VAX Rdb/VMS Version
4.0B. This chapter also describes
documentation errors and omissions in VAX
Rdb/VMS Version 4.0 and troubleshooting
suggestions for SQL/Services.
Chapter 3 Describes the optional ECO patches that
can be applied to VAX Rdb/VMS Version
4.0B.
Related Manuals
For more information on VAX Rdb/VMS, see the following
manuals in the Rdb/VMS documentation set. Note that all
books cited are found in the V4.0 documentation set.
o VAX Rdb/VMS Introduction and Master Index
x
Introduces Rdb/VMS and explains major terms and
concepts. Includes a glossary, a directory of Rdb/VMS
documentation, and a master index that combines entries
from all the Rdb/VMS manuals.
o VAX Rdb/VMS Guide to Distributed Transactions
Describes the two-phase commit protocol and distributed
transactions, explains how to start and complete
distributed transactions using SQL, RDBPRE, and RDML,
and how to recover from unresolved transactions using
RMU commands.
o VAX Rdb/VMS Guide to Database Design and Definition
Explains how to design a logical database and how to
translate that design into a physical database using
Rdb/VMS data definition statements.
o VAX Rdb/VMS Guide to Database Maintenance and
Performance
Provides guidelines for maintaining good database
performance, and explains how to use the database
maintenance utilities to perform backup and recovery
operations, restore journals, and analyze the database.
o VAX Rdb/VMS Guide to Database Tuning
Introduces the concept of tuning, and explores how
tuning the system, the database, and the application
affects database performance. Describes steps to follow
in identifying, analyzing, isolating, and solving a
performance problem, and in monitoring the resulting
solution. Includes a set of decision trees that provide
an organized approach to solving some common database
tuning problems.
o VAX Rdb/VMS Guide to Using RDO, RDBPRE, and RDML
Describes how to use the features of Rdb/VMS to
retrieve, store, change, and erase data. Shows how to
write programs that use Rdb/VMS as a data access method;
contains information on writing programs in high-level
languages that are supported by Rdb/VMS preprocessors,
including Relational Data Manipulation Language (RDML);
and describes Callable RDO, an interactive utility for
languages without preprocessors.
o VAX Rdb/VMS Guide to Using SQL
xi
Introduces the Rdb/VMS SQL (structured query language)
interface, and shows how to retrieve, store, and update
data interactively and through application programs. Can
be used as a tutorial for learning the major features of
SQL.
o VAX Rdb/VMS Guide to Using SQL/Services
Describes how to develop application programs that use
SQL/Services, a client/server software component of
Rdb/VMS. SQL/Services allows programs invoked on various
remote computers running the Macintosh, MS-DOS, OS/2,
ULTRIX, ULTRIX for RISC, or VMS operating systems to
access Rdb/VMS as well as other databases supported by
SQL on a VMS server system.
o VAX Rdb/VMS SQL Reference Manual
Provides reference material and a complete description
of the statements, the interactive, dynamic, and
module language interfaces, and the syntax for SQL,
the structured query language interface for Rdb/VMS.
o VAX Rdb/VMS SQL Quick Reference Guide
Summarizes the information in the VAX Rdb/VMS SQL
Reference Manual.
o VAX Rdb/VMS RDO and RMU Reference Manual
Provides reference material and a complete description
of the statements and syntax of the Rdb/VMS Relational
Database Operator (RDO) interface and the commands of
the Rdb/VMS Management Utility (RMU).
o RDML Reference Manual
Describes the syntax and use of the Relational Data
Manipulation Language (RDML), which can be embedded
in VAX C or VAX Pascal programs to access Rdb/VMS or
Rdb/ELN databases.
o VAX Rdb/VMS Installation Guide
Describes how to install Rdb/VMS.
o VAX Rdb/VMS Release Notes
xii
Describes new features, problems and problems fixed,
restrictions, and other information related to Rdb/VMS
Version 4.0. Contains information about SQL and other
Rdb/VMS interfaces and utilities.
o Mandatory Update for VAX Rdb/VMS Versions 3.1B and 4.0
Contains the installation verification prodecure (IVP)
for installing updated images and the VAX Rdb/VMS
release notes that describe the problems fixed in
these images, additional known problems not fixed, and
additional restrictions for VAX Rdb/VMS Version 3.1C and
Version 4.0A.
Conventions
In examples, an implied carriage return occurs at the end
of each line, unless otherwise noted. You must press the
Return key at the end of a line of input.
Often in examples the prompts are not shown. Generally,
they are shown where it is important to depict an
interactive sequence exactly; otherwise, they are omitted
in order to focus full attention on the statements or
commands themselves.
This section explains the conventions used in this manual:
<Ctrl/x> This symbol in examples tells you to press
the Ctrl (control) key and hold it down while
pressing the specified letter key.
<Return> This symbol in examples indicates the Return key.
<Tab> This symbol in examples indicates the Tab key.
Vertical ellipsis points in an example mean that
. information not directly related to the example
. has been omitted.
.
xiii
. . . Horizontal ellipsis points in statements or
commands mean that parts of the statement or
command not directly related to the example have
been omitted.
< > Angle brackets enclose user-supplied names.
[ ] Brackets enclose optional clauses from which you
can choose one or none.
$ The dollar sign represents the DIGITAL Command
Language prompt. This symbol indicates that the
DCL interpreter is ready for input.
x A lowercase italic x indicates the generic use of
a letter. For example, Version 3.0x refers to any
released letter version of the specified number
version, such as V3.0A.
n A lowercase italic n indicates the generic use of
a number. For example, Version 2.n refers to any
released version of the specified number version,
such as V2.3.
References to Products
The Rdb/VMS documentation to which this document belongs
often refers to products by their abbreviated names:
o DECdecision software is referred to as DECdecision.
o DEC RdbExpert for VMS software is referred to as
RdbExpert.
o DECtrace for VMS software is referred to as DECtrace.
o VAX ACMS software is referred to as ACMS.
o VAX Ada software is referred to as Ada.
o VAX BASIC software is referred to as BASIC.
o VAX C software is referred to as C.
o VAX CDD/Plus software is referred to as CDD/Plus, the
data dictionary, or the dictionary.
xiv
o VAX COBOL software is referred to as COBOL.
o VAX Data Distributor software is referred to as Data
Distributor.
o VAX DATATRIEVE software is referred to as DATATRIEVE.
o VAX DBMS software is referred to as VAX DBMS.
o VAX FORTRAN software is referred to as FORTRAN.
o VAXELN Pascal and VAX Pascal are both referred to
as Pascal except when the use of a Relational Data
Manipulation Language (RDML) statement is not the same
in the VAXELN and VMS environments. In the latter case,
either VAXELN Pascal or VAX Pascal is specified.
o VAX PL/I software is referred to as PL/I.
o VAX RALLY software is referred to as RALLY.
o VAX Rdb/ELN software is referred to as Rdb/ELN.
o VAX Rdb/VMS software is referred to as Rdb/VMS. VAX
Rdb/VMS software Versions 3.1, 3.1A, 3.1B, and 3.1C
are often referred to as V3.1, V3.1A, V3.1B, and V3.1C,
respectively. Similarly, VAX Rdb/VMS software Versions
4.0, 4.0A, and 4.0B are often referred to as V4.0,
V4.0A, and V4.0B.
o VAX SQL software is referred to as VAX SQL whenever it
is correct to refer to Version 2.0 or earlier of SQL.
The use of SQL by itself indicates the SQL interface
included as part of VAX Rdb/VMS since Version 3.0.
o VAX TEAMDATA software is referred to as TEAMDATA.
o VAX TDMS software is referred to as TDMS.
o VIDA software is referred to as VIDA.
xv
1
_________________________________________________________________
Software Problems Fixed in Rdb/VMS V4.0B
The following sections describe problems with previous
versions of the Rdb/VMS software that are fixed in Version
4.0B. These software problems no longer exist.
1.1 General Information
This section contains notes and problem descriptions of a
general nature.
1.1.1 Privileges Required to Execute the RMU/DUMP, RMU/OPEN, and
RMU/CLOSE Commands
There has been some confusion regarding privilege
requirements when installing an RMU image. The following
list shows when the RMU/DUMP, RMU/OPEN, and RMU/CLOSE
commands are permitted:
o If you have SYSPRV, you can execute the RMU/DUMP,
RMU/OPEN, and RMU/CLOSE commands regardless of the
installed privilege of the RMU image.
o If you do not have SYSPRV but do have DBADMN, you can
execute the RMU/DUMP, RMU/OPEN, and RMU/CLOSE commands
if the RMU image is installed with SYSPRV.
o If you do not have SYSPRV but do have DBADMN and the RMU
image is not installed with SYSPRV, you can execute the
RMU/DUMP, RMU/OPEN, and RMU/CLOSE commands if you have
VMS read access to the database files.
o If you do not have SYSPRV or DBADMN, you cannot execute
the RMU/DUMP, RMU/OPEN, and RMU/CLOSE commands even if
the RMU image is installed with SYSPRV.
o If there is a problem with the database, such as a
corruption or journaling failure, VMS SYSPRV is required
if RMU is unable to access the database to determine
whether you have DBADMN privilege for the database.
Software Problems Fixed in Rdb/VMS V4.0B 1-1
1.2 Software Problems Fixed That Apply to All Interfaces of
Rdb/VMS V4.0B
This section contains notes and problems fixed in all
interfaces.
1.2.1 Total Relation Boolean Was Not Generated Properly in a Leaf
Strategy
When you used a Leaf strategy and when one or more
background indexes contained key-only booleans that you
were evaluating, the "total" relation boolean was not
generated properly because a portion of the expression
was already marked as used.
This problem is fixed in Rdb/VMS V4.0B.
1.2.2 ALTER STORAGE MAP Statement Caused Rdb/VMS to Bugcheck When
Combined with Disabling Compression
There was a problem with the ALTER STORAGE MAP statement
in Rdb/VMS V4.0A. Specifying a combination of altering the
storage map for a table to use a different storage area and
disabling compression would cause Rdb/VMS to bugcheck. This
was due to an improper copy of storage map information from
the old table definition to the new table definition prior
to the data decompression.
For example, the following sequence of SQL statements would
lead to a bugcheck when the ALTER STORAGE MAP statement was
executed:
SQL> ALTER SCHEMA FILENAME MF_PERSONNEL;
SQL> ADD STORAGE AREA TEST FILENAME TEST PAGE FORMAT IS MIXED;
SQL> DECLARE SCHEMA FILENAME MF_PERSONNEL;
SQL> CREATE UNIQUE INDEX DI ON DEPARTMENTS (DEPARTMENT_CODE)
cont> TYPE IS HASHED
cont> STORE IN TEST;
SQL> ALTER STORAGE MAP DEPARTMENTS_MAP
cont> PLACEMENT VIA INDEX DI STORE IN TEST
cont> DISABLE COMPRESSION;
This problem is fixed in Rdb/VMS V4.0B.
1-2 Software Problems Fixed in Rdb/VMS V4.0B
1.2.3 SQL or RDO Hung During INTEGRATE Operation
When using Rdb/VMS V4.0, or V4.0A and CDD/Plus V4.3 or
CDD/Repository V5.0, it was possible for Rdb/VMS to go into
an infinite loop during an INTEGRATE operation. Typing Ctrl
/Y to stop the loop did not work.
This occurred because incorrect information about index
column attributes was supplied by the data dictionary
during the INTEGRATE operation. When an index column needed
to be changed and the MAPPING VALUES or SIZE IS clauses
were used on an index definition, it was possible for the
data dictionary to delete the index and redefine it during
the INTEGRATE operation. During the redefinition, the data
dictionary supplied incorrect definitions to Rdb/VMS and an
infinite loop resulted.
The circumstances that cause this problem are very unusual.
This problem was visible only if you used the MAPPING
VALUES or SIZE IS attributes on an index definition and
made changes to the columns referenced by that index.
This problem is fixed in Rdb/VMS V4.0B. Rdb/VMS now detects
and reports the illegal attributes generated by the data
dictionary. A future version of CDD/Repository will correct
the attribute generation for the SIZE IS and MAPPING VALUES
clauses.
If you cannot install Rdb/VMS V4.0B immediately, a
workaround to this problem is to delete any indexes
containing these attributes before the INTEGRATE operation
and redefine them later using SQL.
1.2.4 Optimizer Did Not Recognize That an Index Segment Was
Compressed
Rdb/VMS V4.0 did not recognize that an index segment was
compressed. When ordering was requested on a column that
had compression enabled in the index and that column
was not the first segment of the index, the optimizer
incorrectly chose the index to return records in the sorted
order of the compressed segment. All requested records were
returned, but the order may have been partially wrong.
This problem is fixed in Rdb/VMS V4.0B.
Software Problems Fixed in Rdb/VMS V4.0B 1-3
1.2.5 Defining a Remote Logical Name Denied Access to the Local
Node
If you defined a system logical for a database file on
a remote node, the local node was not able to access
the database remotely. For example, if you defined the
following logical name on remote node A:
$ DEFINE/SYSTEM DB DISK1:[DIR1]RDB_DATABASE
Then typed the following at the local node:
RDO> DATA FILE A::DB
You received the following error:
%RDB-E-BAD_DB_FORMAT, DB.RDB; does not reference a database known to Rdb
-RMS-E-FNF, file not found
The workaround to this problem is to type the following at
the local node:
RDO> DATA FILE A::DB:
This problem is fixed in Rdb/VMS V4.0B.
1.2.6 Transfer of Large Blocks of Data over the Network Resulted
in an Error
When large blocks of data (greater than 2000 bytes) were
transferred over the network, it was possible to get the
following error:
%RDB-F-BUG_CHECK_CALL, internal consistency check failed
%RDB-F-IO_ERROR, input or output error
-SYSTEM-F-LINKABORT, network partner aborted logical link
The workaround is to define the RDB$REMOTE_BUFFER_SIZE
logical name to a number larger than the maximum bytes
for the data transfer. This workaround only works for
machines that can accommodate the memory size specified
by the logical name.
This problem is fixed in Rdb/VMS V4.0B.
1-4 Software Problems Fixed in Rdb/VMS V4.0B
1.2.7 COBOL Lines Generated That Did Not Comply with the ANSI
Standards
While precompiling a COBOL program with the /ANSI
qualifier, it was possible to generate COBOL lines that
did not comply with the ANSI standards. The problem was
most likely to occur while expanding structure references.
This problem is fixed in Rdb/VMS V4.0B.
1.2.8 Optimization of Constraint Processing Was Limited
Rdb/VMS V4.0 incorrectly limited the optimization of
constraint processing when null equality checking was
carried out within the context of a constraint record
selection expression.
This problem is fixed in Rdb/VMS V4.0B. Rdb/VMS now
recognizes NULL equalities within constraint record
selection expressions as similar to any other equality
and optimizes the constraint accordingly.
1.2.9 NOWAIT Transactions Started During a Recovery Process
Caused an RDMS-F-AREABUSY Fatal Error
The following messages resulted after repeated attempts to
start a NOWAIT transaction:
%RDB-E-LOCK_CONFLICT, request failed due to locked resource;
no-wait parameter specified for transaction
-RDMS-F-AREABUSY, usage of storage area <rdb$system>
conflicts with a co-user
This problem generally occurred after a recovery process
had been started to roll back a terminated process. The
user process that attempted to start the NOWAIT transaction
gave up the freeze lock because of the recovery process. As
part of the execution of the start transaction statement,
Rdb/VMS attempted to access the RDB$SYSTEM storage area and
in doing so, attempted to regain the freeze lock when the
recovery was done. Rdb/VMS could not regain the freeze lock
due to a problem, and so returned an error indicating that
it could not access the RDB$SYSTEM storage area.
Software Problems Fixed in Rdb/VMS V4.0B 1-5
You can reproduce this problem on the PERSONNEL database
by using four processes. Three processes are used to update
the database, and the fourth process is used to stop the
job. The function of each process and its time sequence is
as follows:
(1) Process A: START_TRANSACTION READ_WRITE NOWAIT
(2) Process B: START_TRANSACTION READ_WRITE NOWAIT
(3) Process A: STORE C IN CANDIDATES USING C.LAST_NAME="A" END_STORE
COMMIT
(4) Process B: STORE C IN CANDIDATES USING C.LAST_NAME="B" END_STORE
(5) Process C: START_TRANSACTION READ_WRITE NOWAIT
STORE C IN CANDIDATES ...
(6) Process D: STOP/PROC/ID=PROCESS C
**** Wait for recovery to complete (pause for a minute) ****
(7) Process A: START_TRANSACTION READ_WRITE NOWAIT
The user process did not regain the freeze lock due to a
problem in the Rdb/VMS software.
A workaround is to start a WAIT transaction or detach from
the database with a FINISH statement.
This problem was documented as fixed in V4.0A when, in
fact, it reappeared in V4.0A due to an interaction between
patches.
This problem is fixed in Rdb/VMS V4.0B.
1.2.10 DACCESS Audit Event Required a Minimal Set of Privileges
for Auditing to Occur
In Rdb/VMS V4.0, it was necessary to enable one of the
privileges (SELECT, SUCCESS, or FAILURE) using the RMU/SET
AUDIT command to get any DACCESS security auditing to occur
for an object. If one of these privileges was not enabled
for an object being audited, no security auditing would
occur for that object.
This problem is fixed in Rdb/VMS V4.0B. In Rdb/VMS V4.0B,
it is necessary to enable only those privileges that are
desired for security auditing of an object.
1-6 Software Problems Fixed in Rdb/VMS V4.0B
1.2.11 UPDATE Privilege Access for Table with DACCESS Audit Event
Was Not Captured
In Rdb/VMS V4.0, the security auditing facility did not
log attempted UPDATE access to a table when the UPDATE
privilege was enabled for the DACCESS audit event. However,
security auditing of UPDATE access to columns within a
table always worked correctly.
This problem is fixed in Rdb/VMS V4.0B. UPDATE privilege
auditing for the DACCESS audit event for a table now occurs
correctly.
1.2.12 Virtual Memory Increased with Some Fourth Generation
Languages
With some fourth generation languages (4GLs), virtual
memory increased by approximately 64 pages for each
modification made in a multifile database where the
modified relation had indexes with a STORE clause and
constraint.
This problem is fixed in Rdb/VMS V4.0B. Some minor memory
problems still exist when you use the RDO and SQL user
interfaces. These will be fixed in Rdb/VMS V4.1. These
problems do not appear when you use any of the precompilers
or the module level language.
1.2.13 Collating Sequence Problems
There were several problems related to collating sequences
in V4.0 and V4.0A. The following list describes the current
behavior:
o Multisegment indexes in which one or more of the
segments was a field with a collating sequence are no
longer a problem in Rdb/VMS V4.0B.
o If the user uses the collating sequence multinational_2
or multinational_1, Rdb/VMS V4.0B no longer bugchecks.
o The predicate STARTING WITH "" not retrieving the proper
record stream is no longer a problem in Rdb/VMS V4.0B.
Support has been added for the Thai collating sequence in
Rdb/VMS V4.0B.
Software Problems Fixed in Rdb/VMS V4.0B 1-7
1.2.14 Improper Error Displayed When Exporting and Importing to
Use a Different Collating Sequence
The following example shows a database created with a
collating sequence and then exported and imported to use
a different collating sequence:
RDO> DEFINE DATABASE FOO COLLATING_SEQUENCE GERMAN GERMAN.
RDO> EXPORT FOO FOO
RDO> IMPORT FOO BAR COLLATING_SEQUENCE DANISH DANISH.
In earlier versions of Rdb/VMS, the following message was
improperly returned:
Database collating sequence was !AC, now is !AC
Rdb/VMS V4.0B corrects this deficiency and returns the
following message:
Database collating sequence was GERMAN , now is DANISH
Rdb/VMS V4.1 will address the problem of the excess spaces
between the text of the first collating sequence name and
the comma.
1.2.15 Multisegmented Index Was Not Selected When a Not-Equal
Predicate Was Specified
A query that used the not-equal predicate referring to a
column within the most selective index caused the query
optimizer to chose a different index. When more than one
useful multisegmented index existed, the query optimizer
chose a less selective index. This occurred when the more
selective index had a not-equal (<>) predicate on its
nonfirst segment. This problem does not apply to hashed
indexes.
For example, assume MY_TABLE had columns A, B, C, D, E,
and F with two 3-segment sorted indexes: INDEX_A_B_C on
columns A, B, C and INDEX_A_D_E on columns A, D, E. For
the following query, a less selective index INDEX_A_D_E is
used:
1-8 Software Problems Fixed in Rdb/VMS V4.0B
SQL> SELECT * FROM MY_TABLE
cont> WHERE A = 'A' AND B = 'B' AND C <> 'C';
Leaf#01 FFirst MY_TABLE Card=100
BgrNdx1 INDEX_A_D_E [1:1]
Although the index INDEX_A_B_C was a better index, it was
not used because a not-equal predicate (C <> 'C') appeared
on the third segment of this index.
This problem is fixed in Rdb/VMS V4.0B.
If you cannot install Rdb/VMS V4.0B immediately, a
workaround to this problem is to modify the query to
replace the not-equal predicate with a Boolean expression.
For example, in the previous query, the expression AND C <>
'C' can be replaced with AND ((C < 'C') OR (C > 'C')).
1.2.16 Privilege Violation in Batch-Update Caused Database
Corruption
When a user without privileges tried to delete an index in
a batch-update transaction, the database was corrupted.
This problem is fixed in Rdb/VMS V4.0B.
1.2.17 A Join Query Matched a Null Aggregate or Expression to a
Column with Zeros or Blanks and Produced Incorrect Results
In Rdb/VMS Version 4.0 and earlier, a join query matching
an aggregate or an expression to a table column produced
incorrect results when the aggregate or expression was null
and the table column contained either a zero or blanks. The
result of matching a null to zero or blanks should produce
an "unknown" truth value and, therefore, no joined result
should be produced. Due to a problem, Rdb/VMS successfully
matched a null to a zero or blanks and produced joined
results.
This problem only occurred if a cross join strategy was
used for the join query, and an index was used to fetch
table column values. In all other cases, null values were
properly evaluated as not equal to zero or blank values.
This problem is fixed in Rdb/VMS V4.0B.
Software Problems Fixed in Rdb/VMS V4.0B 1-9
1.2.18 Bugcheck Occurred with an Exception at
RDMS$$RSS$ASN_FOR_RSS$NDX
During the processing of a query similar to the following
example, Rdb/VMS bugchecked with an exception:
SQL> CREATE INDEX IND1 ON TAB1
cont> (FLD1, FLD2) TYPE IS SORTED;
SQL> SELECT A.FLD1 FROM TAB1 A, TAB2 B, TAB3 C
cont> WHERE
cont> A.FLD2 = "B" AND
cont> A.FLD1 = B.FLD1
cont> OR
cont> A.FLD2 = "C" AND
cont> A.FLD1 = C.FLD1;
*****Exception at RDMS$$RSS$ASN_FOR_RSS$NDX
If an index was not defined, the query executed correctly.
This problem also occurred during the definition of a view
with a similar select clause.
This problem is fixed in Rdb/VMS V4.0B.
If you cannot install Rdb/VMS V4.0B immediately, a
workaround to this problem is to use a correct existential
expression to determine the presence of a matching record,
as shown in the following example:
SQL> SELECT A.FLD1 FROM TAB1 A
cont> WHERE
cont> A.FLD2 = "B" AND
cont> EXISTS ( B.FLD1 FROM TAB2 B WHERE A.FLD1 = B.FLD1)
cont> OR
cont> A.FLD2 = "C" AND
cont> EXISTS ( C.FLD1 FROM TAB2 C WHERE A.FLD1 = C.FLD1);
1.2.19 Incorrect Results Returned on Join Operations Using
Partitioned Indexes
Rdb/VMS sometimes returned incorrect results for a join
operation on a table with a partitioned index if the
following conditions were met:
o A column that was used to specify the limits for
partitioning was used to join the table.
1-10 Software Problems Fixed in Rdb/VMS V4.0B
o The same column was contained in a Boolean expression
that compared the column to a literal value.
This problem is fixed in Rdb/VMS V4.0B.
1.2.20 Arithmetic Exception Resulted When Joining Integer Columns
If you performed a join operation using integer columns of
different sizes, Rdb/VMS reported the following error:
%RDB-E-ARITH_EXCEPT, truncation of a numeric value at runtime
-SYSTEM-F-INTOVF, arithmetic trap, integer overflow at
PC=xxxxxxxx, PSL=01C00
This problem occurred only when each of the joined columns
was part of an index, and when the columns contained
values larger than 255. For instance, both of the following
examples could exhibit this problem:
SQL> SELECT Q.QUAD1, I.INT1 FROM QUADWORD_TABLE Q,
cont> INTEGER_TABLE I
cont> WHERE Q.QUAD1 = I.INT1;
SQL>
SQL> SELECT I.INT1, S.SMALL1 FROM INTEGER_TABLE I,
cont> SMALLINT_TABLE S
cont> WHERE I.INT1 = S.SMALL1;
This problem is fixed in Rdb/VMS V4.0B.
If you cannot install Rdb/VMS V4.0B immediately, a
workaround to this problem is to redefine the smaller field
to be the same size as the larger field. You must drop any
indexes and redefine them after you alter the column, as
shown in the following example:
SQL> DROP INDEX INTEGER_TABLE_INDEX;
SQL> ALTER TABLE INTEGER_TABLE ALTER INT1 QUADWORD;
SQL> CREATE INDEX INTEGER_TABLE_INDEX ON INTEGER_TABLE (INT1);
SQL> COMMIT;
1.2.21 Query with Computed-By Field and OR Returned Incorrect
Results
A query with computed-by and OR returned incorrect results
as shown in the following example. Assume that the yyyymm
field is a computed-by field.
RDO> FOR R IN R2 WITH (R.M_OVED="0023" AND R.YYYYMM="199101") OR
cont> (R.M_KARTIS="0018" AND R.YYYYMM >= "199101")
cont> PRINT R.* END-F
This problem is fixed in Rdb/VMS V4.0B.
Software Problems Fixed in Rdb/VMS V4.0B 1-11
1.2.22 CHANGE DATABASE Statement Resulted in Bad Parameter Error
Message
Using the CHANGE DATABASE statement (or ALTER SCHEMA
statement in SQL) to add or drop storage areas resulted
in RDMS-F-BADPARAM error messages. This usually occurred
when the number of storage areas involved (both existing
and to be added) was approximately 64.
This problem was caused by the improper initialization
of a data structure when more than 64 storage areas were
involved.
This problem is fixed in Rdb/VMS V4.0B.
1.2.23 Defining a Partitioned Hashed Index Resulted in Corruption
Suppose you have a storage area A, that has at least one
table stored in it. If you define a hashed index H so
that one of its partitions is stored in A, H could become
corrupt when it is created.
To determine if an existing database has corrupt hashed
indexes of this form, perform the following SQL query on
the database:
SQL> SELECT SMA1.RDBVMS$MAP_NAME, SMA1.RDBVMS$AREA_NAME
cont> FROM RDBVMS$STORAGE_MAP_AREAS SMA1,
cont> RDBVMS$STORAGE_MAP_AREAS SMA2
cont> WHERE SMA1.RDB$STORAGE_ID <> 0
cont> AND SMA1.RDB$INDEX_ID <> 0
cont> AND SMA1.RDB$STORAGE_ID = SMA2.RDB$STORAGE_ID
cont> AND SMA2.RDB$INDEX_ID = 0;
If no rows are selected, there are no corrupt hashed
indexes of this form. Otherwise, a selected row represents
a corrupt hashed index of this form. The SMA1.RDBVMS$MAP_
NAME field indicates the name of the corrupt hashed
index while the SMA1.RDBVMS$AREA_NAME field indicates a
particular partition of the index.
This problem is fixed in Rdb/VMS V4.0B. An export/import to
V4.0B removes the corruption.
In Rdb/VMS V4.1, an RMU/VERIFY/INDEXES=*/LOG will detect
this type of hashed index corruption. A SYSRECHKY error
indicates a corruption of this type.
1-12 Software Problems Fixed in Rdb/VMS V4.0B
1.2.24 Change in Operation of Index Deletion
In Rdb/VMS V4.0B, the action of an SQL DROP INDEX statement
(or an RDO DELETE INDEX statement) has been optimized in
the following cases:
1. If a sorted index has a storage map (that is, a STORE
clause), then each index (or each partition of each
index) is allocated a unique logical area. If the index
is stored in areas with uniform page format, Rdb/VMS
optimizes the index deletion by marking the logical
area as deleted. In this way, Rdb/VMS reuses the space
without having to scan the storage area and remove each
index node.
In previous versions, Rdb/VMS always scanned the uniform
area and erased each index node, usually an expensive
I/O operation. The behavior in V4.0B enables much faster
index deletion for this class of indexes.
2. If a sorted index does not have a storage map, it is
mapped automatically to RDB$SYSTEM storage area. All
indexes created in this way for a table share a single
logical area. Therefore, it is only the final index
deletion that can be optimized as previously described.
For example, consider three indexes defined without
storage maps for EMPLOYEES: EMP_INDEX1, EMP_INDEX2, and
EMP_INDEX3. A DROP INDEX EMP_INDEX1 statement erases
all index nodes for EMP_INDEX1, a DROP INDEX EMP_INDEX2
statement erases all index nodes for EMP_INDEX2, and
finally a DROP INDEX EMP_INDEX3 statement simply marks
the logical area as deleted.
In previous versions, Rdb/VMS would not perform
this optimization in all cases. Rdb/VMS performed
optimization only if all indexes for a table defaulted
to RDB$SYSTEM. If just one index was created for a table
that had a storage map, then a full index scan would be
used for each index deletion for the table.
This behavior is corrected in Rdb/VMS V4.0B.
________________________ Note ________________________
The sharing of logical areas is maintained for upward
compatibility with older versions of Rdb/VMS in which
single file databases did not have storage maps for
Software Problems Fixed in Rdb/VMS V4.0B 1-13
indexes. Digital recommends that storage maps be used
with all indexes so that the delete behavior described
in this section can be achieved for all sorted indexes
in uniform areas.
______________________________________________________
For any index stored in a mixed area, Rdb/VMS must scan
each area and delete the index nodes (SORTED) or hash
buckets (HASHED) as components of these indexes are mixed
with records from other tables and indexes. Therefore, no
optimization is possible in these cases.
1.2.25 Rdb/VMS Monitor Failed When the Last User Finished on a
Particular Database
If the Rdb/VMS monitor process, RDMMON, failed when the
last user finished from a database, an abbreviated bugcheck
was written to the monitor log file. The exception was one
of the following:
MON$UNLOCK_MPLL + 00000031
or
MON$UNLOCK_MPLL + 00000036
or
MON$UNLOCK_MPLL + 00000049
The secondary error message was either a SYSTEM-F-ACCVIO or
SYS$SYSTEM-F-INVLOCKID.
This exception was caused by the way Rdb/VMS allocated
virtual memory. Customers who saw this problem generally
had storage areas (live and snapshot) that numbered in the
hundreds (the number varied from database to database).
This problem did not cause a database to become corrupt.
This problem is fixed in Rdb/VMS V4.0B.
1.2.26 Comparing Integer and Text Fields Caused Problems
Rdb/VMS V4.0 did not tolerate using a text field with
leading zeros for qualification against a numeric field
in the database in a program. Although this was not good
coding practice, Rdb/VMS returned a 'data not found'
message rather than a message indicating that the syntax
was unacceptable.
1-14 Software Problems Fixed in Rdb/VMS V4.0B
In addition, in interactive SQL an informational message
displayed whenever an integer-to-text conversion was
carried out during comparisons:
SQL> SELECT * FROM EXTRACT_SERIAL WHERE
cont> X_SER_INDEX_NO = '0328913';
%SQL-I-NUMCMPTXT, Numeric column will be compared with string
literal as text
This problem is fixed in Rdb/VMS V4.0B.
1.3 SQL Problems Fixed in Rdb/VMS V4.0B
This section contains notes and problems fixed in the SQL
interface.
1.3.1 REORGANIZE Clause Caused a Bugcheck
After moving data from a mixed formatted area to a
uniform area utilizing the ALTER STORAGE MAP statement
and REORGANIZE clause, an attempt to drop a hashed index
that remained in the mixed area produced a bugcheck.
This problem is fixed in Rdb/VMS V4.0B.
1.3.2 Updating the Cardinality of a Relation Caused a Bugcheck
The following query for updating the cardinality of a
relation caused a bugcheck:
SQL> UPDATE RDB$RELATIONS SET RDB$CARDINALITY = 65535
cont> WHERE RDB$RELATION_NAME = "T1";
This problem is fixed in Rdb/VMS V4.0B.
1.3.3 Memory Lost Between Database Attaches
A problem in dynamic SQL caused memory to be lost
between database attaches. This problem also showed up
in SQL/Services because many attaches were performed by a
single server.
This problem is fixed in Rdb/VMS V4.0B.
Software Problems Fixed in Rdb/VMS V4.0B 1-15
1.3.4 Incorrect Conversion of Numeric Data Types Caused Erroneous
Values for Scales
In PL/I, numeric data types were incorrectly converted,
which caused erroneous values for scales.
This problem is fixed in Rdb/VMS V4.0B.
1.3.5 Using the IGNORE CASE Option of the LIKE Clause Sometimes
Resulted in a Query That Incorrectly Returned No Rows
In certain SELECT statements in SQL, the LIKE clause worked
correctly unless the IGNORE CASE option was added to it.
The IGNORE CASE option caused the query to return no rows.
This seemed to occur when the WHERE clause involved more
than one condition connected with an AND Boolean operator.
The following command procedure illustrates this problem.
The first SELECT statement correctly returns the inserted
record. Adding an IGNORE CASE option to one of the items in
the WHERE clause results in the return of no rows. Adding
another IGNORE CASE option to a different item in the WHERE
clause seems to fix the problem.
SQL> CREATE SCHEMA FILE MF_PERSONNEL;
SQL> CREATE TABLE XXX (F1 CHAR(5), F2 CHAR(3), F3 CHAR(3));
SQL> INSERT INTO XXX (F1, F2, F3) VALUES ("ABC", "ABC", "ABC");
1 row inserted
SQL> SELECT * FROM XXX WHERE
cont> F1 LIKE "AB%" AND
cont> F2 LIKE "ABC" AND
cont> F3 LIKE "ABC";
F1 F2 F3
ABC ABC ABC
1 row selected
SQL> SELECT * FROM XXX WHERE
cont> F1 LIKE "AB%" AND
cont> F2 LIKE "ABC" IGNORE CASE AND
cont> F3 LIKE "ABC";
0 rows selected
SQL> SELECT * FROM XXX WHERE
cont> F1 LIKE "AB%" AND
cont> F2 LIKE "ABC" IGNORE CASE AND
cont> F3 LIKE "ABC" IGNORE CASE;
F1 F2 F3
ABC ABC ABC
1-16 Software Problems Fixed in Rdb/VMS V4.0B
1 row selected
This problem is fixed in Rdb/VMS V4.0B.
1.3.6 Record Parameters Could Not Be Used Where Values Were
Expected
Attempting to compile a module resulted in the following
error, without a bugcheck, when a parameter name was used
that was the same as a column, domain, and field, and the
field was referenced in the WHERE clause:
%SQL-F-BUGCHK, There has been a fatal error. Please submit an SPR.
Record parameters cannot be used where values are expected.
This was a problem in the SQL module processor. SQL$MOD
should have reported that the comparison of parameter with
column, domain, and field was illegal.
This problem is fixed in V4.0B, and errors now display
correctly.
1.3.7 Certain Trigger Definitions Caused a Bugcheck
Under certain circumstances, a user error in a trigger
definition caused SQL to bugcheck as in the following
example:
! CREATE THE DATABASE
SQL> CREATE SCHEMA FILENAME TEST;
SQL> CREATE TABLE T1 (NODE CHAR(10),
cont> NEXT CHAR(10),
cont> PRIOR CHAR(10)
cont> );
SQL> COMMIT;
SQL> CREATE TRIGGER DELETE_FROM_LIST
cont> AFTER INSERT ON T1
cont> (UPDATE T1 DELETED_RECORD
cont> SET PRIOR = T1.PRIOR,
cont> T1.NEXT = "1"
cont> WHERE DELETED_RECORD.PRIOR = T1.NODE
cont> )
cont> FOR EACH ROW;
%SQL-F-BUGCHK, There has been a fatal error. Please submit an
SPR. No dump was produced.
Software Problems Fixed in Rdb/VMS V4.0B 1-17
The user error is in the UPDATE statement. Only the table
named in the UPDATE statement, with its correlation name,
can be updated in the SET clause. In this particular case,
because the correlation name DELETED_RECORD is defined for
the table being updated, it is the only qualifier that can
be used on the left-hand side of assignments in the SET
clause. The illegal left-hand side is T1.NEXT. The column
qualifier T1 is not allowed in this context because it
is not the defined correlation name for the table being
updated.
This problem is fixed in Rdb/VMS V4.0B. An appropriate
error message is now generated instead of a bugcheck when a
user error occurs.
1.3.8 SQLTYPE Value Fixed in the SQLDA
For TINYINT columns, dynamic SQL returned an incorrect
value in the SQLTYPE field of the SQLDA.
This problem is fixed in Rdb/VMS V4.0B.
1.3.9 Bugcheck Returned by System When User with Incorrect
Privileges Showed Protection on a Schema
The system returned a bugcheck when a user, running with
SYSPRV and no matching ACL, tried to show protection on a
schema.
This problem is fixed in Rdb/VMS V4.0B. An error message is
now generated when this situation is detected.
1.3.10 SQL Incompatibilities in Rdb/VMS V4.0 That Are Fixed in
Rdb/VMS V4.0B
This section describes incompatibilities in V4.0 with
object modules and cursors.
1.3.10.1 Incompatibilities Between Object Modules
Incompatibilities between object modules occurred in
Rdb/VMS V4.0A and previous versions of Rdb/VMS. If
you relinked an application with V3.1B object modules
(especially ones with cursors), you received error
messages. For example, you might have received the
following SQLCODE -1005 message:
%RDB-E-BAD_TRANS_HANDL, invalid transaction handle
1-18 Software Problems Fixed in Rdb/VMS V4.0B
These incompatibilities are addressed in Rdb/VMS V4.0B. The
current status is as follows:
o V4.0 and V4.0A object modules (.OBJ) are compatible
with each other, but not compatible with object modules
compiled with any other version of SQL.
o Executable images (.EXE) compiled using V3.1B (or
earlier) are compatible with all all versions of SQL.
Users who upgrade directly from V3.1B to V4.0B do not
have to recompile.
o V4.0 and V4.0A executable images are compatible with
each other, but not compatible with V4.0B and future
releases. Users with V4.0 or V4.0A object modules must
recompile those V4.0 or V4.0A modules prior to relinking
under V4.0B or later versions.
o V3.1B (and earlier) object modules are compatible with
V4.0B (and future release) object modules.
o When fixing a problem with null terminated strings in C
programs, an incompatibility was introduced.
A workaround is to use the following SQL$MOD qualifier:
/[NO]FIXED_CDD_STRINGS
This SQL$MOD qualifier is the same as the SQL$PRE
qualifier /SQLOPTIONS=[NO]FIXED_CDD_STRINGS.
These qualifiers set the default behavior for how text n
fields are interpreted from data dictionary records for
the C preprocessor. The default behavior is that a text
field is treated as a null terminated string of n-1 data
bytes and 1 null byte. The /FIXED_CDD_STRINGS qualifier
treats the field as n data bytes and no null byte.
In summary, if you are relinking and not recompiling under
V4.0 and V4.0A, you encounter errors.
The goal is to maintain compatibility between versions,
implying the following:
o Executable images from previous versions work in newer
versions.
o Object modules from previous versions can be linked with
newly compiled object modules.
Software Problems Fixed in Rdb/VMS V4.0B 1-19
1.3.10.2 Incompatibilities Between TABLE and LIST Cursors
When a TABLE cursor was closed, its LIST cursor was left
open. This problem is fixed in Rdb/VMS V4.0B. Now, LIST
cursors are implicitly closed when the TABLE cursor they
are defined on is closed.
1.3.10.3 Incompatibilities Between Cursors and COMMIT or ROLLBACK
Statements
When a COMMIT or ROLLBACK statement was issued, all cursors
were implicitly closed. This status was not preserved
by V4.0 and V4.0A when the cursors were in one image of
an application and the COMMIT or ROLLBACK operation was
executed in another, which occurred when an application was
divided into one or more VMS shared images.
To correct this problem, use Rdb/VMS V4.0B to recompile all
SQL modules in all images.
1.3.11 Message Vector Contained Erroneous Information About the
Number of Longwords Used
The message vector is used to communicate status between
SQL and the user. For errors related to an improper cursor
state, the message vector contained erroneous information
about the number of longwords used in the message vector.
The value was always one greater than the actual value.
________________________ Note ________________________
This was true for only a small number of error states
and did not represent a general problem.
______________________________________________________
This problem is fixed in Rdb/VMS V4.0B.
1.3.12 Common Data Dictionary (CDD/Plus) Fields with Scales Were
Not Always Properly Translated
Scale is an attribute of numeric data type fields. Scale
controls how you interpret the actual value that is stored
in the field.
Whenever a record in the Common Data Dictionary (CDD/Plus)
contained fields with scale attributes, it was ignored.
Therefore, not all of the information that the user
intended to store was stored. For example, if the user
1-20 Software Problems Fixed in Rdb/VMS V4.0B
wanted to store 233.22, this problem caused 233 to be
stored instead.
This problem is SQL specific and limited to SQL$PRE and
SQL$MOD. It is fixed in Rdb/VMS V4.0B.
1.3.13 UNION Queries Returned Incorrect Data on Numeric Data
Types
The statement SELECT COL1 FROM TBL1 UNION SELECT COL2 FROM
TBL2 did not return the correct data for numeric data types
because it incorrectly calculated the data type of the
union of COL1 and COL2.
This problem is fixed in Rdb/VMS V4.0B.
1.3.14 Modules That Used the DECLARE TRANSACTION Statement Were
Ignoring TXN Attributes
Modules that used the DECLARE TRANSACTION statement were
ignoring TXN attributes when the transaction was started.
This problem is fixed in Rdb/VMS V4.0B.
1.3.15 Embedded SQL Ada Programs Could Not Use LIST Cursors
Embedded SQL Ada programs could not use LIST cursors
because the precompiler incorrectly generated the Ada
parameter declarations.
This problem is fixed in Rdb/VMS V4.0B.
1.3.16 Views That Selected Dbkeys Caused a Bugcheck
The statement CREATE VIEW V1 AS SELECT DBKEY FROM TBL1
generated an SQL bugcheck in Rdb/VMS Versions 1.0 through
4.0A.
This problem is fixed in Rdb/VMS V4.0B.
1.3.17 Dynamic SQL Statements with Indicator Arrays Were Not
Correctly Handled Prior to Rdb/VMS V4.0B
Dynamic statements with indicator arrays were not correctly
handled prior to V4.0B. Specifically, if you had the
following procedure, the indicator array IND was read
incorrectly:
Software Problems Fixed in Rdb/VMS V4.0B 1-21
PROCEDURE EXECUTE
SQLCODE
FOO RECORD A CHAR (10), B CHAR(10) END RECORD
IND RECORD ARRAY OF 2 SMALLINT END RECORD;
EXECUTE USING FOO INDICATOR IND;
This problem is fixed in Rdb/VMS V4.0B.
1.3.18 SQL Allocated More Memory Than Necessary During a Dynamic
SET TRANSACTION Statement
During preparation of a dynamic SET TRANSACTION statement,
SQL allocated more memory than necessary and did not return
it to the system.
This problem is fixed in Rdb/VMS V4.0B.
1.3.19 Preparing a Statement with D-float Parameters Caused a
Bugcheck
Preparing a statement with D-float parameters, describing
it, and then describing it again caused SQL to bugcheck.
This problem is fixed in Rdb/VMS V4.0B.
1.4 SQL/Services Problems Fixed in Rdb/VMS V4.0B
This section contains notes and problems fixed in
SQL/Services.
1.4.1 Unpredictable Results Occurred When Trying to Store
Segmented Strings from the Macintosh Environment Using
DECnet
In Rdb/VMS V4.0, SQL/Services had unpredictable results
when trying to store segmented strings from the Macintosh
platform using the DECnet transport. Possible symptoms were
that the application hung or that the server received a
fatal error. However, symptoms were not limited to these
two types.
This problem is fixed in Rdb/VMS V4.0B.
1-22 Software Problems Fixed in Rdb/VMS V4.0B
1.4.2 Certain Calls to the sqlsrv_fetch_many Routine Caused
Problems
The following problems with the sqlsrv_fetch_many routine
are fixed in Rdb/VMS V4.0B:
o In previous versions of SQL/Services, some calls to the
sqlsrv_fetch_many routine failed with a -2007 error when
fetching a large number of rows.
o The sqlsrv_fetch_many routine also returned a status
code of "1" instead of SQL_EOS (100) in some instances
when the fetch operation was complete.
o Other invalid sqlsrv_fetch_many routine error messages
were returned because internal error buffers were not
reset properly. For example, -1007 is an invalid error
code that was returned by SQL/Services, although it is
not a valid SQL or SQL/Services code.
o In previous versions of SQL/Services, a problem occurred
on the Macintosh platform when the sqlsrv_fetch_many
routine was used. One symptom was that the Macintosh
would crash with a "bus error". This problem occurred
because of a memory pointer that was incorrectly
maintained.
1.4.3 Authorization Failure Occurred When SYSUAF Flag LOCKPWD Was
Set
Before Rdb/VMS V4.0B, execute server accounts required that
the SYSUAF flag LOCKPWD be clear for the server to operate.
If the flag was set, the server returned an authorization
failure to the client application.
This problem is fixed in Rdb/VMS V4.0B and the flag can
either be set (LOCKPWD) or clear (NOLOCKPWD) in SYSUAF.DAT.
1.4.4 Column Limit Raised to 500
The previous SQL/Services limit of 100 columns per table
has been raised to 500 in Rdb/VMS V4.0B.
Software Problems Fixed in Rdb/VMS V4.0B 1-23
1.4.5 SQL/Services Failure Did Not Produce a Bugcheck File
SQL/Services now produces a bugcheck file much like other
Rdb/VMS components.
In an SQL/Services failure, the system writes the bugcheck
file to SYS$LOGIN:SQLSRV$BUGCHECK.DMP.
The SYS$LOGIN logical is defined differently based on the
SQL/Services image and the status of the connection. To
direct all SQL/Services bugchecks, assign the following
logical to a directory that can be written to by the world:
$ DEFINE/SYSTEM SQLSRV$BUGCHECK dev:[dir]
Please provide the process logs and the bugcheck file when
you report a problem with SQL/Services.
1.4.6 VMS Application Programming Interface (API) Installation
Failed Without Rdb/VMS
In Rdb/VMS V4.0, the VMS Application Programming Interface
(API) Installation Verification Procedure (IVP) failed
when building the SQL/Services IVP executables because
the linking operation could not find the SQL$INT.EXE and
RDBSHR.EXE images.
In the mandatory update for V4.0, you could correct this
problem by copying both the SQL$INT.EXE and RDBSHR.EXE
images from a system running the mandatory update for
Rdb/VMS V4.0 and SQL/Services to the target installation
system SYS$LIBRARY directory.
The images are required for IVP linking only. SQL/Services
does not access the files during execution.
This problem is fixed in Rdb/VMS V4.0B.
1.4.7 SQL$STARTUP.COM Startup File Contained an Error in the
SQL/Services Startup Logical Name
In Rdb/VMS V4.0 and V4.0B, the SQL startup file contained
a commented out line for starting SQL/Services that
incorrectly specified the SYS$SYSTARTUP logical name
instead of SYS$STARTUP.
This problem is fixed in Rdb/VMS V4.0B.
1-24 Software Problems Fixed in Rdb/VMS V4.0B
1.4.8 SQL/Services MS-DOS API Installation Failed
Refer to Section 6.5.3 of the Mandatory Update for VAX
Rdb/VMS Versions 3.1B and 4.0. This note describes an
SQL/Services MS-DOS IVP error in which the IVP failed
with -2003 and 9 error status codes when numbers were used
within node names.
This problem is fixed in Rdb/VMS V4.0B. SQL/Services now
allows numbers as well as alphabetic characters in server
node names.
1.4.9 Macintosh API Installation Failed
Refer to Section 6.5.9.2 of the Mandatory Update for
VAX Rdb/VMS Versions 3.1B and 4.0. This note provides
information about a problem in which the SQL/Services
Macintosh API did not work with the DECnet transport
mechanism because of a name mismatch with the DECnet tool
provided by PATHWORKS for Macintosh V1.0.
This problem is fixed in Rdb/VMS V4.0B.
1.4.10 Node Names Containing Numeric Characters Were Improperly
Made Uppercase in OS/2 API
In Rdb/VMS V4.0 and V4.0A of SQL/Services OS/2 API, node
names containing numeric characters were improperly made
uppercase. An error occurred on the sqlsrv_associate()
call when the name of the target node contained one or more
numeric characters.
This problem is fixed in Rdb/VMS V4.0B.
1.5 RDO, Callable RDO, RDBPRE, and RDML Problems Fixed in Rdb/VMS
V4.0B
This section contains notes and problems fixed in the RDO,
Callable RDO, RDBPRE, and RDML interfaces.
1.5.1 Incorrect Value Was Stored During an RDO STORE or MODIFY
Operation
In Rdb/VMS V4.0A, RDO incorrectly converted data types
during a MODIFY or STORE operation. If the data types of
an assignment statement did not match, RDO converted the
righthand side to match the data type of the lefthand side.
This conversion caused incorrect values to be stored.
Software Problems Fixed in Rdb/VMS V4.0B 1-25
This problem is fixed in Rdb/VMS V4.0B.
1.5.2 Multiple RDO Commands in a FOR Loop Caused Unpredictable
Results
Multiple RDO commands in a FOR loop caused unpredictable
results. The following examples show a PRINT command that
returned the wrong result and a MODIFY command that stored
the wrong value:
RDO> SET VERIFY
RDO> !
RDO> ! EXAMPLE_1:
RDO> ! ==========
RDO> START_TRANSACTION READ_WRITE
RDO> FOR T2 IN TABLE_2
cont> CROSS T1 IN TABLE_1 WITH T1.KEY_FIELD = T2.KEY_FIELD
cont> PRINT T2.VALUE_FIELD_1,
cont> T2.VALUE_FIELD_2 ;
cont> PRINT " SUM OF FIELD VALUE_FIELD_1 AND VALUE_FIELD_2",
cont> ( T2.VALUE_FIELD_1 + T2.VALUE_FIELD_2 );
cont> MODIFY T1 USING T1.SUM_FIELD = (T2.VALUE_FIELD_1 +
cont> T2.VALUE_FIELD_2);
cont> END_MODIFY;
cont> PRINT T1.SUM_FIELD;
RDMS-E-JOIN_CTX_UPD, relation TABLE_1 is part of a join, cannot be updated
cont> END_FOR;
1-26 Software Problems Fixed in Rdb/VMS V4.0B
RDO> ! EXAMPLE_2:
RDO> ! ==========
RDO> START_TRANSACTION READ_WRITE
RDO> FOR T2 IN TABLE_2
cont> CROSS T1 IN TABLE_1 WITH T1.KEY_FIELD = T2.KEY_FIELD
cont> PRINT T2.VALUE_FIELD_1 ,
cont> T2.VALUE_FIELD_2 ;
cont> MODIFY T1 USING T1.SUM_FIELD = (T2.VALUE_FIELD_1 +
cont> T2.VALUE_FIELD_2);
cont> END_MODIFY;
cont> PRINT "THE STORED VALUE AFTER THE 1.
cont> MODIFY", T1.SUM_FIELD;
cont> MODIFY T1 USING T1.SUM_FIELD = (T2.VALUE_FIELD_1 +
cont> T2.VALUE_FIELD_2);
cont> END_MODIFY;
cont> PRINT "THE STORED VALUE AFTER THE 2.
cont> MODIFY", T1.SUM_FIELD;
cont> END_FOR;
%RDMS-E-JOIN_CTX_UPD, relation TABLE_1 is part of a join,
cannot be updated
RDO> COMMIT;
This problem is fixed in Rdb/VMS V4.0B.
1.5.3 A Query Using Static OR and a Common Subexpression in Two
or More OR Legs Produced Incorrect Results
A query involving static OR optimization, when a common
subexpression is used in two or more OR legs, produced
incorrect results.
This problem occurred with the execution of the following
two interactive queries:
RDO> FOR R IN COMP_BY
cont> WITH (R.COST_CENTER="0023" AND R.YYYYMM="199101")
cont> OR
cont> (R.DEPARTMENT="0018" AND R.YYYYMM >= "199101")
cont> PRINT R.*
cont> END_FOR
RDO> FOR R IN COMP_BY
cont> WITH (R.DEPARTMENT="0018" AND R.YYYYMM >= "199101")
cont> OR
cont> (R.COST_CENTER="0023" AND R.YYYYMM="199101")
cont> PRINT R.*
cont> END_FOR
Software Problems Fixed in Rdb/VMS V4.0B 1-27
The field 'YYYYMM' is a COMPUTED BY field. The queries
are identical with the exception of the reversal of the OR
legs. Upon execution of the command stream, the number of
rows returned by each query was different.
This problem is fixed in Rdb/VMS V4.0B.
1.5.4 RDB$INTERPRET Now Fully Supports VS (Varying String)
Descriptors
In versions of Rdb/VMS previous to V4.0B, Callable RDO-
RDB$INTERPRET only supported VS (varying string-DSC$K_
CLASS_VS) string descriptors for command strings. If VS
class descriptors (the default for PL/I) were used for
passing data to match the !VAL placeholders, no data was
returned.
VS descriptors contain two length fields shown as follows:
+-------+-------+---------------+
| class | dtype | max len |
| =VS | =VT | |
+-------+-------+---------------+
| pointer |----+
| | |
+-------------------------------+ |
V
+-----------+----------- ----+
| cur len | text data \...\ |
+-----------+------------- --+
One field contains the maximum length and the other field,
which is the first word of the data portion, contains the
current length of the data.
RDO incorrectly used the current length when generating
calls to Rdb/VMS. This length field for an empty string was
zero, so no data was returned.
This problem is fixed in Rdb/VMS V4.0B. RDB$INTERPRET now
supports CLASS S, CLASS SD, and CLASS VS string descriptors
for the command and data.
1-28 Software Problems Fixed in Rdb/VMS V4.0B
1.5.5 Query with a FOR Loop and MODIFY Statement Followed by a
PRINT Statement Returned Incorrect Results
The following query with a FOR loop that uses a MODIFY
statement followed by a PRINT statement returned incorrect
results as follows:
RDO> FOR E IN R1 CROSS F IN R2 WITH (E.UCTO_BH = F.UCTO_B)
cont> SORTED BY E.CION
cont> MODIFY E USING E.CAP = '1' END_MODIFY
cont> PRINT E.CION,E.UCTO_BH,F.UCTO_B
cont> END_FOR
The following results were incorrect:
119 PRO003 PRO003
119 PRO003 PRO003
119 PRO003 PRO003
119 PRO003 PRO003
. . .
. . .
. . .
*** THE SAME RECORD IS RETURNED 63 TIMES INSTEAD OF THE 63
RECORDS ***
The Rdb/VMS V4.0B code was fixed, and the following results
are correct:
101 PRO001 PRO001
102 PRO001 PRO001
103 PRO001 PRO001
104 PRO002 PRO002
. . .
. . .
. . .
1.5.6 Bugcheck Returned Because CHANGE FIELD Had No VALID IF
The following sequence generated a bugcheck because the
CHANGE FIELD . . . NO VALID IF statement incorrectly set the
segmented string id to -1:-1:-1 when it should have been
0:0:0.
RDO> DATABASE FILE PERSONNEL
RDO> CHANGE FIELD ID_NUMBER NO VALID IF.
RDO> CHANGE RELATION WORK_STATUS. DEFINE ID_NUMBER. END.
Software Problems Fixed in Rdb/VMS V4.0B 1-29
This statement appeared harmless, but if this global field
was later added to a relation with existing records, a
bugcheck resulted.
Rdb/VMS was attempting to load the VALID IF definition even
though none existed. This has been corrected in Rdb/VMS
V4.0B. The CHANGE FIELD statement now correctly sets the
segmented string id to 0:0:0.
The following RDO query lists the segmented string id for
all fields in your database:
RDO> FOR R IN RDB$FIELDS
cont> PRINT R.RDB$FIELD_NAME, R.RDB$VALIDATION_BLR
cont> END_FOR
If any VALID IF fields display the -1:-1:-1 segmented
string id, then you should repeat the CHANGE FIELD . . . NO
VALID IF statement to ensure that the segmented string id
is properly cleared.
1.5.7 Shared Fields in a Relation and a View Caused a Bugcheck
Suppose you had an RDML program that stored a field in
a relation that was reserved for SHARED WRITE, and you
also had in a view another field with the same name that
had a COMPUTED-BY clause defined. In Rdb/VMS V4.0, the
compilation aborted with the following error on the STORE
statement:
RDML-E-READ_ONLY, Invalid attempt to update a read only
field '(fieldname)'
This problem is fixed in Rdb/VMS V4.0B.
1.5.8 Changing Records in CDD/Plus Caused an Error
Suppose you had fields and records defined in CDD/Plus and
created a schema via the CDD/Plus pathname and a table from
the CDD/Plus record. If you later changed the records in
CDD/Plus, you might have received the following error at
RDML precompile time if you were using Rdb/VMS V3.1B:
% DML-F-NO_CDD_META_DAT, unable to load metadata from the CDD because
could not attach to CDD/Plus database pathname _CDD$TOP.MOCHI
_CDD-I-MESS,entity has messages
1-30 Software Problems Fixed in Rdb/VMS V4.0B
This problem is fixed in Rdb/VMS V4.0B. RDML now generates
the following informational message:
%RDML-I-DIC_DB_CHG, A dictionary definition used by CDD/Plus database
cdd$default:DATABASE has changed
-CDD-I-MESS, entity has messages
1.6 RMU Problems Fixed in Rdb/VMS V4.0B
This section contains notes and problems fixed in the RMU
interface.
1.6.1 RMU/VERIFY Reported False MINGTRSIZ Error Messages
Under the following conditions, RMU/VERIFY reported false
MINGTRSIZ error messages:
o A database with at least one snapshot area with
allocation 0 was verified, and the 0 allocation snapshot
area was requested to be verified.
o The /START qualifier was not specified on the RMU/VERIFY
command line.
For example, if you verified a database containing a
snapshot area with allocation 0, a false MINGTRSIZ error
message was reported.
$ RMU/VERIFY/ALL/NOLOG MF_PERSONNEL
RMU-W-MINGRTSIZ, starting page 1 is greater than last page 0 of area
area verification is skipped
This problem is fixed in Rdb/VMS V4.0B.
1.6.2 RMU/VERIFY Reported False AIPENTMBZ Warning Messages
In versions prior to Rdb/VMS V4.0B, RMU/VERIFY reported
AIPENTMBZ warning messages when, in fact, there were no
Area Inventory Page (AIP) corruptions of this type. An
example of this message follows:
%RMU-W-AIPENTMBZ, entry 7 in area inventory page 4 has never
been used, but is not empty. It should
contain all zeros
Software Problems Fixed in Rdb/VMS V4.0B 1-31
These warning messages occurred under the following
circumstances:
o A database was restored from some backup and recovered
using some set of .AIJ files.
o The recovery operations included at least one table or
index deletion.
o Verifying the database immediately after the recovery
resulted in the false AIPENTMBZ messages, one for each
deletion specified during recovery. These messages
persisted until the AIP entries freed by the deletions
were reused (by defining new tables and/or indexes).
This problem is fixed in Rdb/VMS V4.0B.
1.6.3 Index Cardinality Not Maintained When an Application
Performed Only a Few Insertions or Deletions
Previous releases of Rdb/VMS did not correctly maintain
index cardinality when an application performed only a few
insertions or deletions to the index.
This problem is fixed in V4.0B. You can use the
RMU/ANALYZE/CARDINALITY/UPDATE operation after installation
to correct any previously inaccurate index cardinalities.
1.6.4 RMU/CLOSE/CLUSTER/WAIT Hung the Database in a Cluster
Environment
The RMU/CLOSE/CLUSTER/WAIT command hung if it was
issued from a node where no processes were attached
to the database and when at least one other process
was attached to the database from another node. The
RMU/CLOSE/CLUSTER/WAIT command created a subprocess that
attached to the database on the node where the command was
issued. That process then was terminated and a recovery job
started. The recovery job would hang and, consequently, the
RMU/CLOSE/CLUSTER/WAIT would hang.
This problem is fixed in Rdb/VMS V4.0B.
1-32 Software Problems Fixed in Rdb/VMS V4.0B
1.6.5 SPAM Threshold Calculations Resulted in Errors Reported by
the RMU/VERIFY Command
In prior versions of Rdb/VMS problems in calculating SPAM
(SPAce Management) threshold values generally resulted in
RMU-W-PGSPAMENT errors reported by the RMU/VERIFY command.
In Rdb/VMS V4.0A and previous versions, incomplete fixes
were made for this problem. The fixes improved SPAM
threshold calculations in about half of the cases. Rdb/VMS
V4.0B should correct the incomplete fix to this problem.
1.6.6 Hashed Index Verification Caused Buffer Flushing Problem
The RMU/VERIFY command caused a bugcheck due to an
unaccounted for buffer pool page flush during a hashed
index verification.
The bugcheck occurred in the RMUVERNDX$VFY_ONE_PAGE_HINDEX
routine. An example exception from a bugcheck of this type
follows:
***** Exception at 000B0C94 : RMUVERNDX$VFY_ONE_PAGE_HINDEX + 00000106
% SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=00000000, PC=000B0C94, PSL=03C00004
This problem is fixed in Rdb/VMS V4.0B.
1.6.7 RMU/COPY or RMU/MOVE Command Incorrectly Copied Area
Inventory Pages (AIP)
The RMU/COPY or RMU/MOVE command incorrectly copied Area
Inventory Pages (AIP). When AIP pages had fewer than 8
bytes of free space, either operation corrupted the last
AIP entry on the page, and you were unable to verify the
database after the operation.
This problem is fixed in Rdb/VMS V4.0B.
1.6.8 TA90E and TA91 Tape Drives Were Not Recognized in Rdb/VMS
V4.0B
Because Rdb/VMS V4.0 did not have support for the TA90E or
TA91 tape drives, RMU treated them as generic devices,
which did not allow RMU to make use of the tape stack
loader.
Software Problems Fixed in Rdb/VMS V4.0B 1-33
This problem is fixed in Rdb/VMS V4.0B. Rdb/VMS V4.0B
supports the TA90E and TA91 tape drives by recognizing
these tape drives as TA90 drives.
In Rdb/VMS V4.1, RMU will fully support and recognize these
tape drives and write to each in compacted mode.
1-34 Software Problems Fixed in Rdb/VMS V4.0B
2
_________________________________________________________________
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
This chapter describes known problems and restrictions
relating to Rdb/VMS Version 4.0B, and includes workarounds
where appropriate. It also contains other information not
discussed in the preceding chapter.
2.1 General Problems, Restrictions, and Notes
This section contains general problems, restrictions, and
other notes.
2.1.1 Singleton Subselect Statement Returning Incorrect Results
Partially Fixed in Rdb/VMS V4.0A But Not Fixed in V4.0B
In Rdb/VMS V4.0A, queries involving a singleton subselect
statement in an SQL precompiled C program sometimes return
incorrect results.
The ECO 32 optional patch for RDMSHRP.EXE (VD2A_
RDMSHRPV040$ECO32.PAT and VD2A_RDMSHRPV040A$ECO32.PAT)
partially fixed this problem for V4.0A; however, not all
cases or situations were covered.
The fix that was distributed in ECO 32 with V4.0A is not in
V4.0B. The problem cannot be fixed in V4.0B, but is fixed
in V4.1.
2.1.2 VMS Lock Remastering Changed in VMS V5.4
Because VMS changed the lock remastering algorithm in VMS
V5.4, the lock trees mastered on one node might migrate
to another node. If the new node (where the locks get
remastered) is a slower node, Rdb/VMS lock requests
might take more time to be processed. You can force the
lock manager to avoid certain nodes as candidates for
remastering by setting the value for LCKDIRWT to 0 for the
respective nodes using SYSGEN. See the VMS documentation
set for more information.
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-1
2.2 Problems, Restrictions, and Notes for All Interfaces
This section contains problems, restrictions, and other
notes that pertain to all interfaces.
Also see the known problems and restrictions chapter of the
V4.0 VAX Rdb/VMS Release Notes and the release notes in the
Mandatory Update for VAX Rdb/VMS Versions 3.1B and 4.0 for
other restrictions that still apply.
2.2.1 Queries Using LIKE Predicate Run Slowly
Key-only Boolean optimization was made available in Rdb/VMS
V3.1, but has not been fully utilized by the optimizer.
Therefore, queries executed with the LIKE predicate are
not being optimized in V3.1x and V4.0x and may execute more
I/Os and run slowly.
A key-only Boolean is a selection or restriction predicate
on an indexed column that does not represent a contiguous
key range within the index. But, it can be applied to
filter out unwanted index keys. Therefore, application
of a key-only Boolean can save I/Os by not fetching the
data records for the keys that are filtered out.
To illustrate this problem, create a sorted index using the
following SQL command:
SQL> CREATE INDEX EMP_LAST_NAME ON EMPLOYEES (LAST_NAME);
And execute the following query:
SQL> SELECT * FROM EMPLOYEES
cont> WHERE LAST_NAME LIKE '%z%'
cont> ORDER BY LAST_NAME;
The strategy produced by the optimizer for this query
follows:
Conjunct Get Retrieval by index of relation EMPLOYEES
Index name EMP_LAST_NAME [0:0]
The EMP_LAST_NAME index is used because it provides the
order requested by the query and, therefore, no sort is
done. Because key-only Boolean is not used on the index
keys, all keys in the index are sequentially scanned and
records are fetched for each index key. The predicate
2-2 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
LAST_NAME LIKE '%z%' is applied to filter out unwanted
records from the final output.
Because this process does not use key-only Boolean
optimization, it generally performs more I/Os and runs
slowly.
This is a known problem in Rdb/VMS V3.1x and V4.0x. In
Rdb/VMS V4.1, the key-only Boolean optimization is improved
so the queries shown in the previous example will run more
efficiently.
2.2.2 Sequential Retrieval Causes Problems with Dynamic Optimizer
When the dynamic optimizer determines that index retrieval
is unproductive, it switches to sequential retrieval. The
switch to sequential retrieval sometimes causes locking
to be escalated from row level to table level. Possible
side effects of this switch are reduced concurrency and
increased risk of deadlocks.
To achieve optimal performance for your application, you
can modify the buffer sizes. See the VAX Rdb/VMS Guide to
Database Maintenance and Performance for more information
regarding buffer sizes.
This will continue to be a problem in Rdb/VMS V4.1.
2.2.3 Anomalous Update Occurs with Subqueries
Rdb sometimes updates more or less than the actual number
of rows when the update query references a table that
is also being updated in a subquery. Specifically, when
the result of a subquery is determined by reading data
from the table being updated and the subquery result is
used to decide whether or not a row should be updated,
sometimes an anomalous update occurs. The anomalous update
occurs because the determination of subquery result and the
decision to update each row is interleaved. The solution to
this problem is to separate these tasks into two different
steps.
The following example illustrates the anomalous update:
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-3
SQL> SELECT * FROM SALARY_HISTORY S WHERE EMPLOYEE_ID = '00187';
EMPLOYEE_ID SALARY_AMOUNT SALARY_START SALARY_END
00187 $12,000.00 7-Aug-1979 29-Nov-1980
00187 $12,513.00 27-Jul-1981 22-Jul-1982
00187 $13,067.00 22-Jul-1982 NULL
00187 $12,390.00 29-Nov-1980 27-Jul-1981
4 rows selected
SQL> DELETE FROM SALARY_HISTORY S
cont> WHERE EMPLOYEE_ID = '00187' AND
cont> SALARY_AMOUNT = (SELECT MIN(SALARY_AMOUNT)
cont> FROM SALARY_HISTORY S2
cont> WHERE S2.EMPLOYEE_ID = S.EMPLOYEE_ID);
2 rows deleted
The query deletes two rows instead of one, which is an
anomalous update. The reason is that Rdb starts with the
first salary history row and finds the minimum salary
amount from a set of four rows. The salary amount in the
first row matches the minimum found and, therefore, the
first row is deleted. Next, the minimum salary amount
is found for the second row from a set of three rows.
The salary amount does not match the minimum found and,
therefore, it is not deleted. The same thing happens with
the third row. Finally, for the fourth row, the minimum is
still found from a set of three rows and the salary amount
matches the minimum found; therefore, it is also deleted.
This problem will be fixed in Rdb/VMS V4.1.
2.2.4 INSERT Command to Double the Contents of a Table Results in
an I/O Loop
When you try to double the contents of a table by executing
the following INSERT command, the process goes into an I/O
loop:
SQL> INSERT INTO TABLE SELECT * FROM TABLE;
This problem occurs when you are using an index and you are
also modifying the index key value as part of the update.
This problem cannot be fixed in Rdb/VMS V4.0B, but is fixed
in V4.1.
2-4 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
2.2.5 A Problem in PSII$DELETE_EMPTY_NODE Causes an Error
A problem in PSII$DELETE_EMPTY_NODE in which the line
number portion of a dbkey was overwritten with zero causes
the following error:
%RDB-E-NO_RECORD, access by dbkey failed because dbkey is no longer
associated with a record
-RDMS-F-NODBK, 46:354:0 does not point to a data record
The dbkey in question is the next node pointer in a level
2 (or higher) index node. This occurs under the following
conditions:
o The level 2 node is second to the left-most node on a
given level.
o The node is completely full. There is no free space
between the last key or dbkey and the next node pointer.
o The current left-most node is deleted.
This problem will be fixed in Rdb/VMS V4.1.
2.2.6 Range Query Returns Unexpected Results
Range retrieval queries that use sequential access to
retrieve records from a uniform area can return fewer
records than expected. When the same query is performed
using a sorted index, it returns the correct number of
records.
This problem occurs when the query is using a comparison of
text fields to non-text fields as the selection criteria
for the range of records. The problem is that Rdb/VMS
converts the non-text values to text values, but handles
leading zeros (for numeric to text comparison) and trailing
zeros (for date to text comparisons) improperly during
the conversion. The improper handling of leading and
trailing zeros can cause the values being compared to be of
different length. The unequal lengths cause the comparison
to fail, which causes the query to return fewer records
than it should.
To avoid the problem store 16 digits of text data,
including trailing zeros for missing time fields, and store
numeric data without leading zeros.
This problem will be fixed in Rdb/VMS V4.1.
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-5
2.2.7 Cannot Correctly Import a Database That Contains
Computed-By Fields That Reference Other Computed-By Fields
In an import operation, if a database contains a table
with a computed-by column that is dependent on another
computed-by column in another table, the import operation
completes, but all the computed-by columns in the group
fail to be created. Rdb/VMS cannot define the computed-by
column because the computed-by column that is referenced is
not yet defined.
Beginning with V4.0, and continuing to V4.0A, V4.0B, and
V4.1, use of computed-by columns that reference other
computed-by columns in a database is restricted, because
the resulting database cannot be imported correctly. This
change to the import operation improves performance of
tables containing many computed-by columns. In versions
previous to V4.0, each computed-by column was created
one column at a time, causing excessive numbers of table
versions (RDB$FIELD_VERSIONS) to be created. Starting in
V4.0 all computed-by columns are defined as a group, thus
saving hours of import operation time. The side effect
is that if one computed-by column contains a dependency
on a computed-by column in another table then all the
computed-by columns in the group fail to be created.
There are two workarounds to this problem:
o Redefine the computed-by columns to omit references to
other computed-by columns.
o Before exporting the database, delete all computed-by
columns that reference other computed-by columns. After
the import operation, re-create the computed-by columns
that reference other computed-by columns. You can create
a short SQL or RDO script to run before each export
operation and after each import operation to accomplish
this.
2-6 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
2.2.8 Using Quoted Threshold Values for Binary Data Types for
Partitioning Data or Indexes Results in Data or Index
Corruption
Data or index corruption can result from using quotes
around threshold values for the signed quadword, signed
longword, signed word, and signed byte data types when
you partition data and indexes, as shown in the following
example:
RDO> DEFINE DATABASE MIKE DICTIONARY IS NOT USED
cont> DEFINE STORAGE AREA ST1 FILENAME ST1 END ST1 STORAGE AREA
cont> DEFINE STORAGE AREA ST2 FILENAME ST2 END ST2 STORAGE AREA
cont> DEFINE STORAGE AREA ST3 FILENAME ST3 END ST3 STORAGE AREA
cont> DEFINE STORAGE AREA ST4 FILENAME ST4 END ST4 STORAGE AREA
cont> DEFINE STORAGE AREA ST5 FILENAME ST5 END ST5 STORAGE AREA
cont> DEFINE STORAGE AREA ST6 FILENAME ST6 END ST6 STORAGE AREA
cont> DEFINE STORAGE AREA ST7 FILENAME ST7 END ST7 STORAGE AREA.
RDO> DEFINE FIELD BILL DATA SIGNED QUADWORD.
%RDO-W-NOCDDUPDAT, database invoked by filename, the CDD will
not be updated
RDO> DEFINE FIELD ACCT_NO DATA TEXT SIZE 5.
RDO> DEFINE RELATION ACCT. BILL. ACCT_NO. END.
RDO> COMMIT
RDO> DEFINE INDEX I1 FOR ACCT DUPLICATES ARE NOT ALLOWED
cont> STORE USING BILL WITHIN
cont> IST1 WITH LIMIT OF "01";IST2 WITH LIMIT OF "03";
cont> IST3 WITH LIMIT OF "05";
cont> IST4 WITH LIMIT OF "07";IST5 WITH LIMIT OF "09";
cont> IST6 WITH LIMIT OF "11";
cont> IST7.
cont> BILL. ACCT_NO. END.
RDO> COMMIT
RDO> DEFINE STORAGE MAP ACCT_MAP FOR ACCT RELATION
cont> STORE USING BILL WITHIN
cont> ST1 WITH LIMIT OF "01";ST2 WITH LIMIT OF "03";
cont> ST3 WITH LIMIT OF "05";
cont> ST4 WITH LIMIT OF "07";ST5 WITH LIMIT OF "09";
cont> ST6 WITH LIMIT OF "11";
cont> ST7 END.
RDO> COMMIT
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-7
RDO> START_TRANSACTION READ_WRITE
cont> STOR A IN ACCT USING A.BILL=1;A.ACCT_NO="1" END_STORE
cont> STOR A IN ACCT USING A.BILL=11;A.ACCT_NO="11" END_STORE
cont> STOR A IN ACCT USING A.BILL=3;A.ACCT_NO="3" END_STORE
cont> STOR A IN ACCT USING A.BILL=5;A.ACCT_NO="5" END_STORE
cont> STOR A IN ACCT USING A.BILL=15;A.ACCT_NO="15" END_STORE
cont> STOR A IN ACCT USING A.BILL=7;A.ACCT_NO="7" END_STORE
cont> STOR A IN ACCT USING A.BILL=9;A.ACCT_NO="9" END_STORE
RDO> COMMIT
RDO> FOR A IN ACCT WITH A.BILL EQ 5 PRINT A.* END_FOR
RDO> FOR A IN ACCT WITH A.BILL LE 5 PRINT A.* END_FOR
If you have data and index records stored in the wrong
partition for a table, reload the table with a storage
map that does not use quotes around the threshold values
for the signed quadword, signed longword, signed word, and
signed byte data types. Quotes are permitted around the
TEXT data type values and work correctly.
This will continue to be a restriction for Rdb/VMS V4.1.
2.2.9 Problem Comparing Different Data Types
The RDO MATCHING clause, the SQL and RDO CONTAINING and
STARTING WITH clauses, and the SQL LIKE clause work as
expected on character string and integer data types, but
all work differently with the DATE data types.
In each case, the syntax is accepted but unexpected results
are returned if a character expression is used because of
the conversion of dates to text strings. When a number is
used in the MATCHING expression or LIKE predicate, correct
results are returned, but if a character expression is
used, no results are returned, as shown in these examples:
RDO> FOR E IN EMPLOYEES WITH E.BIRTHDAY MATCHING "*1954*"
cont> PRINT E.BIRTHDAY END_FOR
BIRTHDAY
20-MAR-1954 00:00:00.00
13-MAR-1954 00:00:00.00
21-NOV-1954 00:00:00.00
15-MAY-1954 00:00:00.00
20-JUL-1954 00:00:00.00
2-8 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
RDO> FOR E IN EMPLOYEES WITH E.BIRTHDAY MATCHING "*mar*"
cont> PRINT E.BIRTHDAY END_FOR
The same behavior is seen in SQL with the LIKE clause:
SQL> SELECT BIRTHDAY FROM EMPLOYEES WHERE BIRTHDAY LIKE "%1954%";
BIRTHDAY
20-Mar-1954
13-Mar-1954
21-Nov-1954
15-May-1954
20-Jul-1954
5 rows selected
SQL> SELECT BIRTHDAY FROM EMPLOYEES WHERE BIRTHDAY LIKE "%Mar%";
0 rows selected
SQL> SELECT BIRTHDAY FROM EMPLOYEES WHERE BIRTHDAY LIKE "%MAR%";
0 rows selected
The reason for this apparently inconsistent behavior is
because the RDO MATCHING clause, the SQL and RDO CONTAINING
and STARTING WITH clauses, and the SQL LIKE clause all
require TEXT as input. Therefore, the dates are converted
to text strings that have the YYYYMMDDHHMMSSCC format
described in the VAX Rdb/VMS SQL Reference Manual. The
match is performed on all digit text strings of the date
("MAR" is never seen because the month value has been
converted to "03") and then the binary values are returned
to SQL or RDO for printing in the format shown.
Use the RDO MATCHING clause with "%%%%03*" or the SQL
LIKE clause with "_ _ _ _03%" to get the results you are
expecting.
2.2.10 RDB$REMOTE Account That Has SYSTEM as Owner Creates
Installation Problems
If V4.0B is installed over an older version of Rdb/VMS
that has SYSTEM as the owner of the default directory
of the RDB$REMOTE account, RDB$SERVER cannot create the
NETSERVER.LOG file and fails on attach or on the first
transaction. A workaround is to use the DCL (DIGITAL
Command Language) command SET FILE/OWNER to set the
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-9
ownership of the default directory of the RDB$REMOTE
account to RDB$REMOTE.
This problem will be fixed in Rdb/VMS V4.1.
2.2.11 Read/Write Query with Multiple Range Predicates on an
Index Column Performs Poorly
With dynamic OR index retrieval, several key ranges on
the same index are scanned in order. The index is opened
and the first key range is scanned. After the first key
range is processed, a key skip is performed to the start of
the next key range to be scanned. The key skip process is
repeated for the remaining key ranges. This is how dynamic
OR index retrieval should work.
However, when dynamic OR index retrieval is used for a
query that is executed within a read/write transaction,
the key skip mechanism is not used. This may cause many
unwanted index records to be read, resulting in poor
performance.
The following read/write query uses a large table to
reproduce this problem:
SQL> SET TRANSACTION READ WRITE;
SQL> SELECT FIELD1, FIELD2 FROM TABLE1
cont> WHERE KEYED_FIELD = 'AAA' OR KEYED_FIELD = 'ZZZ';
Here KEYED_FIELD is a column of a sorted index, and several
keys should appear between the key values 'AAA' and 'ZZZ'.
A workaround is to use ORDER BY KEYED_FIELD in the previous
query.
This problem does not occur for read-only queries. However,
it is a problem for read/write queries. This will be fixed
in Rdb/VMS V4.1.
2.2.12 Synchronization Problem for an Empty Sorted Index
When two simultaneous attaches to the same database access
an empty table via a sorted index, one attach might fail
to see a row created by the other attach. This problem
occurs only in tables whose indexes reside in a single
storage area. It does not occur in partitioned indexes,
nor does it occur in relations whose indexes are unmapped
and reside by default in the RDB$SYSTEM logical area.
2-10 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
Furthermore, this problem occurs only if the table is empty
when both processes attach to the database. This problem
was originally fixed in V3.1B. However, when two released
patches (LCKCCH31B.PAT and SORT_FIX_B.PAT) are applied, the
problem recurs and produces the following exception:
Exception at 00211A5C : RDMS$$KOD_REMOVE_TREE + 0000046B,
(%RDMS-F-BUGCHECK, fatal, unexpected error detected)
The problem still occurs in V4.0B. The following example
shows this problem:
SQL> CREATE SCHEMA FILENAME TEST_DB;
SQL> FINISH;
SQL> DECLARE SCHEMA FILE TEST_DB;
SQL> CREATE TABLE CANDIDATES
cont> (LAST_NAME CHAR (15),
cont> FIRST_NAME CHAR (15));
SQL> COMMIT;
SQL> CREATE INDEX CANDIDATES_INDEX ON CANDIDATES
cont> (LAST_NAME, FIRST_NAME) TYPE IS SORTED;
SQL> COMMIT;
SQL> FINISH;
- Table CANDIDATES is empty.
- User #1 attaches to the database.
SQL> DECLARE SCHEMA FILE TEST_DB;
SQL> SET TRANSACTION READ ONLY;
SQL> SEL * FROM CANDIDATES;
0 rows selected
SQL> COMMIT;
- User #2 attaches to the database and inserts a row.
SQL> DECLARE SCHEMA FILE TEST_DB;
SQL> SET TRANSACTION READ WRITE;
SQL> INSERT INTO CANDIDATES (LAST_NAME, FIRST_NAME)
cont> VALUES ("Doe", "John");
1 row inserted
SQL> COMMIT;
- User #1 wants to delete the row
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-11
SQL> SET TRANSACTION READ WRITE;
SQL> DELETE FROM CANDIDATES;
%RDMS-I-BUGCHKDMP, generating bugcheck dump file $2$DUA1:[DB]RDSBUGCHK.DMP;1
%SYSTEM-F-BREAK, breakpoint fault at PC=00000000, PSL=00000000
There is a workaround to this problem. After creating any
new B-tree index defined on an empty table, store data in
the table so that the index fields are used. In addition,
if you have a partitioned index, store at least one record
in each partition. Once the data is stored, erase the rows.
2.2.13 Query Optimizer Does Not Choose Index-Only Retrieval When
the Dbkey Is Selected
Queries that return dbkeys, but do not reference table
columns, can avoid the use of beneficial indexes. Consider
the following query in which the EMPLOYEES table has a
sorted index with the EMPLOYEE_ID column as the first
segment:
RDO> FOR E IN EMPLOYEES PRINT E.RDB$DB_KEY END_FOR
Rdb/VMS chooses to access the EMPLOYEES table data rather
than the sorted index to solve the query.
In a similar query that references a table column
(E.EMPLOYEE_ID) in which the EMPLOYEES table has a sorted
index with the EMPLOYEE_ID column as the first segment,
Rdb/VMS chooses to access the sorted index using index-only
retrieval.
RDO> FOR E IN EMPLOYEES PRINT E.EMPLOYEE_ID,E.RDB$DB_KEY END_FOR
There is no suitable workaround for this problem.
The following example shows the problem:
$ DEFINE RDMS$DEBUG_FLAGS S
$ RDO
RDO> INVOKE DATABASE FILENAME MF_PERSONNEL
RDO> FOR E IN EMPLOYEES
cont> PRINT E.RDB$DB_KEY
cont> END_FOR
2-12 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
Leaf#01 FFirst RDB$RELATIONS Card=19
BgrNdx1 RDB$REL_REL_NAME_NDX [1:1]
Cross block of 2 entries
Cross block entry 1
Leaf#01 FFirst RDB$RELATION_FIELDS Card=72
BgrNdx1 RDB$RFR_REL_FLD_NAMES_NDX [1:1]
Cross block entry 2
Get Retrieval by index of relation RDB$FIELDS
Index name RDB$FIELDS_NAME_NDX [1:1] Direct tree lookup
Get Index only retrieval
Retrieval by index of relation EMPLOYEES
Index name EMP_EMPLOYEE_ID [0:0]
RDB$DB_KEY
55:15:1
55:2:1
55:22:1
55:50:1
55:14:1
.
.
.
RDO> FOR E IN EMPLOYEES
cont> PRINT E.EMPLOYEE_ID, E.RDB$DB_KEY
cont> END_FOR
Get Index only retrieval
Retrieval by index of relation EMPLOYEES
Index name EMP_EMPLOYEE_ID [0:0]
EMPLOYEE_ID RDB$DB_KEY
00164 55:15:1
00165 55:2:1
00166 55:22:1
00167 55:50:1
00168 55:14:1
. .
. .
. .
This problem will be fixed in Rdb/VMS V4.1.
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-13
2.2.14 Rdb/VMS Hangs on a SELECT Statement When a Column Data
Type Is Changed from INTEGER to CHARACTER to DATE
When changing a column data type from INTEGER to CHARACTER
to DATE, and then trying to select a row from the affected
table, Rdb/VMS hangs.
When you store a value of zero (0) in a table with a
column of INTEGER data type and then try to modify this
column to a DATE data type, this operation fails (as
expected) with the following error message:
%SQL-F-NUM_TO_DATE, Numeric data in column INTEGER_FIELD cannot be
converted to a date data type.
When the same column is altered to a CHARACTER data type,
CHAR(1), Rdb/VMS gives the following error message, and
does perform the alter operation:
%SQL-W-CHR_TOO_SMA, The string length of column INTEGER_FIELD is
too small
When a SELECT operation is performed on the table, the
desired row is returned.
When you alter the data type of the same column to a DATE
data type, the following error is returned:
%SQL-W-INC_DAT_TYP, Altering column INTEGER_FIELD to an
incompatible data type may cause
data loss
When you perform a SELECT operation on the table, it causes
Rdb/VMS to hang for this process, and does not allow anyone
to attach to the database. The process must be deleted from
the system to allow users to attach to the database again.
When you perform metadata changes, Rdb/VMS generates a new
version number on each new row inserted. When the SELECT
statement tries to read an old version, it restructures
that version to the latest (current) version of the row.
In this case, the restructuring tries to convert an INTEGER
data type to a DATE data type.
The problem described here is the result of incorrect error
processing within Rdb/VMS. While trying to output a message
of the following format, Rdb/VMS goes into an infinite
loop:
%RDB-F-WISH_LIST, feature has not been implemented
2-14 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
Converting from an INTEGER to a DATE data type is not
defined by Rdb/VMS and should result in a conversion error.
As a workaround you should modify all the INTEGER fields
stored in old rows using an UPDATE statement before
altering the domain to a DATE data type.
This problem will be fixed in Rdb/VMS V4.1.
2.2.15 Triggers That Affect Subject Table Rows Can Cause Loops or
Inconsistent Results
Triggers that update or add rows to the trigger subject
table can cause infinite loops or inconsistent results
to be returned. For example, consider the following two
conditions:
o A BEFORE UPDATE trigger on table X that inserts a row
into table X
o An UPDATE statement affecting all rows in table X
Given these two conditions, the UPDATE statement loops
until all resources are consumed because for each row
updated, a new row is added, which in turn is updated,
and so forth.
If subject table rows are retrieved using an index, a
triggered action operating on the same table can affect
the index (by changing index key values or adding new keys)
such that the triggering statement behaves differently than
when no trigger is involved.
To avoid this problem, construct any such trigger to
operate only on a row that is either the current subject
table row, or that is never selected by the triggering
statement. A more difficult avoidance method is to
restructure triggering statements so that they never select
a row that could have been updated or added by a trigger
action. Some circumstances require a combination of these
methods.
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-15
2.2.16 Relation Name Must Match Dictionary Record Name
If you define a relation using a CDD/Plus pathname, the
relation name must match the record name. For example, the
following statement contains an error. (The statement can
be processed. However, problems occur later.)
RDO> DEFINE RELATION AAAA FROM PATHNAME "CDD$TOP.TEST.XXXX" END.
The correct form of the statement is as follows:
RDO> DEFINE RELATION AAAA FROM PATHNAME "CDD$TOP.TEST.AAAA" END.
This is a known restriction that was first documented in
the V3.0 VAX Rdb/VMS Release Notes.
2.2.17 NOWAIT Transactions Have Their Buffers Invalidated at
Commit Time
Programs that use NOWAIT transactions have their buffers
invalidated at commit time. This forces Rdb/VMS to read the
data again, as can be observed by higher than expected DIO
rates.
A workaround is to use WAIT transactions.
2.3 SQL Problems, Restrictions, and Notes
This section describes problems, restrictions, and other
information of interest to users of the SQL interface.
See also the Restrictions chapter of the V4.0 VAX Rdb/VMS
Release Notes and the release notes in the Mandatory
Update for VAX Rdb/VMS Versions 3.1B and 4.0 for other
restrictions that still apply to users of SQL.
2.3.1 SQL Deprecated Features and Incompatible Changes for VAX
Rdb/VMS V4.1
Portions of the SQL language are changing for V4.1. The
changes are required for SQL conformance to the ANSI/ISO
standard and to the standard emerging from ANSI SQL2.
Where possible, the current language syntax and semantics
are preserved and merely deprecated. However, in a few
cases, incompatible changes will be made to achieve ANSI
conformance. The types of changes envisioned for V4.1
include:
o Deprecated feature
2-16 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
Syntax that is marked as deprecated will work as it
did previously but its usage may not be supported in a
future Rdb/VMS release.
o Incompatible change
A change to syntax, referred to as an incompatible
change, identifies syntax that does not work as it did
in the previous version or does not work at all.
In anticipation of these changes, Rdb/VMS V4.0 deprecated
some SQL language features. However, some language
features deprecated in Rdb/VMS V4.0 will be changed in a
future version of Rdb/VMS. You can make changes to your
applications now to ease the transition. The following
list describes the language features that will change in
a future version of Rdb/VMS and suggests how to minimize
application impact:
o Schemas will be objects within an Rdb/VMS database.
Currently, an Rdb/VMS database is called a schema in
SQL. To make SQL fully ANSI/ISO compliant, schemas will
become objects within an Rdb/VMS database. V4.1 will
correctly interpret both existing SQL applications and
ANSI-compliant applications in all but two cases:
1. In the first case, an application contains a CREATE
SCHEMA statement that uses ANSI-compliant syntax,
but expects an Rdb/VMS database to be created. You
can resolve this ambiguity by adding an Rdb/VMS
specific clause (such as FILENAME) to the CREATE
SCHEMA statement. For example, your module might
contain the following procedure:
SQL> PROCEDURE CREATE_MY_SCHEMA
cont> SQLCODE
cont> CREATE SCHEMA AUTHORIZATION MY_AUTH
cont> CREATE TABLE T1 (A INT);
In Rdb/VMS V4.0, this statement creates an Rdb/VMS
database. In V4.1, this statement will create a
schema within a database. To resolve this ambiguity,
change the procedure as follows:
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-17
SQL> PROCEDURE CREATE_MY_SCHEMA
cont> SQLCODE
cont> CREATE SCHEMA AUTHORIZATION MY_AUTH
cont> FILENAME MY_AUTH
cont> CREATE TABLE T1 (A INT);
2. In the second case an application contains a DROP
SCHEMA AUTHORIZATION statement. You must change
the DROP SCHEMA AUTHORIZATION statement to either
DROP SCHEMA PATHNAME or DROP SCHEMA FILENAME. SQL
correctly interprets your changed applications in
both Rdb/VMS V4.0 and in V4.1.
o Use single quotes (') instead of double quotes (") for
string literals.
In Rdb/VMS V4.0, the use of the double quote character
for string literals is deprecated. ANSI/ISO dictates
that string literals be formed using the single quote
character. The ANSI/ISO standard does not specify the
double quote character but the ANSI SQL2 draft standard
does use the double quote character for identifiers.
In V4.1, SQL will implement both the ANSI SQL2 draft
standard quoting rules and the quoting rules supported
by Rdb/VMS V4.0 and earlier. Users will be able to
choose which quoting rules to use, with the default
following V4.1 quoting rules of using single quotes.
Rdb/VMS SQL is moving customers toward the ANSI SQL2
draft standard quoting rules. The quoting default will
most likely change to the ANSI SQL2 draft standard
rules in a future release after V4.1. To smooth this
transition, Digital recommends that you develop all
new applications using the single quote character with
character string literals and the double quote character
with identifiers.
o DROP TABLE will default to RESTRICT semantics.
Currently, the DROP TABLE statement first drops all
entities dependent on the table. The keywords CASCADE
and RESTRICT are optional qualifiers to the DROP TABLE
statement in Rdb/VMS V4.0. With the CASCADE qualifier,
all dependent entities are dropped along with the
table. With the RESTRICT qualifier, no entities that
are dependent on the table are dropped.
2-18 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
In Rdb/VMS V4.0, if neither CASCADE nor RESTRICT is
specified, the DROP TABLE statement is interpreted as
DROP TABLE CASCADE. This is consistent with previous
versions of SQL. In V4.1, the interpretation will
be changed to DROP TABLE RESTRICT. You can make
applications containing DROP TABLE statements upward
compatible by adding the CASCADE keyword to their DROP
TABLE statements.
2.3.2 SQL to Support Error Code Values in Rdb/VMS V4.1
In Rdb/VMS V4.1, SQL will add error code values. Some of
these values describe specific error conditions with no
specific SQLCODE value in Rdb/VMS V4.0 and earlier. If your
programs test for SQLCODE -1 as a possible error value,
they may not correctly trap error conditions.
The VAX Rdb/VMS Guide to Using SQL states that values
that are less than zero are error values. Therefore,
applications should check for SQLCODE less than zero rather
than equal to -1 for error status.
Using this test ensures that your programs are always
upwardly compatible between SQL versions.
2.3.3 An SQL SELECT Statement Results in an Invalid BLR Error
The following SQL SELECT statement causes an invalid BLR
error:
SQL> SELECT ( SELECT GRP2.FIRST_NAME FROM EMPLOYEES GRP2 WHERE
cont> GRP2.EMPLOYEE_ID = SST.EMPLOYEE_ID AND
cont> GRP2.SEX = "m" ) FROM DEGREES SST ORDER BY 1;
%RDB-E-INVALID_BLR, request BLR is incorrect at offset 142
If the inner SELECT statement is an aggregate then the BLR
is correctly parsed.
This problem will be fixed in Rdb/VMS V4.1.
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-19
2.4 RDO, RDBPRE, and RDML Problems, Restrictions, and Notes
This section describes problems, restrictions, and other
information of interest to users of the RDO, RDBPRE, and
RDML interfaces.
See also the Restrictions chapter of the V4.0 VAX Rdb/VMS
Release Notes and the release notes in the Mandatory
Update for VAX Rdb/VMS Versions 3.1B and 4.0 for other
restrictions that still apply to users of RDO, RDBPRE, and
RDML.
2.4.1 An Incompatible Change for RDO Applications: New Update
Rules Will Be Enforced by Default in Rdb/VMS V4.1
In Rdb/VMS V4.1, new update rules will be enforced by
default. With new update rules, it will no longer be
possible to modify or delete rows from a table that is
directly joined with other tables. However, rows from a
table can still be modified or deleted if the table is
joined with other tables that are in a subquery. Because
SQL does not have syntax that allows rows from a table
to be modified or deleted and concurrently allows that
table to be joined with other tables, these rules have no
affect on SQL applications. However, those RDO applications
that contain join update queries (the update queries that
modify or delete rows from a table that is joined with
other tables) are affected and must be fixed.
For the following join update query, Rdb/VMS V4.1 provides
this diagnostic:
RDO> FOR E IN EMPLOYEES CROSS D IN DEGREES OVER EMPLOYEE_ID
cont> WITH D.DEGREE = 'MA'
cont> ERASE E
cont> END_FOR
%RDMS-E-JOIN_CTX_UPD, relation EMPLOYEES is part of a join,
cannot be updated
In this update query, if an employee has two MA degrees,
the same employee row would be joined to two different
degree rows. Therefore, Rdb/VMS will try to delete the
same row twice. Or, if instead of using the ERASE verb, the
previous update query used a MODIFY verb on the EMPLOYEES
table, then Rdb/VMS might modify the row more than once.
2-20 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
In versions of Rdb/VMS prior to V4.1, join update queries
similar to the previous query worked correctly, produced
an error diagnostic for trying to delete the same row more
than once or, even worse, produced a bugcheck.
You can reword the previous update query as follows:
RDO> FOR E IN EMPLOYEES WITH (ANY D IN DEGREES WITH
cont> D.EMPLOYEE_ID =
cont> E.EMPLOYEE_ID AND D.DEGREE = 'MA')
cont> ERASE E
cont> END_FOR
Because the EMPLOYEES table is no longer directly joined
to the DEGREES table, in V4.1, the rows can be erased. The
modified update query guarantees that an employee row will
not be deleted more than once.
To ease the transition for applications that depend on the
old update rules, Rdb/VMS will support both new and old
update rules in V4.1, and in the next version after V4.1.
This allows users two Rdb/VMS versions in which to change
their applications (if necessary) to conform to the new
update rules. By default, Rdb/VMS V4.1 will enforce new
update rules. To continue to use the old update rules, you
can define the logical name RDMS$USE_OLD_UPDATE_RULES to
"1" in V4.1.
After these two releases, the support for old update rules
will be removed from Rdb/VMS.
The following is another example of how to change a join
update query to work with the new update rules:
! Give a 10% salary raise to all managers who have an MA degree.
RDO> FOR S IN SALARY_HISTORY CROSS D IN DEGREES CROSS DP IN DEPARTMENTS
cont> WITH S.EMPLOYEE_ID = D.EMPLOYEE_ID AND
cont> S.EMPLOYEE_ID = DP.MANAGER_ID AND
cont> S.SALARY_END MISSING AND
cont> D.DEGREE = 'MA'
cont> MODIFY S USING S.SALARY_AMOUNT = S.SALARY_AMOUNT * 1.1
cont> END_FOR
The previous join update query will not work with the new
update rules. It also modifies some salary history rows
more than once and gives multiple salary raises to some
managers. This query can be reworded using a subquery as
follows:
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-21
RDO> FOR S IN SALARY_HISTORY
cont> WITH S.SALARY_END MISSING AND
cont> (ANY D IN DEGREES CROSS DP IN DEPARTMENTS
cont> WITH S.EMPLOYEE_ID = D.EMPLOYEE_ID AND
cont> S.EMPLOYEE_ID = DP.MANAGER_ID AND
cont> D.DEGREE = 'MA')
cont> MODIFY S USING S.SALARY_AMOUNT = S.SALARY_AMOUNT * 1.1
cont> END_FOR
This latter query works with the new as well as the old
update rules; it ensures that each qualified manager gets a
single salary raise.
2.4.2 Aggregate Expressions in RDO Return an Error
If you invoke multiple databases in the RDO interface and
declare an aggregate expression, Rdb/VMS returns an %RDB-E-
INVALID_BLR error.
For example:
RDO> INVOKE DATABASE FEE = FILENAME USER1:[STUDENT_FEES]STUDENTDB
RDO> INVOKE DATABASE STA = FILENAME USER2:[STUDENT_FEES]STATS
RDO>
RDO> START_TRANSACTION ON FEE USING
cont> (READ_ONLY RESERVING FEE.TRANS FOR SHARED READ) AND
cont> ON STA USING (READ_WRITE RESERVING STA.STATDATA FOR
cont> EXCLUSIVE WRITE)
RDO>
RDO> FOR TX IN FEE.TRANS SORTED BY TX.SNO, TX.SESS, TX.TYPE
cont> REDUCED TO TX.SNO, TX.SESS, TX.TYPE
cont> WITH TX.SESS = "91S"
cont> STORE SX IN STA.STATDATA USING
cont> SX.SNO = TX.SNO;
cont> SX.SESS = TX.SESS;
cont> SX.TYPE = TX.TYPE;
cont> SX.AMOUNT = (TOTAL T1.AMOUNT OF T1 IN FEE.TRANS WITH
cont> T1.SNO = TX.SNO AND
cont> T1.SESS = TX.SESS AND
cont> T1.TYPE = TX.TYPE);
cont> END_STORE
cont> END_FOR
%RDB-E-INVALID_BLR, request BLR is incorrect at offset 172
RDO> ROLLBACK;
2-22 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
2.4.3 Certain Reserved Words Cannot Be Used as Database Handles
for RDBPRE or as Aliases for SQL$PRE and SQL$MOD
The following words cannot be used as database handles for
RDBPRE or as aliases for SQL$PRE and SQL$MOD:
o IV
o R0, R1, . . . , R15
o AP
o SP
o FP
Although not documented in the current release of
VAX MACRO, these words are all reserved symbols in
VAX MACRO and cannot be used in the generated code. This
will be documented as a restriction in a future version of
VAX MACRO. These reserved symbols are also not trapped
in the language precompilers so no warning message is
generated in Rdb/VMS V4.0B.
2.4.4 Wrong Number of Records Returned by a Query in an Inner FOR
Loop
In Rdb/VMS V4.0, V4.0A, and V4.0B an RDBPRE query in an
inner FOR loop returns the wrong number of records when all
of the following conditions exist:
o The query (cursor/stream) is embedded in an application
program.
o The strategy used to solve the query is dynamic OR index
retrieval.
o The query is executed several times with each program
run.
o The host language variables are used in the query to
provide different values for the index keys before each
open cursor.
o The index keys values used with each open cause some
values to be merged into one by the dynamic OR index
retrieval.
This problem is fixed in Rdb/VMS V4.1.
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-23
2.4.5 RDO IMPORT Statement Does Not Save All SQL Defined
Attributes
An RDO IMPORT statement does not save all SQL defined
attributes, such as the default value defined for columns.
Use the SQL IMPORT statement. This is a problem for run-
time only (RTO) systems. There is no workaround to this
problem for RTO systems.
This problem will be fixed in Rdb/VMS V4.1.
2.4.6 RDO CONVERT Statement on V3.0 Databases Causes Database
Corruption When the Database Is Converted to V4.0B
The RDO CONVERT statement for V3.0x reorders the fields
of some system relations so they no longer have the
correct on-disk structure. Consequently, if you try to
integrate the database into the data dictionary (CDD/Plus),
export it, or perform a SHOW TABLE RDB$FIELDS operation, a
bugcheck results with the following exception:
PIOFETCH$WITHIN_DB + 142
Because normal DML access to these relations continues to
work, the corruption usually is not noticed with V3.0x or
even if the database is converted to V3.1x. However, the
corruption causes the database to be incompatible with
V4.0, V4.0A, and V4.0B. After using the RMU/CONVERT command
to convert the V3.0x or V3.1 database to V4.0B, you can no
longer attach to the database.
The solution is to perform an export/import operation
after converting to V3.0x and before converting to V4.0B.
Alternately, the database can be converted by using
the EXPORT/IMPORT statements rather than by using the
RMU/CONVERT command.
Only databases converted from V2.n to V3.0x using the RDO
CONVERT statement and never imported since the conversion
are affected.
2-24 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
2.5 Rdb/VMS Management Utility (RMU) Problems, Restrictions, and
Notes
This section contains problems, restrictions, and other
notes that pertain to the Rdb/VMS Management Utility (RMU).
See also the Restrictions chapter of the V4.0 VAX Rdb/VMS
Release Notes and the release notes in the Mandatory
Update for VAX Rdb/VMS Versions 3.1B and 4.0 for other
restrictions that still apply.
2.5.1 Do Not Delete After-Image Journal (.AIJ) Backup Files if
the AIJ Backup Fails or Is Terminated
If an AIJ backup process fails or is terminated
prematurely, the user might discard the resultant .AIJ
backup file because the backup operation was not completed.
However, all .AIJ backup files, including those produced
by a failed backup process, are necessary to recover a
database. If an .AIJ backup file of a failed backup process
is discarded, the database is not recoverable from that
point forward. This is especially important if you use
magnetic tapes as the AIJ backup media; in this case,
preserve this magnetic tape and do not reuse it.
When an AIJ backup process, especially one running in
continuous (/CONTINUOUS) mode, writes to the .AIJ backup
file, it is possible for the transferred data to be
deleted from the database .AIJ file. If the backup process
subsequently fails or is prematurely terminated (for
example with Ctrl/Y or the STOP command), it might not
be possible to retransfer the data to the subsequent .AIJ
backup file because the data was deleted from the active
database .AIJ file.
Therefore, it is extremely important that you preserve
all .AIJ backup files, even those produced by failed or
terminated backup processes. If the resultant .AIJ backup
file is discarded, the next .AIJ backup file could contain
a "gap" in transactions, so that no transactions would ever
be rolled forward from that point on.
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-25
________________________ Note ________________________
If this problem occurs, the database is not
inconsistent or corrupt. Rather, the database cannot
be rolled forward past the discarded .AIJ backup file.
______________________________________________________
The solution to this problem is to preserve all .AIJ
backup files to ensure that a database can be completely
recovered.
If you have discarded an .AIJ backup file, perform a
complete database backup immediately to ensure that the
database can be recovered up to the current transaction.
2.5.2 Concealed Logicals Are Supported but No Longer Recommended
for Use After V4.0
For Rdb/VMS V3.1 and earlier, some maintenance operations
either needed the use of concealed logical names or were
simplified or more efficient when they were used. So
the use of concealed logical names was recommended and
supported.
With V4.0 and higher versions of Rdb/VMS, RMU provides an
alternate effective means to perform the same maintenance
operations without concealed logical names. Concealed
logical names are an additional complication, and their
use encourages the use of VMS file utilities. Both of these
factors may lead to problems with database maintenance
operations. Therefore, use of concealed logical names for
database files is no longer recommended, although it is
supported. The use of concealed logical names is redundant,
and should be discouraged for new databases.
2.6 Problems and Restrictions Related to the Common Data
Dictionary (CDD/Plus)
This section describes problems and restrictions relating
to the use of Rdb/VMS with the Common Data Dictionary
(CDD/Plus).
See also the Restrictions chapter of the V4.0 VAX Rdb/VMS
Release Notes for other restrictions that still apply.
2-26 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
2.6.1 RDO or SQL INTEGRATE Statement Fails with a NO_META_UPDATE
Error
When you use CDD/Plus V4.3 and Rdb/VMS V4.0 and you execute
an RDO or SQL INTEGRATE statement, the integrate operation
might fail with the following error message:
CDD-E-RDB_ERROR element RDBVMS$STO_REL_NAM_NDX caused Rdb/VMS
operation to abort
-RDB-E-NO_META_UPDATE, metadata update failed
-RDMS-F-NOMETSYSREL, metadata may not be created/altered on
system relations
This happens when you perform an SQL INTEGRATE ALTER FILES
operation. CDD/Plus is incorrectly attempting to upgrade
the Rdb/VMS system relations to match the CDD$RDB_SYSTEM_
METADATA entries in the dictionary when it detects that a
system relations index has been changed (in this case the
index was changed in V4.0 to allow duplicate rows, when in
previous versions it was a unique index).
This problem is corrected by VAX CDD/Repository V5.0
software. The workaround is to first perform an INTEGRATE
CREATE PATHNAME (or CREATE SCHEMA PATHNAME) operation,
which forces the CDD$RDB_SYSTEM_METADATA to update and
match the current version of Rdb/VMS.
2.6.2 Restriction with CDD/Plus V4.3
SQL substring used in views, COMPUTED_BY columns,
constraints, and triggers is not supported by CDD/Plus
V4.3 or earlier versions.
2.7 Rdb/VMS Documentation Errors and Omissions in V4.0
This section describes errors or omissions in the Rdb/VMS
manuals and documents.
2.7.1 Undocumented SQL ALTER DOMAIN and RDO CHANGE FIELD
Statement Restriction
Suppose you perform an SQL ALTER DOMAIN or RDO CHANGE FIELD
operation that causes a conversion error on retrieval of a
record. In an attempt to avoid the error, you might try to
delete the record. This does not work because the delete
operation attempts to do the same incorrect conversion.
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-27
A workaround to this problem is to alter or change the
domain back to the original data type and then remove or
change the offending records. Then you can use the SQL
ALTER DOMAIN or RDO CHANGE FIELD statements to alter the
domain to the new required data type.
2.7.2 Documentation Error Regarding Microsoft C Compatible
Assembler Required for the SQL/Services MS-DOS Application
Programming Interface (API) Installation
In the V4.0 VAX Rdb/VMS Installation Guide, Section
C.1.1, it was documented that an assembler compatible
with Microsoft C is required on your system for the
SQL/Services MS-DOS Application Programming Interface (API)
installation.
A macro assembler is needed to build the DECnet DOS sources
to produce a library that can be used with SQL/Services.
The Microsoft Macro Assembler (MASM), developed and sold
by Microsoft Corporation, is probably the most common macro
assembler that is compatible with Microsoft C compilers.
It was not clear in the V4.0 documentation that other
assemblers besides the Microsoft Macro Assembler might
also work.
2.7.3 Incorrect Reference in V4.0 VAX Rdb/VMS SQL Reference
Manual, Chapter 3
An incorrect reference appears in the V4.0 VAX Rdb/VMS SQL
Reference Manual. On page 3-46, the last paragraph before
the note says to see Table 6-8 for more information about
the LIB$DT_INPUT_FORMAT logical name.
Table 6-8 does not contain any information about LIB$DT_
INPUT_FORMAT. You should refer to the VMS RTL Library
(LIB$) Manual for the appropriate information.
2.7.4 Printing Error in V4.0 VAX Rdb/VMS SQL Reference Manual,
Chapter 4
On page 4-24 of the V4.0 VAX Rdb/VMS SQL Reference Manual,
the following text, which should have preceded Table 4-2,
was omitted:
Table 4-2 shows the VMS data types that SQL requires for actual
parameters when you declare formal parameters for each SQL data type.
2-28 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
2.7.5 Documentation Error in V4.0 VAX Rdb/VMS SQL Reference
Manual, Appendix D.4
In Appendix D.4, Table D-2, in the V4.0 VAX Rdb/VMS
SQL Reference Manual, footnote one states that, "If the
parameter marker or select list item data type allows null
values, the SQLTYPE field value returned is the base value
plus one." This statement is in error. All versions of the
Rdb/VMS SQL interface since and including VAX SQL V1.0 have
not included the functionality stated in footnote one. Such
a feature has never been supported in any released version
of the SQL interface for Rdb/VMS.
The documentation should not have included this footnote.
The only known method for finding the state of the null
vector is to query the metadata and then set a program flag
that indicates the 'null value allowed' state.
2.7.6 SQL/Services Error Documentation
You can find SQL/Services client and server error
documentation in a number of locations:
o Client errors
Client errors are documented in the V4.0 VAX Rdb/VMS
Guide to Using SQL/Services. For Rdb/VMS errors (SQLSRV
error -1), look in the V4.0 VAX Rdb/VMS SQL Reference
Manual. For network errors (SQLSRV -2003), see the
appropriate platform-specific documentation. Table 2-1
contains a partial list of error information on a
platform-specific basis.
Before listing these file names, look at your own
platform-specific documentation for more information
on the secondary error code resulting from a network
error.
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-29
Table_2-1_SQL/Services_Network_Errors______________________
Platform__File_Location____________________________________
VMS sys$library:ssdef.h
DOS \decnet\src\errno.h
ULTRIX /usr/include/errno.h
MPW_______MPW:Interfaces:CIncludes:CMIntf.h________________
o Server errors
VMS server errors are logged in the following
locations:
- The SYS$MANAGER:SQLSRV$.LOG file contains
communication server error information.
- The default directory of the SQLSRV$SRV account
contains execution server log files that are named
SQLSRV$RUNEXE.LOG;n. A log file is created for every
execution server.
2.7.7 RDMS$BIND_VALIDATE_CHANGE_FIELD Logical Name Was Not
Documented in V4.0
The RDMS$BIND_VALIDATE_CHANGE_FIELD logical name that was
introduced and described in the V3.1 VAX Rdb/VMS Release
Notes, was not documented for V4.0.
When using the RDO CHANGE FIELD statement to alter field
attributes of a relation, Rdb/VMS changes the metadata in
the system relation but converts the actual data stored
in the relation when the next update operation occurs.
This approach usually causes no problems. Sometimes,
however, you may make changes to metadata that render data
unreadable due to conversion problems between stored data
and newly defined metadata.
By defining the logical name RDMS$BIND_VALIDATE_CHANGE_
FIELD, you ensure that data records are validated and
converted to the new metadata definition by the CHANGE
FIELD statement, rather than at data update time.
2-30 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
The following example shows how to define the
RDMS$BIND_VALIDATE_CHANGE_FIELD logical name:
$ DEFINE RDMS$BIND_VALIDATE_CHANGE_FIELD 1
2.7.8 RDMS$BIND_VM_SEGMENT Logical Name Was Misnamed in the V3.1
Documentation and Was Not Documented in V4.0
The RDMS$BIND_VM_SEGMENT logical name that was introduced
and described in the V3.1 VAX Rdb/VMS Release Notes, should
not have an S before the dollar sign. The correct logical
name is RDM$BIND_VM_SEGMENT.
2.8 SQL/Services Troubleshooting Suggestions
This section describes the SQL/Services installation
failures most commonly observed during previous Rdb/VMS
installations and offers a solution for each failure.
Errors resulting from these failures, however, are not
exclusively installation errors but general SQL/Services
errors that can arise under a variety of circumstances.
This section also describes incompatibilities among
versions of SQL/Services.
2.8.1 Common SQL/Services Network Errors
This section describes secondary status codes that are
displayed when the SQL/Services Installation Verification
Procedure (IVP) fails with a -2003 error, indicating
an error that is issued from the network. SQL/Services
displays the status codes placed in the SQLCA SQLERRD[0]
field in a message like the one that follows:
SQLCA: SQLCODE: -2003 SQLERRD[0]: error-status-code SQLERRD[2]0
The following list includes a set of error status codes and
a description of how to correct each error condition:
o 8356-SS$_NOSUCHOBJ
The SQL/Services communications server is not active.
Invoke the SQL/Services startup command procedure on the
server system to restart the SQL/Services server:
$ @SYS$STARTUP:SQLSRV$STARTUP
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-31
Refer to Section 6.5.8 of the Mandatory Update for VAX
Rdb/VMS Versions 3.1B and 4.0 for information about the
changes that have been made to the SQL/Services startup
command procedure for Rdb/VMS V4.0A.
After starting SQL/Services, issue a DCL SHOW SYSTEM
command to see if the communication server is active.
If the SQLSRV$SERVER process does not exist, the
communication server encountered a problem during
startup.
The SYS$MANAGER:SQLSRV$.LOG file contains the error
message text describing why the communication server did
not start. Send this file to your local support center
if the error does not directly identify the problem.
o 8436-SS$_LINKEXIT
8348-SS$_INVLOGIN
The SQL/Services IVP for Rdb/VMS V4.0B fails with either
the 8436-SS$_LINKEXIT or 8348-SS$_INVLOGIN status code
if SQLSRV is defined as a DECnet object.
With Rdb/VMS V4.0B, the SQL/Services communication
server automatically declares itself as a network
object. This differs from the approach taken in Rdb/VMS
V3.1, where the SQL$STARTUP.COM procedure defines SQLSRV
as a DECnet object.
To correct this condition, delete the DECnet object from
the DECnet database by entering the following command at
the VMS Network Control Program (NCP) prompt:
NCP> CLEAR OBJECT SQLSRV ALL
2.8.2 Common SQL/Services Fatal Execution Server Errors
The SQL/Services IVP for Rdb/VMS V4.0B fails with the
following error message:
VAX SQL Services sample program failed
SQLCA: SQLCODE: 61312708 SQLERRD[0]: 0 SQLERRD[2] 0
SQLERRM.SQLERRMC %SQLSRV-F-FTLEXEERR,
Fatal execute server error,
sqlsrv$runexe.log contains more information
2-32 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
The communication server was not able to start an execution
server process successfully. A log file, SQLSRV$RUNEXE.LOG,
is created within the SQLSRV$SRV accounts default directory
for every execution server. This log file contains the
error text that caused the execution server process to
fail.
A majority of these failures are caused by incorrect
values for the SQLSRV$SRV account. (All execution server
processes are started within the context of the SQLSRV$SRV
VMS account.) Examples of incorrect account values are:
o The accounts password has already expired.
o The default device or directory is incorrect.
o The process account ENQLM quota value is set too low.
Set this parameter to 1000, and try the IVP again after
shutting down the server and restarting it.
o The process account PGFLQUO quota value is too low.
Set this parameter to 25000 and try the IVP again after
shutting down the server and restarting it.
You may need to experiment further with the ENQLM and
PGFLQUO quota values. Make sure to shut down and then
restart the server each time you change either value.
Use the VMS Authorize utility to modify the SQLSRV$SRV
account if an incorrect value for the SQLSRV$SRV account is
identified. Send the SQLSRV$RUNEXE.LOG file to your local
support center if the error in the log file does not help
you to identify the problem.
2.8.3 Common SQL/Services API Installation Failures
This section provides a list of common problems encountered
during SQL/Services client Application Programming
Interface (API) installations. The list suggests a solution
to each problem, if available.
o A common installation failure that affects all API
installations
Default DECnet access must be enabled on the server.
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-33
If the initial transfer of the client installation file
fails, consult with your system manager to ensure that
your default DECnet account is correctly configured
for default file access. In addition, have your system
manager use the VMS Network Control Program (NCP) to
ensure that the server node allows nonprivileged access.
o Common Macintosh API installation failures
- Selecting the Apple-Digital Gateway with the
Macintosh Chooser
If you plan to use the AppleTalk network as the
SQL/Services transport mechanism, use the Chooser
to select the correct Apple-Digital Gateway.
- Renaming the System Folder
SQL/Services looks for control panel information in
the "System Folder" folder. SQL/Services fails with
a network error, -2003, and a specific error code
of -1 if the system folder has been renamed or named
differently for international products.
2.8.4 SQL/Services Compatibility Issues
This section describes the differences among various
versions of SQL/Services that affect software
compatibility.
2.8.4.1 SQL/Services V4.0B Server Uses Proxy-Like and Default
Access to Authorize V3.0 or V3.1 Client Applications
Explicit access authorization is never granted to an
SQL/Services API client application (Rdb/VMS V3.1) seeking
access to an SQL/Services server (Rdb/VMS V4.0B); however,
the SQL/Services communication server (V4.0) does authorize
access to incoming SQL/Services client application (V3.1)
requests using either the proxy-like or default access
method.
For the SQL/Services server (V4.0B) to grant explicit
access, you must upgrade your Rdb/VMS V3.0 or 3.1 system to
Rdb/VMS V4.0B. As an interim measure, should you choose to
upgrade Rdb/VMS at a later date, set up an SQLSRV$PROXY.DAT
file on the server system to link incoming user names with
local server system accounts. Refer to the VAX Rdb/VMS
Guide to Using SQL/Services for further information.
2-34 Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B
2.8.4.2 SQL/Services V4.0B Server Error -2031 Returned to V3.1
Client APIs
The SQL/Services V3.1 Application Programming Interface
(API) receives the SQLSRV_APINOTSUP (-2031) error mnemonic
when it cannot interpret information returned by the
SQL/Services Rdb/VMS V4.0B communication server. For
example, the SQL/Services Rdb/VMS V3.1 API receives the
SQLSRV_APINOTSUP error when a V3.1 API application attempts
to access list cursor data.
2.8.4.3 Queue Manager Must Be Started for the SQL/Services IVP to
Work
The queue manager must be started for the SQL/Services
Installation Verification Procedure (IVP) to work. If the
VMS queue manager is not started when the SQL/Services IVP
runs, the IVP fails with the following error:
SQLCA: SQLCODE: -2003 SQLERRD[0]: x20a4 SQLERRD[2] 0
Known Problems, Restrictions, and Other Notes for Rdb/VMS V4.0B 2-35
3
_________________________________________________________________
Optional ECO Patches for VAX Rdb/VMS V4.0B
The .A saveset of this kit contains optional ECO patches
for V4.0B that you can install after the V4.0B kit is
installed. These patches are optional for one or more of
the following reasons:
o The patch has reported side effects.
o The patch changes the query optimizer behavior and some
customers may not want the changed behavior.
o The patch is needed by only a few customers, and the
problem does not involve data corruption or incorrect
results.
o The fix was not completed in time for field test and is
therefore not part of the final kit.
If you do not need the patch (that is, you do not have the
problem), then probably you should not install the optional
patch. Please read each patch article and then follow the
specific instructions for any patch you decide to apply.
3.1 Optional ECO Patches That Can Be Applied to Rdb/VMS V4.0B
This section contains the optional ECO patches that can be
applied to Rdb/VMS V4.0B.
3.1.1 RDMSHRP ECO 30: Poor OR Optimization Performance on
Read/Write Transactions
See the Mandatory Update for VAX Rdb/VMS Versions 3.1B and
4.0 for a description of this problem.
This patch resolves a problem with dynamic OR optimization
on read/write transactions by changing the query optimizer
to use static OR optimization instead of dynamic OR
optimization. The patch is optional as it may help some
customers (mainly those who want the V3.1B behavior),
while hurting others (those who are happy with dynamic
Optional ECO Patches for VAX Rdb/VMS V4.0B 3-1
OR optimization on V4.0). The patch article file name is
VD2A_RDMSHRPV040B$ECO30.ARTICLE.
This problem will be fixed in a future release.
To get this patch, use the following command. Replace
<device> by the name of the device where your Rdb
distribution media is mounted.
$ BACKUP <device>RDBVMSDEV040.A/SAV/SEL=VD2A_RDMSHRPV040B$ECO30.ARTICLE *.*
3-2 Optional ECO Patches for VAX Rdb/VMS V4.0B