Migrating to Uniface 10

Heading towards Uniface 10.3

Since the release of  Uniface 10.2 the topic of custom utilities on the Uniface repository has come up several times during conversations with customers, at user events and in the forums. The plan is that we address at least part of these requirements (making umeta.xml available) in 10.3.

Migrating to Uniface 10
Uniface Entity Editor

Why wait for 10.3? The migration from 9 or 10.2 to 10.3 will require a full migration, an xml export and import. This is something we don’t do in patches or service packs. The reason for the migration is that we are working towards locking the repository to offer a stable platform for customers. By stable I mean one where, for the foreseeable future, we will not require customers to undertake a full migration. We have planned changes and are validating them to make sure we can implement the functionality we would like to deliver. For Work Area Support we need to make sure that, as much as possible, merging is possible. For global objects (USOURCE) we are splitting it in to multiple tables to more closely reflect the data they hold.

With the repository being updated there are some areas in the development environment that also need some attention, we need to ensure they continue to work:

  • The compiler
  • Export/Import
  • The hybrid components
  • xml
  • Migration
  • Create Table Utility (for repository and user tables)

Whilst on the subject of the “Create Table Utility”… We have been thinking how it might fit into the IDE, should it have its own workbench or should we achieve the functionality in another way? There are currently two implementations we are looking at. Firstly, from the command line. This option is how, in the future we will be supplying the scripts for the repository. Getting Uniface to generate the scripts, rather than a static list being supplied with the installation, will mean more deployment options – it will use driver options in the ASN to generate the correct scripts for your environment.

Uniface Scripts
*Example only

Secondly, we are looking at adding a create table menu option to the project editor. With this method it would be possible to collect all the tables you need generating into a project and asking Uniface to generate the scripts for you.

Uniface Table Menu

2 thoughts on “Heading towards Uniface 10.3”

  1. While I’m not entirely sure this lines up with Mike’s topic 100%, but I think there’s some things that need to be said of Uniface 10.2. I’d be happy with just being able to accomplish the simple tasks in a reasonable amount of time. For example: Creating a new entity, defining fields, relationships and sub-types used to take minutes…..now it’s much longer and there’s no guarantee you’ll get everything setup correctly. I don’t want this post to come across the wrong way…..I think Uniface needed an overhaul on the back-end to allow for more modern approaches to software development (hopefully), but it doesn’t feel “finished”. Case in point, I’m looking at an existing project in the Uniface 10.2 IDE and I want to look at the code (write script) and the layout (define frames) at the same time — sounds like it should be pretty simple and like the first thing you’d need after migrating a project from U9 to U10 to check under the hood to be sure everything is where it should be. Well, you would be disappointed to find out that you can’t see both at the same time. While I have been promised that this will be addressed in 10.3…..how did it get from 10.1 to 10.2 without this? I’d also like to do something simple like recompile all the components that has an entity painted on it that I just did a db change to. I had a tool that I wrote to do this for me and now it doesn’t work in 10.2? Why would I want to migrate a project that has hundreds of entities and thousands of components into an environment that IMO can’t handle the job? I could be making a huge leap here, but the patches that are getting released for 10.2 aren’t coming close to addressing what I call the basic and common functions that should be available in a development environment. Was Uniface 9 so advanced that duplicating the functionality in Uniface 10 seems to be treated as something short of miraculous? My Uniface 10.2 experience is only causing me to want to stay in Uniface 9.6/9.7 that much longer. I think one would be hard-pressed to find a senior Uniface developer that would disagree. ….but that’s what forums are for, eh?

    1. Hi Larry,
      i totally agree with your findings, but as I asked for some “exclusive forum” for U10 early adopters, this was rejected.
      There are a couple of things like beeing neither able to set INFO messages in compile listing via preferences nor test/debug components out of the IDE
      which makes it pretty hard to reach U9 productivity in U10. Specifying some 10 relationships becomes a real nightmare in U10.

      One would have expected that U10 as a follower of U9 would keep the traditional obligations
      and have at least from the very very first version: 1) Additional Menu 2) Preferences 3) Metadictionary.
      But most important: in U9 the developer decides when changes are written to the database (^accept, ^save) or changes are canceled.
      In U10, your modifications are saved without your control which IMHO is a violation of the prime directive “Coder Is Always In Control”.

      Greetings from Frankfurt/Germany,

      P.S. For 10.2 I compiled my own “provisional metadictionary” (old uniface gurus have experiences how to fill gaps like this)
      to be able to check the sources and be prepared for excercises like “compile all components having changed entity XYZ”.
      Contact me if you are interested.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please fill in the right answer to this question * Time limit is exhausted. Please reload CAPTCHA.