Application Security problem in 710G1

[Ohmes, Matt]

Hi Kent,
Hmmm.  That Master file is only being used for Read access?  Then that may
be your problem.  When Quick sees a Master file, one of the assumptions it
makes is that the Master file was a Primary or Secondary file on the
previous screen and therefore is "updateable". So it normal Update
processing will attempt a PUT against the Master file.  

How is the file declared on the calling screen?  Is it a Primary, Secondary,
or Detail file?  Or is it a Designer or Reference file.  If the file is
opened for READ access on the calling screen, then passed to a subscreen and
declared as a Master file, you will get the message you mentioned when you
attempt an update on the subscreen.

IF the file is declared as a Designer with Read only access or as a
Reference (which implies Read only access), then also declare the file as a
Designer or Reference file on the lower subscreen too.  That will take away
Quick's assumption that it is updateable.

If this is your problem, then I don't know why you didn't get the error on
earlier releases.

Hope that helps.
Matt :-)

Matt.Ohmes@Cognos.Com
Cognos Corporation
909 E. Las Colinas Blvd.
Suite 1900
Irving, TX  75039
214-259-6200
"Matt doesn't really know anything.  He just likes to pontificate a lot.
We refuse to acknowledge that he works for Cognos or that we have ever
met him or anyone with whom he's ever been associated.  Don't lend him
money and don't let him talk to your sister!" ;-)


-----Original Message-----
From: KHeathe673@aol.com [mailto:KHeathe673@aol.com]
Sent: Thursday, April 15, 1999 10:23 AM
To: powerh-l@lists.swau.edu
Subject: Application Security problem in 710G1



I seemed to have stumbled into a 'new to 710G' behaviour with regards to 
application security.

The screen I have a problem with, has not been touched since 1992, and thus 
has
survived previous PowerHouse upgrades unscathed.  And yet, the 710G1 upgrade

has caused it grief.

What has happened is that for some reason application security is now being
checked on a MASTER file, regardless of what access to that MASTER file
takes 
place in the screen.

In this example, the MASTER file, is simply used to establish ACCESS to the 
PRIMARY file.  No ITEM statements, LET OR ACCEPT verbs exists for the FILE.

The user does not have WRITE access to the MASTER file.  He does have READ.
Suddenly, the screen fails with the message

"You are'nt authorized to update data in this field"

Take out the MASTER file and all is well.  Funny when I ran the debugger,
the 
message actually appears on a LET verb for an unrelated DESIGNER file.

But clearly, something is amiss with MASTER files and APPLICATION SECURITY.

Just wanted to share my findings....

Kent Heatherington
Pont Rouge Systems Inc.
Fort Coulonge, Quebec (WE'RE GETTING SNOW THIS WEEKEND !)
(wish I was back in Texas !)


= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.