Kbase 11386: NEW Rdb Gateway Release: Changes and Compatibility issues
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/10/1998 |
|
NEW Rdb Gateway Release: Changes and Compatibility issues
Implications of THE NEW RELEASE OF Rdb Gateway on VMS:
-----------------------------------------------------
There have been considerable changes/bug fixes to the Rdb
Gateway and these are addressed in Progress 6.2L on VMS.
The changes require an update to both the Client and Server.
o If a user is running strictly on VMS, they will be all set
long as as they get 6.2L10 on all VMS machines running Rdb
gateway.
o If a user is running VMS with Rdb gateway with DOS
clients, they need to have 6.2M on their DOS machines
with 6.2L10 on VMS.
o If a user has UNIX or OS/2 clients going to Rdb on VMS,
then we will have to most likely patch them a client
version to run with the 6.2L10 Rdb Gateway.
HERE ARE THE RELEASE NOTES FOR THE RELEASE.
o RDB GATEWAY -- Issues to be aware of
------------------------------------
o Remote Clients and 6.2L10 Rdb Gateway release
With the 6.2L10 release of Progress on VMS, there are substantial
internal changes which require changes to both client and server
software. Users who only have VMS clients will be all set as long as
all users are on 6.2L10. If you have remote clients (DOS, Unix, etc)
then you need to find out what release for your clients contains
the necessary Rdb Gateway changes in order for you to run. DO NOT
INSTALL 6.2L10 AND EXPECT TO RUN NON-VMS REMOTE CLIENTS WITHOUT
UPGRADING YOUR CLIENT VERSION ALSO. As client software becomes
available we will publish the version you need in the technical
bulletin, or call technical support for information.
o The Rdb Gateway has been enhanced to better handle the
following:
o Progress cursors and their relationship to Rdb
cursors/transactions. The Rdb Gateway will now maintain an
active transaction and cursor pair. For example:
User 1: User 2:
------- -------
FIND FIRST CUSTOMER
WHERE CUST-NUM = 2.
DISPLAY NAME
yields NAME of "John Smith"
DO TRANSACTION:
FIND FIRST CUSTOMER
WHERE CUST-NUM = 2.
NAME = "Tim Jones".
END.
Database is updated.
FIND CUSTOMER WHERE
CUST-NUM = 2.
DISPLAY NAME
yields "Tim Jones"
(previously would have yielded "John Smith")
o Lock upgrades from read only locks to share locks to
support consistent update of records from Progress 4GL. Rdb
does not directly support the notion of lock upgrades, but
in order to maintain data integrity, the Rdb gateway will
now employ an internal mechanism to do this. For example:
FIND CUSTOMER WHERE CUST-NUM = 2.
UPDATE NAME.
In versions previous to this release, this could cause data
integrity problems if 2 users where doing this at the same time.
This is corrected in this version of the Rdb Gateway.
o Detects the different WHERE clauses within FIND statements.
This is best described in the following example:
FIND NEXT CUSTOMER.
DISPLAY NAME CUST-NUM.
FIND NEXT CUSTOMER WHERE CUST-NUM > 10.
DISPLAY NAME CUST-NUM.
In versions previous to this release the Rdb Gateway did
not detect the specification of a new WHERE clause. This
could lead to the wrong record being returned. This is
corrected in this version of the Rdb gateway.
o Compatibility Considerations
With the above mentioned enhancements, the Rdb Gateway will behave
in a manner that is more consistent with a standard Progress
database. However, the following are examples of where the Gateway
will fail to behave in a similar fashion to a Progress database:
1) Use of WHERE clauses
The example is:
FIND FIRST CUSTOMER WHERE CUST-NUM = 5.
FIND NEXT CUSTOMER.
Explanation of behavior:
The absence of a WHERE clause on the second FIND NEXT, means that
the FIND statement is treated as if there were a new WHERE clause.
Therefore, the transaction associated with the cursor is committed
and a new one started. The FIND statement then returns the first
record in the file.
Another example is:
FIND FIRST CUSTOMER.
FIND NEXT CUSTOMER WHERE CUST-NUM < 21.
DISPLAY CUST-NUM.
With the absence of a WHERE clause on the FIND FIRST, Progress
through the Rdb Gateway, will treat each of the FIND statements
separately. In order for the FIND NEXT to get the next record,
issue a WHERE CUST-NUM < 21 on the FIND FIRST also.
2) Rdb cursors/transactions
The example is:
DO TRANSACTION:
FIND NEXT CUSTOMER.
NAME = "John Smith".
END.
FIND NEXT CUSTOMER.
Explanation of behavior:
The cursor is lost once the Rdb transaction is completed (after the
name has been updated) so that when the FIND NEXT CUSTOMER is
executed, an attempt to use a "dead" cursor is made and the following
error will be generated from Progress:
** RDB cursor committed by previous transaction.
If the FIND NEXT CUSTOMER had met the rules for starting a new
transaction, then this error would not occurr.
Another example:
REPEAT:
FIND NEXT CUSTOMER.
NAME = "Fred".
DO TRANSACTION:
FIND NEXT CUSTOMER.
NAME = "Tim".
END.
END.
The second time through this loop, the user will see the
** RDB cursor committed by previous transaction.
Explanation of behavior:
The NAME = "Fred" statement has the net effect of moving the DO
transaction to before the FIND NEXT CUSTOMER statement. Therefore,
when the transaction is committed the cursor is lost. The second
time through the loop the FIND NEXT tries to use the now dead
cursor and Progress generates the
** RDB cursor committed by previous transaction message.
Progress Software Technical Support Note # 11386