Migrating to Uniface 10 .2 or Uniface 10.3

Author: adrian.gosbell@synapse-i.jp (Adrian Gosbell)

From a few recent discussions with customers, some guidelines on migrating to Uniface 10:

 

Uniface 10.2, delivered in Sept 2016, enables customers to migrate their applications from Uniface 9.6 or Uniface 9.7 to Uniface 10. 

  • There is a supported migration path.
  • All application features, deployment architectures and so forth are in the Uniface 10 runtime.
  • All planned Uniface 10 currency is available. 

Customers should note a few points about migrating to Uniface 10.2.

  • The Uniface 10 repository is not finalised, it is planned to be completed and delivered in Uniface 10.3, when the workspace support functionality (key version control functionality), and all the relevant editors have been completed.
  • Migrating to Uniface 10.3 from Uniface 9.6 and Uniface 9.7 will be supported.
  • Migrating from Uniface 10.2 to Uniface 10.3 will be supported, but because of the repository changes, customers will need to take some migration steps. (export-import-compile).
  • The utilities to convert Uniface 9 triggers to the code container functionality will be included in the F106 patch.
  • This utility will transfer code from Uniface 9 to Uniface 10.
    • It will continue to be upgraded and tweaked as we gather feedback from customers applications.
    • It will not have the capability to rearrange code within Uniface 10.2 patch/maintenance versions.
    • Consider, ‘once the code has been moved to containers, then it is done’.
    • If there is the need to repeat the exercise, for example there are use cases which are not yet automated and could be. The exercise will need to be repeated starting from Uniface 9.
    • The code utility should be included in the next patch for Uniface 10.2.
  • Based on our test migrations, customer feedback, what we know from best practices guidelines, Partners frameworks and utilities, etc, etc, we believe we have most of the use cases. But we do anticipate more will be uncovered.

Uniface 10.3

·         This release will have the finalised repository.

·         We aim to have Uniface 10.3 available in first half of 2016, firmer dates will be communicated when known. 

Please work with us when you are migrating your applications to Uniface 10, even as a test. Contact us through support or your account manager, we would be interested to take a copy of your Uniface 9.6/9.7 export and do a test import and compilation into Uniface 10 and give feedback.

 

7 Comments

  1. Hello Adrian,  

    Uniface 10.3

    ·         This release will have the finalised repository.

    ·         We aim to have Uniface 10.3 available in first half of 2017

      I noticed that the field "ucompstamp" is now only in the table "usource" implemented. In my opinion the field "ucompstamp" should be implemented in all tables that holds data that needs to be compiled. Also the field "utimestamp" is not implemented in all table.   How about a field "uUsername" in the tables to known which developer changed the code? In most applications there are the fields like "mod_user", "mod_date".   Kind regards Norbert


    Author: Lauterbach (norbert.lauterbach@infraserv.com)
  2. Hi Norbert, sorry for the delay in replying, I've been away for a month.    In regards to ucompstamp in all tables, not in our plans. What would be the purpose to do this?    uUsername, it would imply that the developers details are known to the IDE to be written in the database. We'll think about this more in the context of our version control direction. 


    Author: Adrian Gosbell (adrian.gosbell@synapse-i.jp)
  3. Well I for one have a utility program which compiles all items changed since a given time where they have not been compiled since the change, so knowing whether or not to compile a glyph or a message or similar would be very useful.  I think $processinfo("user") would get the windows user at the time of modification/compilation. 


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  4. In addition to Iains utility: A couple of groups have a "dirty object" list (utimestamp > ucompstamp). Objects in that list either are just because the developer forgot to compile his changes or there is a problem in the modified code. Dirty Objects are seen as a QA help. For U10 the question is how the "timestamp of last successful compile of a piece of code" can be detected otherwise.


    Author: ulrich-merkel (ulrichmerkel@web.de)
  5. Adrian Gosbell said Hi Norbert, sorry for the delay in replying, I've been away for a month.    In regards to ucompstamp in all tables, not in our plans. What would be the purpose to do this?    uUsername, it would imply that the developers details are known to the IDE to be written in the database. We'll think about this more in the context of our version control direction.   

    Hello Adrian, as Iain and Uli says, we also have a tool to find models and forms/services with utimestamp > ucompstamp. In Uniface 9 the utimestamp sometimes changes, even if you don't change the code. Sometimes only watching the form by pressing the "Toggle Paint Tableau"-button suffice to change the utimestamp.   We have 3 platforms : Development, Test and Production. If the form is developed, we export the code from Development and import it to Test. There we compile the code.   We use our tool across these platforms. So we compare the utimestamp between Development and Production, to know if there are any modifications in Development that are not yet transported to the Production platform. In this case we know that we can not make the next change until the code has been transported to Production.


    Author: Lauterbach (norbert.lauterbach@infraserv.com)
  6. Lauterbach said as Iain and Uli says, we also have a tool to find models and forms/services with utimestamp > ucompstamp.

    We too have tools to check weather a component not compile since last change and if a component does change any how. So we also depend on this two fields


    Author: istiller (i2stiller@gmx.de)
  7. thank you all for your reply.    Understood that we need a way of providing this info, we are looking into some ideas. 


    Author: Adrian Gosbell (adrian.gosbell@synapse-i.jp)