Re: Object Authority for SQL Use

On Dec 22, 2016, at 10:25 PM, Welly@OCBCNISP <Welly@xxxxxxxxxxxx> wrote:

Hi All,
Many thanks for the update and the enlightment..
But one thing for sure, which authority to give?
Since I already try to give *USE directly (let say we are not using any
grpprf or autl) and Already try to give *use to the object directly.. The
error is still no authority
Try to give *Change and even *all to object, the error still the same.
Aldy give Grant Select to file last night, still hit the same error
==> WEBSTMT_ES_FILEXX:Error: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB
error has occurred. Error code: 0x80040E14.
An OLE DB record is available. Source: "Microsoft DB2 OLE DB Provider"
Hresult: 0x80040E14 Description: "The user does not have the authority to
access the host resource. Check your authentication credentials or contact
your system administrator.".


Thanks for your help

Br,
Welly Soegiantoro
EST Division

cug : 367090

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dean
Eshleman
Sent: Jumat, 23 Desember 2016 00.51
To: Midrange-L Mailing list xxxx <midrange-l@xxxxxxxxxxxx>
Subject: Re: Object Authority for SQL Use

Here is how we have solved this issue. We use a combination of
authorization lists and group profiles. Each file has its' own
authorization list with the same name as the file. We assign groups to the
authorization list. If we want to group files together for some reason like
query access, we create a group profile and add it to the authorization
list. Then, we change the user profile and add this group as a supplemental
group. It may not be a perfect solution, but it works for us.

Dean Eshleman
Software Development Architect

Everence Financial
1110 North Main Street
PO Box 483
Goshen, IN 46527
Phone: (574) 533-9515 x3528
www.everence.com<http://www.everence.com/>


On 12/22/2016 9:52 AM, Andrew Lopez (SXS US) wrote:

Have more than one authority list...

Instead of PRODDATA have
ORDDATA
GLDATA
APDATA
ARDATA

However many groups that are required.

And you should have your users assigned to group profiles.

Group profiles are then given access via the authority list.

We have the group profiles/authority list cross reference. But the

approach of having an authority list for each unique combination of users
would be very problematic. We're long past the stage where our production
data could be broken into just a couple dozen categories. For our E1 data
libraries alone, I have dozens of users authorized to query only
one/two/three files. Each time I added a new user for a new interface, I
would further be breaking down the groups:

- MANDATA starts for manufacturing data,
- MANDTAJOBP gets broken off for an interface with a 3rd party
scheduling software
- MANDTALAB needs some of the same files as MANDTAJOBP for an interface

with lab software, but others as well. I'm now faced with an authority list
for files that both Job Pack and the Lab software can use, another for the
ones that just Job Pack can use, and a third for the ones that the Lab
software needs. Oh wait, job pack needs to update one file, and the lab
software another file, but neither one should have update rights to any
other files.

I'll pass. I already have 160 authority lists for grouped library/library

object authorities, and a total north of 220 counting all the TAA Tool ones.

_____________________________________________________________________
Spirax-Sarco Engineering Plc. This e-mail has been scanned for
viruses by Verizon Business Internet Managed Scanning Services -
powered by MessageLabs. For further information visit
http://www.verizonbusiness.com/uk

______________________________________________________________________
Confidentiality Notice: This information is intended only for the individual
or entity named. If you are not the intended recipient, do not use or
disclose this information. If you received this e-mail in error, please
delete or otherwise destroy it and contact us at (800) 348-7468 so we can
take steps to avoid such transmission errors in the future. Thank you.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD


--
Disclaimer :
Confidential information may be contained in this message.
If you are not the intended recipient, you are strictly prohibited and
may be unlawful to use, copy, store, distribute, disclose or
communicate any part of it to others and you are obliged to return
it immediately to sender or notify us and delete the e-mail and any
attachments from your system. Opinions, conclusions and other
information in this e-mail that do not relate to the official business
of any PT Bank OCBC NISP Tbk shall be understood as neither given
nor endorsed by it. No assumption of responsibility or liability
whatsoever is undertaken by PT Bank OCBC NISP Tbk in respect of
prohibited and unauthorised use by any other person.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD