Invalid operation when using utl_file fopen

I'm encountering an invalid operation error when using utl_file fopen. The directory I'm trying to write to is listed properly in the utl_file_dir parm in init.ora and we've verified the read / write permissions on the Unix operating system. Not sure what else could cause this. Any info would be appreciated.

Thanks.
Richard.
rlwremoAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
jtriftsConnect With a Mentor MI and AutomationCommented:
I have experienced the same problem onn occasion.  There are several things to consider:

1. Oracle must be able to see the directory.  Thus the utl_file_dir must have the FULL location or '*'.  Remeber, Unix is case sensitive, so the case of path is essential.

2. Applicable privileges on the directory and file must be granted to the Oracle user.

3. The file name and path in the procedure using utl_file must be accurate:
DECLARE
v_location          VARCHAR2(200) := '/users/app/oracle/product/8.1.5/admin/Data_Location';
v_filename          VARCHAR2(200) := 'your_data_file.dat' ;
   v_file_handle       UTL_FILE.FILE_TYPE;
BEGIN
   v_file_handle := UTL_FILE.FOPEN(v_location,v_filename,'r');

LOOP ...

I have found the most common errors to be with the utl_file_dir (which you say you have already checked), and the wrong case of the location of the file.

Unfortunately, invalid_operation seems to be a catchall for FOPEN, even though technically, FOPEN can raise many different errors.

Can you confirm that the both the case of the file directory (in both utl_file_dir and in the calling procedure) and the file name referenced in the calling procedure all have the correct case?

One point on security: If you set utl_file_dir to * and don't have strict directory and/or file permissions within your unix structures, you leave yourself open to others breaking in via Oracle and grabbing and or writing data).


0
 
mshaikhCommented:
Make sure that you can login in to the uinx box with the 'oracle' OS user account and do a cd to the dir in question and also check if you can actually create a file there. Also, make sure that you don't have the sticky bit set.
0
 
jtriftsMI and AutomationCommented:
ONe more thing...the database server is on the same unix box as the file you're looking for, right?
0
 
rlwremoAuthor Commented:
Well,

It turns out that it was a permissions problem. Even though we opened up permissions all the way (I think 777 is the term) those permissions didn't cascade down to existing files. Just on a whim I deleted the file we were trying to use and found that the permissions were still set to a more limiting profile. After that, our write routine was able to recreate the file with no error.

Thanks to all who responded!

Richard.
0
 
jtriftsMI and AutomationCommented:
Glad to be of service!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.