Oracle Observations

December 14, 2010

A niggling problem with Reports (6i) that I’ve finally got to the bottom of.

Filed under: Uncategorized — bigdaveroberts @ 5:51 pm

Since starting to use an installation of Forms and Reports 6i installed on a terminal server, I have always received the following error when logging on:

REP-0004: Warning: Unable to open user preference file.

I have search for the message online, and have found several pages where this error is mentioned and they all give solutions based around ensuring that the file prefs.ora was in the correct location and was accessible.

Having located a copy of this file on the server I proceeded to copy this file to every location I was recommended, and several more I wasn’t, I hadn’t got rid of the pesky error.

Normally my approach would be to run filemon (formally from sysinternals, latterly from Microsoft and even more latterly replaced by process monitor.) However, as I didn’t have administrator privilege on the server, this wasn’t (at least directly) an option.

However, as the Oracle developer installation was on a shared drive, with an export of the Oracle registry tree a shortcut and a little tinkering I was able to run Forms from my laptop.

NB. I’m glossing over some of the little minor difficulties of using a laptop with Windows 7 on. Essentially a little download and installation of XP mode was involved, my experiences with which will be the source of at least one other blog post.

So having run Oracle Reports from my laptop and received the expected error, I ran process monitor and having filtered out all the information about unrelated processes I was unable to identify any information relating to the file prefs.ora.

This wasn’t entirely a surprise, as the file was already located in six directories, however what was apparent was an attempt to open a directory that didn’t exist.

After a search in the registry it became apparent that this directory was associated with the registry key:


So after creating the directory listed in the registry entry, Reports opens without error and a new file appears: cauprefs.ora containing reports configuration information.

So with a visual inspection of the file, it is apparent that some of the setting would not be appropriate to be shared between multiple Terminal services users. (eg. Reports.MRU_files)

Thus with the amendment of the registry setting to point to a mapped personal drive and the movement of the cauprefs.ora file to the new location, everything’s sorted!

So, prefs.ora? Perhaps this is a historical file, or perhaps it is only opened after the cauprefs.ora file. There is also the cagprefs.ora file whose location is controlled by the associated registry setting CA_GPREFFS registry setting which I suspect could in theory give the same or similar problems.

The final note, from the documentation, cagprefs.ora appears to be for global preferences and is designed to be shared between all users, while the cauprefs.ora file contains user preferences that (assuming Reports can locate the file.) override the global settings.

Go figure! (Or configure!)


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at

%d bloggers like this: