Oracle Observations

November 18, 2012

11g forms error

Filed under: 11g,Oracle forms — bigdaveroberts @ 1:21 pm

After migrating to 11g we encountered the following error in 2 of our forms after migration to 11g:

Error 801 at line 0, line 0
internal error [phd_get_defn:DI_U_NAM_RHS]
Error 908 at line 0, column 0
The stored format of <schema name>.<Procedure name> is not supported by this release.

I believe that the issue related to compiling in form code that called database packages that had dependencies in other databases.

But that isn’t important, there was one hit on the OTN forum that correctly pointed me at the correct Metalink article and patch:

So the problem is described in article 1058803.1 and resolved by 7708340.

So ultimately the problem doesn’t seem to require a blog post.

There was however one anomaly  the patch is a database patch and the read-me implied that the patch needed to be applied to the Weblogic server also the patch was relatively speaking large.

I have to admit I was highly dubious about applying a database patch to the middle tier so I went ahead and applied the patch to my development PC, and to my great surprise, it worked.

It also appears that technically you don’t need to apply it to the middle tier, it simply needs to be applied to the PC on which the forms are compiled, although obviously it would be good practice to keep the development PCs and server environments in sync with the live environment.
So sometimes, however unlikely it sounds, Oracle instructions are sometimes accurate straight out of the tin!

November 17, 2012

Oracle forms 11g, OLE2, Windows 2008 R2 64bit issue. (Possibly.)

Filed under: 11g,OLE,Oracle forms,Uncategorized — bigdaveroberts @ 10:12 pm

For clarity, its definitely a forms issue and It’s definitely an OLE2 issue.

But the rest is speculative.

The application was developed to produce reports as Excel spreadsheets using OLE2 to to populate the cells with data.

This was originally developed under Forms 6i and was successfully migrated to Forms 10g using the middle tier to generate the spreadsheets and then pass it back to the user using the same mechanism (WEB.SHOW_DOCUMENT) as used to pass oracle reports back.

Upon migration to Forms 11g this implementation still worked using 32bit windows server 2003 for the middle tier, but when we moved to 64bit Windows Server 2008 R2 the process failed.

We could see Excel being invoked, but it ran only briefly and then terminated without generating a spreadsheet or logging any form of error that we could find.

I tested using my development environment under windows 7 64 bit and the functionality worked fine.

So, it was back to Sysinternals process monitor ( to try and work out the difference in behavior.

My expectation was that it would be some obscure registry setting that would be the cause, in fact the behavior diverged after an attempt to read the following directory:


Strangely this directory was also missing on my windows 7 PC but it was present on windows server 2003.

I copied the desktop directory and its contents from the windows 2003 server to the windows 2008 server and the problem disappeared.

I then deleted the contents of the desktop directory and the Excel spreadsheet was still successfully generated.

So in conclusion, I guess, that when Oracle implemented it’s forms OLE2 interface, they based it on configuration information that is no longer present on 64 bit Windows Server 2008 R2.

However I am uncertain as to when that directory disappeared.

There is also the issue that on my development machine the problem didn’t manifest itself, indicating that the problem may be more complex than this initial investigation has exposed.

As a last observation, the closest I’ve come to an official document that hints at being related on Metalink is:


Although there is no explicit reference to OLE2 and the bug appears unresolved.

Not quite the conclusive conclusion that I like, but interesting enough for a blog post.


Create a free website or blog at