Skip to main content

Hi all

I'm migrating a 9.7 repository to version 10. I have an issued that seems related with new inheritance rules but it is not.

There are a local proc entry in a modeled entity. And a form that uses this modeled entity BUT has Local Proc trigger commented (replaced by ; ) as this form does not need or want local procs defined. 

When these forms are migrated to version 10, Local procs trigger is migrated as

;- [Start 'Local Proc Modules']
;
;- [End 'Local Proc Modules']

So, there is no component definition to overlay modeled. So, modeled definition is compiled in version 10 but it doesn't in version 9.

It should be not a problem but their mere existence raise compilation errors (they use undefined component variables). It should be not a problem because (I hope) no one within the form tries to call a removed entry.


The question could be if there is any way for migration to automatically detect these issues and break inheritance.

Is it safe to use #define BreakInheritance_ent_ENTITYNAME on those affected components?

Or maybe is better to come back to the source in v9 and replace empty LocalProcsModules by empty Local Procs definitions:

entry NAME1
end
entry NAME2
end

This helps everything work as expected.


Best wishes


Luis Vila

Hi all

I'm migrating a 9.7 repository to version 10. I have an issued that seems related with new inheritance rules but it is not.

There are a local proc entry in a modeled entity. And a form that uses this modeled entity BUT has Local Proc trigger commented (replaced by ; ) as this form does not need or want local procs defined. 

When these forms are migrated to version 10, Local procs trigger is migrated as

;- [Start 'Local Proc Modules']
;
;- [End 'Local Proc Modules']

So, there is no component definition to overlay modeled. So, modeled definition is compiled in version 10 but it doesn't in version 9.

It should be not a problem but their mere existence raise compilation errors (they use undefined component variables). It should be not a problem because (I hope) no one within the form tries to call a removed entry.


The question could be if there is any way for migration to automatically detect these issues and break inheritance.

Is it safe to use #define BreakInheritance_ent_ENTITYNAME on those affected components?

Or maybe is better to come back to the source in v9 and replace empty LocalProcsModules by empty Local Procs definitions:

entry NAME1
end
entry NAME2
end

This helps everything work as expected.


Best wishes


Luis Vila

Hi Luis


It's not quit clear tp me where a which  entries are 🙂

Is this the constellation?
ENTITY1 <LPME>
  ENTRY LP_ENTRY1
  END
FRM1 <LPMX>
 ; ENTRY LP_ENTRY1
 ; END

Then there should no problem; or am I wrong?

BUT ...

But beware of entity (subtype) vs. table (supertype)
Most entity level local procs are defined in a table not entity
And if one paint two entities of the table in a from, you got doubled procs
To avoid this, I do this trick (just an example)

TABLEY1 <READ> 
  call LP_<$entname>_DOIT

TABLE1 <LPME>
  ENTRY LP_<$entname>_DOIT
  END

FRM1 <LPMX>
 ENTRY LP_DOIT
 END

So each entity has its own set of procs and it's independent from LPMX

Ingo



Hi all

I'm migrating a 9.7 repository to version 10. I have an issued that seems related with new inheritance rules but it is not.

There are a local proc entry in a modeled entity. And a form that uses this modeled entity BUT has Local Proc trigger commented (replaced by ; ) as this form does not need or want local procs defined. 

When these forms are migrated to version 10, Local procs trigger is migrated as

;- [Start 'Local Proc Modules']
;
;- [End 'Local Proc Modules']

So, there is no component definition to overlay modeled. So, modeled definition is compiled in version 10 but it doesn't in version 9.

It should be not a problem but their mere existence raise compilation errors (they use undefined component variables). It should be not a problem because (I hope) no one within the form tries to call a removed entry.


The question could be if there is any way for migration to automatically detect these issues and break inheritance.

Is it safe to use #define BreakInheritance_ent_ENTITYNAME on those affected components?

Or maybe is better to come back to the source in v9 and replace empty LocalProcsModules by empty Local Procs definitions:

entry NAME1
end
entry NAME2
end

This helps everything work as expected.


Best wishes


Luis Vila

Hi Ingo

Think is better to explain with an image. The Entity has some entries defined in the model, so they appear in every component that includes the entity. But in several forms, this LPME was replaced by ; (see image)

This leads to this code in version 10

;- [Start 'Local Proc Modules']
;
;- [End 'Local Proc Modules']

What means nothing to the compiler. 


So, in version 10, the compiler gets the modeled definition of LocalProc... which was not the v9 developer wanted when removed them with the ;  (the compiler is right, there is no local version for the modeled entries, just an ; in the middle of nowhere)


Similarly, if the Delete trigger is also removed using a ;   the migration process acts properly and generates this

trigger Delete
;

Which is enough to the v10 compiler to know there is a local definition for trigger Delete.



Hi Ingo

Think is better to explain with an image. The Entity has some entries defined in the model, so they appear in every component that includes the entity. But in several forms, this LPME was replaced by ; (see image)

This leads to this code in version 10

;- [Start 'Local Proc Modules']
;
;- [End 'Local Proc Modules']

What means nothing to the compiler. 


So, in version 10, the compiler gets the modeled definition of LocalProc... which was not the v9 developer wanted when removed them with the ;  (the compiler is right, there is no local version for the modeled entries, just an ; in the middle of nowhere)


Similarly, if the Delete trigger is also removed using a ;   the migration process acts properly and generates this

trigger Delete
;

Which is enough to the v10 compiler to know there is a local definition for trigger Delete.



Ciao Luis,

IMHO to have full compatibility:

;- [Start 'Local Proc Modules']
;- [End 'Local Proc Modules']

should means "nothing" to the U10 compiler...while:

;- [Start 'Local Proc Modules']
;
;- [End 'Local Proc Modules']

should means to the U10 compiler what was meaning in U9:
"I (developer) want to break existing inheritance with Appl.Model".

Now, trying to go for a solution for two type of inheritance supported by U9:
1) Overlay inheritance - in LPMx container I consider safer to define empty entries in the original code, like:
    entry ONE
    end
    entry TWO
    end
2) Properties and single trigger inheritance -  In delete trigger, something like:
    end
Should work either for triggers requiring code to work as well as for triggers having default behaviour when empty.

Further comment:
??? I use, used and suggested the technique to substitute Appl.Model code with a comment a lot!
??? I am not sure if I would accept this last proposal, I do NOT like it!
??? Could migration process taking care to maintain full compatibility?

I am really interested how this discussion will develop...

Gianni


Hi Ingo

Think is better to explain with an image. The Entity has some entries defined in the model, so they appear in every component that includes the entity. But in several forms, this LPME was replaced by ; (see image)

This leads to this code in version 10

;- [Start 'Local Proc Modules']
;
;- [End 'Local Proc Modules']

What means nothing to the compiler. 


So, in version 10, the compiler gets the modeled definition of LocalProc... which was not the v9 developer wanted when removed them with the ;  (the compiler is right, there is no local version for the modeled entries, just an ; in the middle of nowhere)


Similarly, if the Delete trigger is also removed using a ;   the migration process acts properly and generates this

trigger Delete
;

Which is enough to the v10 compiler to know there is a local definition for trigger Delete.



I tried to detect those triggers directly in the XML file. But there are several scenarios: just a semicolon, several semicolons, semicolon + carriageReturn, the whole definition commented...
Final approach is a diff between 9.7.last and 10.3.last components compilations. Those where have an extra error is because version 10.3 is reading modeled definition that have undefined local variables (in version 9 were not defined as these components didn't need them). It is not the 100% but it is indeed the 100% that hurts.

Correct the list manually. Go to LPME container, doble-click to reset with model definition, and empty contents, leaving entry NAME & end. Save.

NOTE: There is no problem at all with entity triggers definitions. A removed/commented entity trigger in version 9, arrives perfectly to version 10.

Hi Ingo

Think is better to explain with an image. The Entity has some entries defined in the model, so they appear in every component that includes the entity. But in several forms, this LPME was replaced by ; (see image)

This leads to this code in version 10

;- [Start 'Local Proc Modules']
;
;- [End 'Local Proc Modules']

What means nothing to the compiler. 


So, in version 10, the compiler gets the modeled definition of LocalProc... which was not the v9 developer wanted when removed them with the ;  (the compiler is right, there is no local version for the modeled entries, just an ; in the middle of nowhere)


Similarly, if the Delete trigger is also removed using a ;   the migration process acts properly and generates this

trigger Delete
;

Which is enough to the v10 compiler to know there is a local definition for trigger Delete.



Ciao Luis,

So...also the commented DELETE trigger works as expected?

Gianni


Hi Ingo

Think is better to explain with an image. The Entity has some entries defined in the model, so they appear in every component that includes the entity. But in several forms, this LPME was replaced by ; (see image)

This leads to this code in version 10

;- [Start 'Local Proc Modules']
;
;- [End 'Local Proc Modules']

What means nothing to the compiler. 


So, in version 10, the compiler gets the modeled definition of LocalProc... which was not the v9 developer wanted when removed them with the ;  (the compiler is right, there is no local version for the modeled entries, just an ; in the middle of nowhere)


Similarly, if the Delete trigger is also removed using a ;   the migration process acts properly and generates this

trigger Delete
;

Which is enough to the v10 compiler to know there is a local definition for trigger Delete.



Sure. Proper triggers are migrated as expected:

trigger Delete
;

(Without end)

Terms & ConditionsAccessibility statement