D
dbeavon
Guest
I was thinking about my issue with client/server schema over the weekend. I also did some searching thru the KB. I think I have two theories about what is going on. Theory #1 is that I'm dealing with an outright bug in client/server ABL connections to an OpenEdge database. Such a bug would cause them to fail to pick up online schema changes as they should. Online schema changes are a relatively new feature of OpenEdge, and there may have been shortcomings in the design of this feature where client/server connections are concerned. I found other KB's that point to client-server bugs of a similar nature. http://knowledgebase.progress.com/articles/Article/Error-when-adding-objects-using-OpenEdge-Architect http://knowledgebase.progress.com/articles/Article/P127816 http://knowledgebase.progress.com/articles/Article/P123605 Moving on to my Theory #2, it is possible that this is not technically a bug (at least not by Progress OE standards), but a "feature" based on the way that online schema changes were introduced. The "feature" may be implemented in a way that causes client/server to behave slightly differently than shared-memory connections. Basically the theory goes like this. Online schema changes are possible given an implementation where existing clients are allowed to execute code which predates a schema change; but this happens only by keeping leaving these clients in an "uninformed" state where they are only aware of the original schema and not any changes to it. It is possible that, while the vast majority of the ABL language works fine under this model, the RAW-TRANSFER statement does *not* work because it is *not* happy to remain "uninformed" or "blissfully unaware" of schema mismatches. Below is a link about certain ABL language features that can generate schema-related error messages. This link explains that some of these messages are "expected behavior". http://knowledgebase.progress.com/articles/Article/P126802 However I must say that even under "theory #2", I am not happy that my client-server connections started kicking out errors, and eventually *recovered* on their own (for unexplained reasons). I don't mind error messages which are "by design" or "expected", so long as they are also consistent. But given my experience of it with "RAW-TRANSFER", I think the client-server stuff is flaky. I have never experienced anything quite like this with the "shared-memory" database connectivity. One thing that might force client-server connections to behave more consistently where online schema changes are concerned is to do one of the following. In retrospect, these may have been good things to try. restart the database (in addition to the appserver brokers), or terminate remote servers ( promon > R&D > 4. Administrative Functions > 7. Terminate a Server) Does anyone have experience with client-server connections and online schema changes? Can you help me determine if my RAW-TRANSFER error was happening as a result of theory #1 or theory #2. I haven't followed the evolution of online schema changes closely enough to know if I encountered a bug, or a feature that is by design. Nor do I have enough client-server experience to explain why the behavior of those clients would be so different than a shared-memory clients. Fortunately we don't do online schema changes every day, especially not in production. But if we are going to start replacing shared-memory connections with client-server connections, we should probably understand some of the consequences of making the switch. Thanks in advance.
Continue reading...
Continue reading...