Versioning forms and comparing sourcecode

Comparing sourcecodes of different versions of the same FMB is very important while developing an application or during maintenance.

If you want to store all versions of your FMB's, then they are two ways:

Manual versioning

Each version of all files is stored under its name plus the versionnumber. E.g. emp_27.fmb, emp_28.fmb, ... In this case "emp" + "_27" + ".fmb".

Parallel to each version you store the textversion of the FMB, emp_27.txt, emp_28.txt and so on. You get the textversion in forms through Edit-Administration-"Object list report".

For viewing the changes between two versions you can use tools like Beyond Compare, my favorite compare tool.

Using Subversion, Git or another VCS

Using a version control software is the other approach. But here we have the problem, that storing the binary file in tools like Subversion didn't solve our origin problem, finding sourcecode differences between two versions. Storing the textversion of the binary FMB plus the forms FMB is here the best practice for the check-in.

If we now want to see the changes between two version, we can easily use the builtin features of the versioning tool:

just use it
Gerd

The future of Oracle Forms

In the last days of 2010 the German Oracle User Group asked me to write an article for the april edition of their magazin.

First I thought, that I write a normal deep technique article like all the others in the last years.

But then I reconsidered and found a better topic: "The future of Oracle Forms"

This article has two main parts. The first one gives an outlook, what Oracle integrates in the new Oracle Forms 12 release and the second part is result of a german wide poll, which I start this week.

The poll should give us an overview, what the german forms developer think about their development tool, which version they actually use, how long they work with Forms and what they think about the future of Oracle Forms

I'm very interested in the results of this poll
Gerd