Skip to main content

Uniface 10 Enterprise Edition: About the U10 DICT

  • November 19, 2018
  • 3 replies
  • 0 views
Jan Cees Boogaard

About the U10 DICT

Author: ulrichmerkel@web.de (ulrich-merkel)

Adrian mentioned in: https://unifaceinfo.com/forum/uniface9/anyway-to-use-session-panels-to-trigger-startupshell-triggers/#p6052893

But it has always been our intention that we would document the Uniface 10 dictionary when complete (with Uniface 10.3). Even if we did not, we can’t stop access to those tables. So to put an end to any more fake news..

  But as all of us know, since the very old days, variable length fields in the DICT are not stored in different database fields, but they are all mashed together and maybe scattered in the nice OVERFLOW tables as well. So individual information can not be reached so easyly. I already created my own DICT in Sep-2016 and found some incompatibilities with the U9 dict reports. Perhaps they are gone with the official 10.3 DICT, but it is worth to migrate a handful of DICT reports (especially those using COMMENT fields) and see if they still do their job.

3 replies

Jan Cees Boogaard

About the U10 DICT

Author: ulrichmerkel@web.de (ulrich-merkel)

Adrian mentioned in: https://unifaceinfo.com/forum/uniface9/anyway-to-use-session-panels-to-trigger-startupshell-triggers/#p6052893

But it has always been our intention that we would document the Uniface 10 dictionary when complete (with Uniface 10.3). Even if we did not, we can’t stop access to those tables. So to put an end to any more fake news..

  But as all of us know, since the very old days, variable length fields in the DICT are not stored in different database fields, but they are all mashed together and maybe scattered in the nice OVERFLOW tables as well. So individual information can not be reached so easyly. I already created my own DICT in Sep-2016 and found some incompatibilities with the U9 dict reports. Perhaps they are gone with the official 10.3 DICT, but it is worth to migrate a handful of DICT reports (especially those using COMMENT fields) and see if they still do their job.

Hi Uli, and others, Here is a short update on 10.3 and DICT, you will get: - Restructured repository (typed libraries, preparation for work area support, removal of long deprecated stuff) - Updated descriptions of the entities and fields of DICT in the umeta.xml - Fresh umeta.xml with every patch (so we can further improve descriptions when needed) - Explanation of the repository changes in the ulibrary - Switch to create sql scripts for your repository tables for any supported database and its driver options There will still be fields in overflow tables, so you will still need Uniface to access all data. And there will be quite a lot of changes, so the new DICT is not compatible with Uniface 9 or even 10.2. Any reports or tools customers have made will need revision. But the really basic stuff has not changed much, so it is not always a lot work to get your tools working again. Since we don't want you to do the changes multiple times, we are doing our best to get it right in 10.3. We are finishing up the work on the repository now. I can't give you a timeline for the release of 10.3, but when it comes it will contain this.   Regards, Theo


Author: Theo Neeskens (tneeskens@itblockz.nl)
Jan Cees Boogaard

About the U10 DICT

Author: ulrichmerkel@web.de (ulrich-merkel)

Adrian mentioned in: https://unifaceinfo.com/forum/uniface9/anyway-to-use-session-panels-to-trigger-startupshell-triggers/#p6052893

But it has always been our intention that we would document the Uniface 10 dictionary when complete (with Uniface 10.3). Even if we did not, we can’t stop access to those tables. So to put an end to any more fake news..

  But as all of us know, since the very old days, variable length fields in the DICT are not stored in different database fields, but they are all mashed together and maybe scattered in the nice OVERFLOW tables as well. So individual information can not be reached so easyly. I already created my own DICT in Sep-2016 and found some incompatibilities with the U9 dict reports. Perhaps they are gone with the official 10.3 DICT, but it is worth to migrate a handful of DICT reports (especially those using COMMENT fields) and see if they still do their job.

Hi Theo, thanks for the little insight "what is in the pipe" as far as the 10.3 repository is concerned. Especially the documentation in the description (and perhaps comments?) needs an update as even the 9.7.04 DICT shows "Uniface Repository version 9.5.01.01".   As I said, it may be good for "Early Adopters" to choose a couple of their productive DICT reports right now and test them against the U10.3 DICT (including automatic U9 to U10 migration) as soon as 10.3 is available. I think this will give you in Amsterdam some early feedback what problems wait "in the trenches". TIA for your efforts, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

About the U10 DICT

Author: ulrichmerkel@web.de (ulrich-merkel)

Adrian mentioned in: https://unifaceinfo.com/forum/uniface9/anyway-to-use-session-panels-to-trigger-startupshell-triggers/#p6052893

But it has always been our intention that we would document the Uniface 10 dictionary when complete (with Uniface 10.3). Even if we did not, we can’t stop access to those tables. So to put an end to any more fake news..

  But as all of us know, since the very old days, variable length fields in the DICT are not stored in different database fields, but they are all mashed together and maybe scattered in the nice OVERFLOW tables as well. So individual information can not be reached so easyly. I already created my own DICT in Sep-2016 and found some incompatibilities with the U9 dict reports. Perhaps they are gone with the official 10.3 DICT, but it is worth to migrate a handful of DICT reports (especially those using COMMENT fields) and see if they still do their job.

We've migration tested 30 or so different customer apps with the goal to make the transition as smooth as we can make it. Getting our hands on those apps, and the subsequent questions and conversations has been a good exercise. We intend to have a webinar session on this.  There could well be some steps we could not automate in some 'edge cases'. These have typically been because in previous migrations, certain steps were not taken, or as a consequence of making updates directly in the repository at some time or another. Making the move to the new repository as hassle free as we feasibly can do has been a consideration from the beginning of the project As I've said at a few user group sessions, a lesson learnt from previous migrations where we could have done better. Mitigating this risk was the reason why we chose not to remove overflow tables. Starting from new is one thing, but migrating existing repositories is something different. 


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

Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement