Migrating overwritten entity read-trigger

It hasn’t changed — the behavior is still the same. If you have overridden the trigger in the component, the component’s trigger will take precedence.

These are the migration parameters we are using:

Hi
I have slightly different settings, I think my settings are the default ones. In the picture below, marked with yellow.

However, to me it’s not working as before, at least for a Uniface-service, marked as Self-contained.
I see this because it’s a very old entity and there has been used a global variable in the entity read-trigger. This has been solved in Uniface9 by removing that global parameter code in this specific Uniface-service component, otherwise you get an error “Global variable not allowed in Self-contained service”, which is correct.
After the migration the component isn’t compiled in U10, because the entity read-trigger is used.

I just fear that what if this has happened the same for usual form-components. I think among several thousands of forms, we do have such forms where the default entity-triggers have been changed in the form.
I’ve to investigate this further, but any additional info appreciated.

 

Hi Roger
We did migrate vom 9.7.04 to 10.something, no problem at all

The trigger hierarchy, including the content, remains intact, whether you're dealing with regular programs or services.

And yes, if you have services, you'll get a warning about global variables. Just ignore it—I haven't had any negative experiences so far.

Ingo

Oh, there is one difference.
Since UF 10 now has only one large code container per "level" (component, subentity, field), it's no longer as easy to manipulate individual trigger contents.
For an existing program in UF 10, you need to know the trigger name and then add it somewhere within the "level" (e.g., UXGROUP vs. UCGROUP). 
If you want to know what the original content from the level above is, you won't be able to get that information at the lower level. You have to explicitly go to the level above and check there.
To reactivate the content of the upper-level trigger (in UF9, simply delete the content at the lower level), you must delete the trigger, including "trigger <name>".

Hi
So my thinking is that, if the code in Uniface9 component read-trigger is changed compared to the one used in the default entity-read trigger, the component read-trigger should be used also in the migrated Uniface10 form.

I’ve now tested that the same is true for a form, eg. there is no component read-trigger, but the default entity read-trigger is used. To me this seem as a disaster, as the program-logic for some forms and services will be totally messed up.

Hi Roger
As I said, we do no have any problem at all.
A component-level trigger "overrides" the model-level trigger. In UF 9 and UF 10 !
Have you checked the database to see what's there in UF 10?
In other words, does the component trigger appear there?
If not, then it's a migration issue.
If so, then something is wrong with the compilation.
Ingo

Hi,
It seems that it’s only one source that has behaved like this. Other sources are ok.
In the error-source it looks like this, even though there is code in the component read-trigger in U9, so it falls back to the entity-trigger:

In  other sources it looks like this:
 

Very strange that this is empty in one source, and it hasn’t been noticed during the migration. The source is a bit smaller than a previous test-migration, so there is probably something missing.

Regards RogerW. 

You most probably have a space in the component read trigger.  This will be enough to override the default entity code.

for info: 

I would set this to 1 otherwise you will get 1000s of info messages, which I personally hate

MIGRATION_SCRIPT_ADD_END = 1

Hi OsmanShariff,
I’m not sure about what you said, are you right or have you misunderstood the situation. My problem is that the upper example,where the  Occurence script is empty, should contain some code that in U9 has been edited in the component. Yes, the exported source do probably have an empty  component read-trigger. However, as the component is run, it uses the default entity code. So in that case, it’s functioning correct. I think that the “Occurence script”, should be empty, if  it hasn’t been touched in the component. As I said, it’s working correctly, in that sense, that the entity read-trigger is run, as Occurrence-script is empty. It somehow falls back to the entity default trigger, although the component occurence-trigger is empty.

I have exported the U9 source as a test in march and then the source was slightly larger than this incorrect export from last week.
Now I exported it again and it’s slightly larger than the one from march and then of course also larger than the incorrect export from last week.
To me it seems that the last week exporting has left out some small code parts from the components?? 

In v10, the component editor does not show what is in the entity trigger.  You need to double click to open up the entity model.

I seem to remember in v9, you see the component code and if it is empty you see the entity model code (with a different icon)

If the component does not have any code it will be blank.  The run time will still use the code in the model at entity level.

So, now as the export-importworked ok, the above upper exemple is like this:
 

Someone has changed the read-trigger to get rid of the default behavior. Notice that no Delete or Write-trigger is there. Delete and Write are probably executde as in the Default entity triggers.

Here another example where the Read, Write and Delete-triggers have been modified in the component:
 

At this point I would check uxgroup in version 9 uniface for any trigger code in the component in question.

And do the same in v10, to check what is in the field ucomment

You can do this either using sql, or just do an xml export of the component.

Ok, but I used the last correct export to import into the same source-database. It’s ok now. I could of course investigate the export files, but what do I get from that. I don’t think I get some compensation from Rocket, although I can prove a deficient export 😉.