I have a class (A) which defines a protected temp-table.
Class (C) inherits (B) which inherits (A)
I have recompiled all the application, including all the classes.
I am getting an error when trying to instantiate (C)
"Inherited temp-table TTFoo and its protected temp-table TTFoo do not match (12767)"
12767 says:
inherited temp-table do not match. (12767)
If a derived class is compiled against a super class that has a PROTECTED temp-table that is referenced in the derived class, and subsequently gets executed against a different version of the super class where the temp-table has changed, you may get this message if the column datatypes, extents, positions, or indexes have been changed.
Now, I know that the temp-table itself hasn't changed, so what could be the problem ?
I have found that if I change a field's position in the temp-table and recompile Class A, then sometimes the error does go away.
10.1C01 win32
jmls wrote:
This may be related to the problem with "order" sequenced fields not being the same as the field's "rpos" ordering resulting in RAW-TRANSFER's failing.
Does the code use an include file to define the TT? If not, are the TT field definitions in the same order in all the classes?
the temp-table is only defined in the one place (class A). the PROTECTED part is meant to allow each class (B and C) to access the temp-table as if it were defined in the class. For example:
Class C :
DEF PROTECTED TEMP-TABLE TTFoo NO-UNDO
FIELD Baa AS CHAR.
END CLASS.
Class B INHERITS C:
METHOD PUBLIC VOID M():
FOR EACH TTFoo NO-LOCK:
END.
END METHOD.
END CLASS.
Class A INHERITS B:
METHOD PUBLIC VOID Q():
FOR EACH TTFoo NO-LOCK:
END.
END METHOD.
END CLASS.
Julian, I'm confused...you are trying to instantiate class C? The super class? Do I understand correctly...class C doesn't inherit from anything?
the reality, of course, is that things are more complicated than the example.
Class C is a class that is responsible for extracting and manipulating data from a certain table
Class B is a class that is responsible for a generic client interface
Class A is a class that is responsible for a specific client interface
So, A inherits B, and B inherits C
this allowed me to access the temp-table from class A, even though it is defined in class C.
this worked well for most of the time. However, if I modified class A (added some extra code to a method, for example) then I sometimes got the error message described when i tried to instatiate class A
Ah, so you are trying to instantiate the most derived subclass. That makes more sense. Of course the simple case does not reproduce the problem but if you are able to narrow down a case that sometimes reproduces in some circumstances please open a call with tech support. It is certainly something we should take a look at.
Also, you mentioned that you recompiled all the classes. I suppose if it was an automated compile it's possible that you compiled the most derived class (which compiles all of its super classes) and then some time after that compiled just the super class. Of course that *shouldn't* cause a failure if nothing has changed, but it might be contributing to the problem.
I've had past instances with the 4GL client where it didn't recognize date/time stamps on a file and failed to pick up a recent change. Julian may be running into a similar issue here.
Tim,
If you have a reproducible case it sounds like a bug, please log it with Tech Support when you can.
Thanks,
Salvador
Ah, so you are trying to instantiate the most
derived subclass. That makes more sense. Of course
the simple case does not reproduce the problem but if
you are able to narrow down a case that sometimes
reproduces in some circumstances please open a call
with tech support. It is certainly something we
should take a look at.
Also, you mentioned that
you recompiled all the classes. I suppose if it was
an automated compile it's possible that you compiled
the most derived class (which compiles all of its
super classes) and then some time after that compiled
just the super class. Of course that shouldn't
cause a failure if nothing has changed, but it might
be contributing to the problem.
yeah, it's the problem of trying to reproduce it that's causing the grief Don't worry, if I can, I will report it ...
So, in the first post it sounded like A was the
top superclass, but in the last two posts it appears
that C is the top superclass?
Mea culpa, got it the wrong way round in the original post.
>Whichever, I'm
not sure that we have enough information to be
helpful. Is the pattern repeatable? E.g., can you
make a specific change, cause the problem, reverse
the change, and the problem goes away?
No, I have found that the only solution was to change the order of one of the fields in class C and recompile class C. Simply recompiling Class C did not work
>Can you
document what changes cause the problem and which
don't?
Nope. I only need to make a change in Class A and (sometimes) the problem rears it's ugly head. No rhyme or reason.
>Does it make any difference if you get out of
OEA and go back in?
This is not an OEA specific issue. This also happens in a run-time client