I'm currently poking around in the metaschema, which I haven't done in a while and I am seeing a bunch of stuff that I don't remember having seen before. I don't suppose all this is documented anywhere?
For example, there are a whole bunch of fields in _Field that start with "For". Does this have to do with DataServer schema? Or what?
Hi Thomas,
Rob posted an idea that could more or less be related to your request. Here it is:
That would be a start ... and should have been done a long time ago, but some real documentation wouldn't hurt.
The fields in _Field ending in SA are another group with mysterious purpose, especially with widths of "X(6)"
yes.
Yes to the DataServer question? Or yes to it is documented "somewhere"?
Yes it's mysterious. :)
If I recall the _File._For-* fields are used by dataservers. I assume it's the same for _Field._For-* as well.
Yes it's mysterious. :)
If I recall the _File._For-* fields are used by dataservers. I assume it's the same for _Field._For-* as well.
Flag this post as spam/abuse.
Lack of documentation is not friendly to tool developers like myself.
[quote user="Thomas Mercer-Hursh"]
The fields in _Field ending in SA are another group with mysterious purpose, especially with widths of "X(6)"
[/quote]
SA = String Attribute - should it be U / T30 etc
How about those which follow the pattern _Has-Ccnstrs for _File?
The other question, which I recognize that no one probably has the answer to, is whether these fields are actually used, regardless of what they are theoretically for. If 99% of all databases will never have anything non-default in the field, then there is little reason for me, as a tool creator, to spend any effort supporting them.
Are the -MiscN fields assumed to be for users or do PSC products use them? How about ResN fields?
And Attributes.
[quote user="Thomas Mercer-Hursh"]
The other question, which I recognize that no one probably has the answer to, is whether these fields are actually used, regardless of what they are theoretically for. If 99% of all databases will never have anything non-default in the field, then there is little reason for me, as a tool creator, to spend any effort supporting them.[/quote]
The SA fields are used when compiling with languages option and with translation database connected.
And, what percentage of databases *is* that? ... although, of course, my question is about all of the fields.
There is probably a hierarchy of
* Used always
* Used in combination with X where X = TranMan, DataServer, or whatever
* Used in some odd special circumstances
* Used in some toolset, somewhere
* Used never.
But, how would one know what that hierarchy is, particularly when the meaning of many of the fields is so obscure?
“But, how would one know what that hierarchy is, particularly when the meaning of many of the fields is so obscure?”
And, what percentage of databases *is* that? ... although, of course, my question is about all of the fields.
There is probably a hierarchy of
* Used always
* Used in combination with X where X = TranMan, DataServer, or whatever
* Used in some odd special circumstances
* Used in some toolset, somewhere
* Used never.
But, how would one know what that hierarchy is, particularly when the meaning of many of the fields is so obscure?
Flag this post as spam/abuse.
If fields are used in connection with other products like TranMan, they may not be reflected there at all.
Besides, is "read the source" what you would expect as documentation of application schema? Is it how one understands the schema of Roundtable?
If fields are used in connection with other products like TranMan, they may not be reflected there at all.
Besides, is "read the source" what you would expect as documentation of application schema? Is it how one understands the schema of Roundtable?
Flag this post as spam/abuse.
Customer users rarely have any interest in the schema unless they are using a reporting tool. But, customer *developers* are very often needing to understand the schema in order to do modifications and additions to the software. Anyone who has an interest in tool building has an interest in the schema related to those tools.
As Peter mentioned, the old Engine Crew monographs can still be viewed here:
http://www.fast4gl.com/downloads/monographs/
A lot has changed in the last 16 years so take what you read there with a grain of salt or three. Anyway, number 17 does contain a fair bit of metaschema information that you likely won't find elsewhere. The information, if true, does answer some of Thomas' previous questions.
As Peter mentioned, the old Engine Crew monographs can still be viewed here:
http://www.fast4gl.com/downloads/monographs/
A lot has changed in the last 16 years so take what you read there with a grain of salt or three. Anyway, number 17 does contain a fair bit of metaschema information that you likely won't find elsewhere. The information, if true, does answer some of Thomas' previous questions.
Flag this post as spam/abuse.
Definitely useful.
Just think what an enhancement it would be to simply put Gus's descriptions of each field in the _Help for that field!
I posted a slide deck from a talk i did a few years ago, that contains some general information about the metadata tables and some examples of data you can get from them. It is in the OpenEdge RDBMS Wiki section. I leave finding it as an exercise for the reader. Shouldn't be too hard.
Another exercise: on the BravePoint web site there is a video of Gus delivering this talk at the Virtual Interchange 2010 conference. With a bonus 5 minutes of Q&A. :)
For the search challenged community.progress.com/.../2205.secrets-of-the-openedge-rdbms-schema-tables-part-1.aspx