I started this email yesterday morning, then went back to work this
through, trying different scenarios. Updates are in-line.
What would prevent getPrimaryMVClass or compiling a new class from
updating attribute 9? Indeed, what you've described is the behavior I
expected; it's only occasionally what I observe.
One instance where I know attribute 9 is not updated for certain goes
like this: You create a class using the stock PROTOCLASS, or in the
case of my modified Protoclass, you don't specify a package. This
creates a class in the default MVFile package. You then go "oops, that
isn't where I want that class" and pay Hobb getting rid of it. If you
create a class for that MV file in another package, attribute 9 is never
updated again. (Update: neither is attribute 5.)
I've fiddled with this during the day and this is what I see: It would
seem that at least one of a couple of possibilities is playing out. The
code I included in my Protoclass doesn't actually get rid of all the old
class information (though it seems to show up nowhere, not in
filehandle->Dump() or in the F-pointer); it certainly never updates
attribute 9 to reflect that the old class is gone; even though you can
plainly see that the old class is nowhere to be found AND update
attribute 9 of the F-pointer by hand, it never reflects the fact that a
new class has been created for the file and has compiled successfully.
Long and short, make sure a class is in the package you want it in from
the very start. It seems impossible to create a new class in a new
package and have it associate with the file ever again. You can edit an
existing class and recompile it as much as you want. Just don't ever
attempt to delete a class and define a new one in another package.
The only solution I've found is to delete the whole file (dict, all
datalevels, and indices) and start over.
Update: I can find no case in which attribute 5 is updated properly,
either. I spent the rest of yesterday afternoon experimenting with
deleting a class for a multi-level file and attempting to associate
another class with it. Long and short, once you compile a class and
associate it with a file, that's it and all. You can never fully delete
it and associate another class in another package with it.
Update: There seems to be a certain danger in storing any
meta-information in the VOC. VOCs are by nature volatile, hence, never
trustworthy. To wit: there was a fashion in the MV world for a while
to create PROCs on the fly, store them in the VOC, and execute them
right away. That didn't work out so well for manifold reasons. Just
thinking out loud here, but metadata belongs with metadata: I trust
objects in the VOC about as far as I can toss the Empire State Building
over my shoulder. Too many programmers treat the VOC as a free-for-all.
There must be a way to delete a class (definition and object) cleanly
with the metadata matching reality.
(Update) Even after manually adding class names in attribute 9 of the
F-pointer, they're still never updating if classes are deleted.
If you could, give me an opinion on the code I'm using in my Protoclass
(in a previous email in this thread, quoted below). It claims to delete
the definition and object (I can verify the definition is gone in
Studio), but the VOC is never in sync with that fact. The object can
persist whether or not there is an active reference to it. Since I'm
the only user on a single-user instance, I can verify that by logging
all terminal sessions off and logging back on cleanly, then restarting
Now I've come to a new problem I ran up against this morning. There was
an existing class for the main datalevel in the HOURLYEXTREMES MV file.
I deleted the class (using all the best ways I know how), yet attribute
5 was never updated. I edited the F-pointer to get rid of the reference
in attribute 5. I ran MVBProtoclass to create a class for the main
datalevel (so I can maintain the DICT easily). Attribute 5 did update
but the class refuses to compile, complaining that "Hourlyextremes" in
the class query does not reference a unique table.
Uh, well. Why wouldn't it be? That's a separate datalevel to
HourlyextremesLow (HOURLYEXTREMES,LOW) and HourlyextremesHigh
(HOURLYEXTREMES,HIGH). I am throughly at a loss at this point. I'm
ceasing work on this project until I can get a handle on keeping MV
files, classes, and metadata squared away.
I'd love to know more about the inner workings of associating classes
with MV files. Any enlightenment would be welcome.
read more »