Question Compile Trouble - Maybe Because Of Table Privileges.

[ron]

OE 10.1C enterprise + Solaris 10

I sometimes need to recompile all the .p files in two directories - close to 1,300 files in total and I'm developing a script to do it. It works fine for most programs - but for some I get an error like this:

/fms/apps/releases/bprepl/repl_w/wfmscont_mnferror.p ERROR! ** Insufficient access privilege for table . (234)
** /fms/apps/releases/bprepl/repl_w/wfmscont_mnferror.p Could not understand line 14. (196)

The only thing I can see to explain this is that each one that fails references a table that has a value in _File._Can-write of "!,*" - whereas those that do compile correctly have a value of "*". This is not something I'm familiar with - but I'm guessing that the "!,*" prevents updating unless the user id is known.

I'm running the script with root privilege. How do I provide a user id to a run of _progress?

Ron.
(BTW - Upgrading to 11.6 is happening.)

 

[TomBascom]

-U

 

[ron]

Thank you Tom. (I should have worked that out for myself!)

Unfortunately, however, it has not solved the problem - even after providing a valid user and password I still get the same error.

Any suggestion welcome on how I can fix this.

 

[ron]

I have done more testing. The problem happens for each table where Can-read is set to "!,*" (rather than "*").

To isolate the problem from the script I'm testing - I have tried compiling using the Data Dictionary and I get exactly the same result - failure for any table where Can-read is "!,*".

 

[RealHeavyDude]

!,* means that everybody except a blank userid has access to the tables. I'll take it that you login ( setuserid ) failed. It depends on how you are authenticating against the database. If you authenticate against the _User table then you need to supply -U ( user name ) and -P ( password ), both capital letters as this is case sensitive.

You can try something like

message setuserid ( "username", "password", [ "logicaldatabasname" ] ) view-as alert-box.

when you are able to connect to the database interactively and run a procedure editor. As long as setuserid does not return true you're not authenticated against the database.

We have our database security set the exact same way except that we use a client principal object to authenticate against the database. Works without a fuzz for us.

Heavy Regards, RealHeavyDude.

 

[ron]

Problem solved.

It was due to my lack of familiarity with table security .... I didn't appreciate that I needed to separately specify -U / -P for each database. Once I fixed that everything works just fine.

Thanks for your help everyone!

Ron.