D
dbeavon
Guest
I've started using client-server connections to the OE DBMS and have discovered issues that never impacted me with "shared memory" connections. One of the more annoying issues is that online schema changes don't work. In version 10 Progress claimed to have added support for this... but whatever support they had added was incomplete to say the least. There are a variety of obscure errors that ABL apps will receive if they are connected remotely via client-server connections to an OE DBMS server ("SERV".) Here is a partial list of the types of interesting messages you will see (list taken from Progress KB - Cannot see schema changes applied online ) BUFFER-FIELD was not found in buffer . (7351) Lead attributes in a chained-attribute expression (a:b:c) must be type HANDLE or a user-defined type and valid (not UNKNOWN). (10068) SYSTEM ERROR: Cannot read field from record, not enough fields. (450) SYSTEM ERROR: Cannot read field XXX from record, not enough fields SYSTEM ERROR: Failed to extract field from record (table ) with recid . (3191) Couldn't extract field ' ' from source in a BUFFER-COPY statement. (5367) Stale schema failure during RAW-TRANSFER - Forum - OpenEdge Development - Progress Community RAW-TRANSFER statement failed due to stale schema The errors listed above are by no means exhaustive, according to that KB. Other KB's elaborate on the problems with "online" schema changes: CLIENT-SERVER CONNECTIONS CANNOT SEE SCHEMA CHANGES APPLIED ONLINE Progress KB - Client-Server connections Cannot see schema changes applied online ERROR WHEN ADDING OBJECTS USING OPENEDGE ARCHITECT Progress KB - Error when adding objects using OpenEdge Architect ERRORS 450 AND 3191 ON LOADING SCHEMA (.DF) WITH CLIENT SERVER CONNECTION Progress KB - Errors 450 and 3191 on loading schema (.df) with Client Server connection By trial-and-error, I've discovered that I can dig into promon (R&D) and find "admin functions" -> 7. "terminate server" and then start killing off any servers of type "SERV". Once they are all dead, the schema corruption/compatibility issues seem to go away for any app that is restarted. But killing off servers like this seems to be a very error-prone solution. It certainly does not seem like the type of thing you want to be doing in a production environment. (more explanation about this workaround can be found here: Progress KB - Client-Server connections Cannot see schema changes applied online ) Is it common knowledge that "online" dictionary changes are this unreliable? Are we doing something unusual? Our ideal workflow would be to run a DDL like so (via the SQL92 interface) without worrying about killing SERV-type servers afterwards. ALTER TABLE PUB."xxx" ADD COLUMN ( "abc" BIT DEFAULT 'false' PRO_ORDER 810 PRO_FORMAT 'true/false' PRO_LABEL 'abc' PRO_COL_LABEL 'abc' ) ; Once the schema is changed we'd like it if our ABL clients would pick up the change, especially if they are restarted. Unfortunately it is not enough to stop the client-server ABL clients because the "SERV"-type servers seem to have corruption in them as well. Any tips would be much appreciated. I'd especially like to avoid the part where we have to use promon to kill servers. In the very least it would be nice if the DBMS would start creating additional servers for all new client connections that are made after the schema changes. The old servers that predated the schema change should not be used for new connections.
Continue reading...
Continue reading...