No doubt: move directly to 9.3 !

You can take benefits from new issues and there are no disadvantages:

- Easy deploy

- Dynamic grid columns labels

- Transparency on editboxes

Really no great dfferences between 9.2 and 9.3.

In this moment our Uniface based E.R.P.   is in "general avaliability" with 9.2 (we published in september 2008) and we are working for the new release with 9.3 (June 2009)

P.S.

unofficially you can switch from 9.3 to 9.2 and back again.

I did it and it works, simply rename Unface folder and pay attention to dol and urr files version.

Luck

Hi Peter,

What are you doing the other 2 days? I think 3 days are too much for a formal 8 -> 9 Migration. ;-)

To be honest, the removal of _ or adding $ are at least cosmetic work. For applications only "keeping alive" it is not necessary. For applications which will be developed and deployed in future, the automatic removal helps reducing warnings, not getting better quality in code!  For older historical grown code it is much better to rewrite parts of the code using new V8/V9 concepts...

We have an application with several thousands of components, and the migration process of the development-area run over night. As far as I remember, we had no problems. Since we did it very early (9.1.) I think one or two minor bugs in uniface, which were solved very fast.  9.x. -> 9.x+1. : (x € {1,2,3} ): No problems at all.

Wolfgang

Hi there,

Why not move up to 9.3? Or why not wait for 9.4 to arrive?

Do you have USP? Then is might be wise to wait for 9.4.

kind regards,

Peter

Hi Peter,

The reason that we would not move to 9.3 is that I have found that keeping always at least one version behind the latest is, for the most part, more 'tested' by the wider community, and more bugs have been spotted and fixed by the time we arrive at this version.  Experience shows me this.  In fact, this is exactly the point that I want to dismiss.  I really do want to move up to 9.3, but I wanted to hear from others of their trials and tribulations of 9.3 compared to those of 9.2.

We do not have USP at all. Our application was originally 6 --> 7 --> 8 (and now) --> 9 with a very high dependancy on Sybase.  This latest move for us is simply to keep up with supportability.

I would not wait until 9.4, as I am sure that some others too wouldn't, until it has been 'tested' by the wider community in production arenas.  This is the pessimist in me speaking... it's safer this way :) .

But I would love to hear comparisons between 9.2 and 9.3 with regards to stability and perfomrance as well as user stories (with happy and unhappy endings) of each of these versions.

Thanks

Hi Disco,

The situation here is almost simular. Biggest difference is that we do have USP's and left them in Uniface 8. The clientserver and batch part is migrated to Uniface 9.2.02. We did that last summer. Because we have some issues with the maximum number of URouter processes, we are rolling out step by step. About 10% of our users is using the application in 9.

The migration was not very hard to do. Some minor issues, but noting more than is already documented in the migration guide. We also did some enhancements to the gui. For instance, we introduced the grid widget. One advice, try not to combine the technical migration with a functional one. Now our users complain about the colors. The 'old' Uniface forms are rather dark grey. Now the backgroundcolor of the forms is far more lighter. And the grid background is white. The precious and sensative eyes of the user just cannot handle the more Windows like colors....

Uniface 9.2.02 is stable. We did not ran into strange behaviour. We see no reason to go to 9.3. We are going to 9.4 as soon as possible, but that is because of the DSP's.


kind regards,

Peter

Hi Peter,

I am also intrigued that users can not adjust their eyes as fast as developers :)

Thanks for your input. Have you heard of any success or failure stories for a U8.4 --> U9.3 migration?

Thanks

We work currently on a migration 8.4 to 9.3 unicode database with Oracle.

Next week, I work on some tests and currently, the status on the migration is OK.

Do not hesitate to change your code before to change old instructions by new instruction (rtrim,...) if exists in U8.4 See documentation of U9.3

Some old instructions are available on U8.4

Regards,

Antoine

Thanks Antoine,

We do have a lot of changes for scan/$scan, idpart/$idpart, etc.  I think we will get the new Uniface developer to do that tedious stuff :)

Please let me/us know how your migration goes.  I would like ot hear the whole story once you are complete.

Thanks

We do have a lot of changes for scan/$scan, idpart/$idpart, etc.  I think we will get the new Uniface developer to do that tedious stuff :)

Hello Disco,

We have tools for source code migrations that automate all that tedious stuff.

Contact me when you are interested.

Theo Neeskens

Hi Disco,

Any luck, yet?
We went into production with the Uniface 9 part of the application. Everything works perfect!
Now we have a webapplication in Uniface 8 and the clientserver users use Uniface 9. To be honest, some users still use the Uniface 7 application. All use the same database (SQLServer) and share the same components. Ofcourse we have 3 repositories, but most services and hidden forms (yes, we come from Six) are migrated without any code change. Just an export and an import. You can use Uniface 7 and 8 code in Uniface 9. Even the changed statement like fieldsyntax and idpart are the same. Uniface 9 compiler shows a warning, but it still works.
Within a few weeks all users must use the Uniface9 application. Most likely we'll change all 'old' statements after Uniface7 is no longer needed. We did a trial conversion: compile the components in U9, make a list of all warnings, make an export, open the export in Textpad (or whatever texteditor you like), find and replace all statements from the writtendown warning, import in a fresh repository and compile. To get rid of those syntax warnings, we did about a 100 components in 30 minutes.  In all cases it was enough to put a '$' or remove a '_'.

I know, this is just a small application. Within a few week we are doing a test migration of an >1000 components application. We planned to do this in 3 days....

kind regards,

Peter

Hi Peter,

In some older migration projects, I created some awk-scripts
to scan *.pro files and the $putmess logfiles and remove "unimportant" information.

The filter was based upon a "migration manual: modifications to be done" where I collected all known changes.

On the other hand: if you already know what needs to be changed, I would suggest the following procedure:
Export your application in some XML-files with a workable size.
Load the XML-exports in an editor which supports prompts before a replace is done so you have control about the changes.

And the comes the stupid job:
replace any "idpart" with "$idpart" ....

Just use the filetered protocols to check if something has been overlooked,
but do NOT use it as a working list

We gained speed working without todo-lists (because you are focused  on a single modification at the time)

Would be nice to hear from you what modifications needs to be done in your migration process
and what your test have showed later on (in a dITo-collection?)

SUccess, Uli

Sounds like a win for you Peter.  A great success.  And  a piece of cake too... always a bonus when it runs smoothly.

We have decided that we will go to 9.3.  We plan to have it done in September.  I will keep you informed of our progress.

Thanks