Stijn Courtheyn said

Hi Instiller

 

We use different repo's per environment.

DEV

MAIN

Version level (101,102,103,...)

 

So we can use other Uniface versions between them, but we try to keep them on the same. First we try a new version in development to see if there are no problems with it, and then we send it to the Main and release level  

Hi Sttijn So we do Different environments for development and deploment (and for every patch we deliver) But I "install" the new UnifAce version on my local computer (but FRM&Co a on server), my colleagues are still a few patch behind. Only after a few seconds, there was they first cry: "What's going on, I could start a component" Ingo

Hi Ingo,

istiller said First think I notice: the debugger licence is missing?!?! Okay, after a few try and errors I did find the problem: UDBG.ASN have now to be in common\\adm

I guess that you have not set the USYSADM-directory (with the /adm command line option) to uniface\\adm (where the udbg.asn is normally located). In case this is not done then you apparently have specified the files required by the Debugger somewhere else. If not then the Debugger will just not work - except when copying the udb.asn from uniface\\adm to common\\adm This is not something that was changed, but was always the case (since version 9.4.01).

istiller said But much more evil: All componentes have to be recompiled! In patches before, UnifAce was much more tolarent about this. Both version are 9.7.04, the old one is 9.7.04.01 and the new one is 9.7.04.02 @UnifAce: Is this new, that within a version you have to recompile?  

I don't think that is accurate. I guess you try to say that components compiled with the patch G422 will not work with version 9.7.04 (without patches). That is correct. With the patch G402 a new security functionality was introduced that allows to explicitly declare an operation or trigger as being accessible to web clients and/or SOAP clients. For this new functionality it was necessary to change the compiler, which means that components created with the patch >= G402 are not compatible with previous patches and sub-versions of Unfiace 9.7. Sorry. More info about the functionality can be found when you search in the current for "public web", "public sub", or $REQUIRE_PUBLIC_DECL. Unfortunately this requirement is not really explicitly documented. Not sure what went wrong here. I'll ask if it's possible to add a note in the ReadMe of the patches and/or in the Uniface Library. Hope this helps. Daniel

Hi Ingo, I've discussed this with the lab and we probably will add a warning to the ReadMe of the patches. The Development Environment (used for compiling the application) should never use a higher sub version or patch level (of a specific release; e.g. Uniface 9.7) than what is used in Deployment. In general it should be possible to use compiled objects from a lower patch level or sub version (unless it's explicitly stated otherwise), but we cannot guarantee that the opposite will work (nor do we support such a scenario). So, it's okay to use an application that was compiled with (e.g.) Uniface 9.7.04 with the runtime of Uniface 9.7.04 + G422. If an application is (e.g.) compiled with Uniface 9.7.04 + G422 then the runtime should at least be Uniface 9.7.04 + G422 (or higher). Hope this helps. Daniel

Hi Daniel ThanX for answering. Problem we do face is, that in development, we use partly higher subversion to have a lookup for fixes&co At customer sites (plural, as we are a VAR), it is not possible to maintain the same subversion of UnifAce all the time. So in past, we only upgrade our customers if there is a new version of UnifAce but not subversion. This will be done on a ~yearly base if there is also a major patch of our software. Now we have to hold ready not only our patches from past (with the "right" UnifAce version) but also for a current delivery enviroment for every customer. For every customer in case of they need a "hotfix" from UnifAce @Lab: If there is no need for new UnifAce interpreted as all pcode-tokens still they same and it's only a matter of a subversion-ID, a "ignore suberversion missmatch"-flag will be great :-) Ingo