Consultor Eletrônico

Status: Verified

GOAL:

On-line schema changes implications?

GOAL:

What are the changes introduced by On-line schema updates?

GOAL:

Database in use by <user> on <tty>. Wait or choose CANCEL to stop. (2623)

GOAL:

<file-name> in use by <user> on <tty>. Wait or choose CANCEL to stop. (2624)

GOAL:

Dictionary being changed by <user> on <tty>. Wait or choose CANCEL to stop. (2625)

FACT(s) (Environment):

All Supported Operating Systems
OpenEdge 10.x

FIX:


Some database maintenance operations that update fields in the _File table may encounter a difference between operation under Version 9 and operating under OpenEdge 10 systems. The differences are intended, and with minor modification an impacted program can still run correctly with both Progress releases.

Programs that modify permissions via changes to the _file table will operate correctly if all of the permissions changes are done in a single transaction as opposed to many small transactions. The key distinction is that changes to permissions require the in-memory schema cache kept by a 4GL client to be updated. Changes to the _DB table are protected by the RDBMS with an intent-exclusive to exclusive lock upgrade, and protected as well on the 4GL side by a request for an exclusive lock on the _DB table. This toggling of the lock on _DB can thus block either side of the exchange while the other is in the midst of updating (re re-caching).

With a single large transaction, there is a single update, and no "toggling back and forth" between many "permissions updates" intermixed with many 4GL client re-cache operations.

The brief description of the difference for OpenEdge 10 is that support for On-line schema changes has required a change in locking protocols in order to extend support to adding tables, columns, fields, and indexes while still in full production. The protocols used in Version 9 were never intended to support this breadth of on-line schema change operation. Please refer to the attached descriptio