I recently encountered an issue when importing a servoy 3.5 solution into servoy 5 (final).
The servoy 3.5 solution that I try to import into servoy 5 consists of several modules.
When I export the modules separately (from Servoy 3.5) and import them in the correct order (in Servoy 5), I end up with the following errors: “Cannot resolve relation sequence…”.
This error is the result of an incorrect notation in the frm-files of tabs with relations.
The incorrect notation in the frm-file of a tab with a relation is:
When I export and import the whole solution (all modules included), then the “relationName”-fields are set correctly and the “Cannot resolve relation sequence…”-errors are absent.
Is the issue due to a problem in the Servoy 5 import feature, or is this expected behavior?
P.S. the Servoy conference in Den Ham yesterday was great!
relationName was actually an uuid reference some time ago (earlier versions) , so some older solutions have it that way. Then , at import, if we find an uuid reference we search for the relation and fill its name for everything to be ok. I guess what happens is that everything works well if all modules are together(and all relation names are found) but if only one module is imported and the relation happens to be in another module the import can not know the name of the relation. So, not sure what we can do about this.
lvostinar:
relationName was actually an uuid reference some time ago (earlier versions) , so some older solutions have it that way. Then , at import, if we find an uuid reference we search for the relation and fill its name for everything to be ok. I guess what happens is that everything works well if all modules are together(and all relation names are found) but if only one module is imported and the relation happens to be in another module the import can not know the name of the relation. So, not sure what we can do about this.
Thanks for the reply Laurian.
Indeed if all modules are imported together then everything works fine.
I was expecting that the uuid reference for the relation would be searched for within the previously imported module, but that was not the case (though it could be possible?).
lvostinar:
relationName was actually an uuid reference some time ago (earlier versions) , so some older solutions have it that way. Then , at import, if we find an uuid reference we search for the relation and fill its name for everything to be ok. I guess what happens is that everything works well if all modules are together(and all relation names are found) but if only one module is imported and the relation happens to be in another module the import can not know the name of the relation. So, not sure what we can do about this.
This happened during conversion from 414 to 5 in our solution too. There were only 2 tab forms where it occurred - and both were fixed by deleting the related form and replacing it again in the tab panel. Not sure why this occurred - I suspect its part of the new ‘element positioning’ checks that 5 does. Its possible that both these ‘forms in tabs’ were very slightly overlapping the edge of the tab form (though I cant confirm that now)?
lvostinar:
relationName was actually an uuid reference some time ago (earlier versions) , so some older solutions have it that way. Then , at import, if we find an uuid reference we search for the relation and fill its name for everything to be ok. I guess what happens is that everything works well if all modules are together(and all relation names are found) but if only one module is imported and the relation happens to be in another module the import can not know the name of the relation. So, not sure what we can do about this.
Thanks for the reply Laurian.
Indeed if all modules are imported together then everything works fine.
I was expecting that the uuid reference for the relation would be searched for within the previously imported module, but that was not the case (though it could be possible?).
I think it would be possible for repository import (from admin page) to search in all repository for uuid. You can create an issue about this at www.servoy.com/s ( if you need it) and we’ll have a closer look.
lvostinar:
relationName was actually an uuid reference some time ago (earlier versions) , so some older solutions have it that way. Then , at import, if we find an uuid reference we search for the relation and fill its name for everything to be ok. I guess what happens is that everything works well if all modules are together(and all relation names are found) but if only one module is imported and the relation happens to be in another module the import can not know the name of the relation. So, not sure what we can do about this.
This happened during conversion from 414 to 5 in our solution too. There were only 2 tab forms where it occurred - and both were fixed by deleting the related form and replacing it again in the tab panel. Not sure why this occurred - I suspect its part of the new ‘element positioning’ checks that 5 does. Its possible that both these ‘forms in tabs’ were very slightly overlapping the edge of the tab form (though I cant confirm that now)?
The issue you are describing here doesn’t seem related to initial problem. The initial problem is for 3.x solutions that are imported in Servoy 4.x or 5.x. The conversion between 4.x soution and 5.x solution is something totally different. What was wrong in your solution after conversion ? Which is the content of files on disk for involved elements ?
Kahuna:
The issue you are describing here doesn’t seem related to initial problem. The initial problem is for 3.x solutions that are imported in Servoy 4.x or 5.x. The conversion between 4.x soution and 5.x solution is something totally different. What was wrong in your solution after conversion ? Which is the content of files on disk for involved elements ?
Relationships of some forms in tabs was lost (only on a couple of forms) and in those cases those forms overlapped the tab panel sides slightly. Deleting the forms and reinstating them inside the tabs fixed it!
They were all in one solution - none of the bad relationships were in modules.
Imported our 3.5.12 solution into 5.1.2. There were 28 errors like this:
Description Resource Path Location Type
Related tab error: cannot resolve relation sequence ‘1191c61b-5b9b-48de-8492-9385751b4fcd’ cncm_com_list.frm /concom/forms concom/forms/cncm_com_list.frm Form Problem
On the first import the relation was named correctly a self join called " contact_self " The relation was pk_contact = pk_contact both in the contacts file.
Each of the 28 errors contain the same sequence. They refer to 28 different forms. Some of the forms have tab panels and some are simple list views with no tab panels. There are no elements using the “contact_self” relation that I can find.
kurtbleicken:
Imported our 3.5.12 solution into 5.1.2. There were 28 errors like this:
Description Resource Path Location Type
Related tab error: cannot resolve relation sequence ‘1191c61b-5b9b-48de-8492-9385751b4fcd’ cncm_com_list.frm /concom/forms concom/forms/cncm_com_list.frm Form Problem
On the first import the relation was named correctly a self join called " contact_self " The relation was pk_contact = pk_contact both in the contacts file.
Each of the 28 errors contain the same sequence. They refer to 28 different forms. Some of the forms have tab panels and some are simple list views with no tab panels. There are no elements using the “contact_self” relation that I can find.
Suggestions would be welcome.
Kurt Bleicken
c3net, LLC
This error means the relationName of a tab refers to a relation that doesn’t exist. If you doubleclick the marker it should open the form editor and select the tab. You have an uuid instead of the relationName.
In the case of the form cncm_com_list it is a simple list view. A few buttons and several fields from the communications file and one from a relationship with the contacts file. (not the “contact_self” relation) Just a header, body and footer.
kurtbleicken:
Thanks for the very prompt response.
In the case of the form cncm_com_list it is a simple list view. A few buttons and several fields from the communications file and one from a relationship with the contacts file. (not the “contact_self” relation) Just a header, body and footer.
There is no tab on this form.
That error should be only for a tab. What happens if you Build → Clean ? Or if you restart the developer ? (still have those markers ?)
That error should be only for a tab. What happens if you Build → Clean ? Or if you restart the developer ? (still have those markers ?)
Did a new build and restarted Developer numerous times. Same result.
I even found a form which had absolutely nothing on it but one button. No tabs, no fields, no relationships. Still getting the error message. What should I do to get past these (bogus, I think) error messages? I can’t open up the solution in 5 unless they are gone.