Re: Changing USER_TAB_COLUMNS Synonym

Have you tried herding cats? That's much more rewarding

f/r,
Gus

Gus Spier
Gus.Spier_at_gmail.com

540 454 3074

> On Oct 18, 2016, at 12:01, Sweetser, Joe <JSweetser_at_icat.com> wrote:
>
> Well, it is called “dual”. J
>
> FWIW, I am of the ilk to create a separate, distinct private synonym for the developers and not muck with the data dictionary.
>
> -joe
>
>
> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Howard Latham
> Sent: Tuesday, October 18, 2016 9:55 AM
> To: jeff.d.smith_at_oracle.com
> Cc: jack.applewhite_at_austinisd.org; Oracle-L <oracle-l_at_freelists.org>
> Subject: Re: Changing USER_TAB_COLUMNS Synonym
>
> I drove 400 miles to a plant in the North of England once to find they had two rows in dual!.
>
> On 18 October 2016 at 16:39, Jeff Smith <jeff.d.smith_at_oracle.com> wrote:
> I spent 3 days recently trying to help a user yelling that our app was broke…and it was bc they create a local DUAL table.
>
> Maybe I’m too gun-shy here. But still.
>
>
>
> From: Jack Applewhite [mailto:jack.applewhite_at_austinisd.org]
> Sent: Tuesday, October 18, 2016 11:37 AM
> To: Jeff Smith <jeff.d.smith_at_oracle.com>; Oracle-L <oracle-l_at_freelists.org>
> Subject: Re: Changing USER_TAB_COLUMNS Synonym
>
> I'd say it's not a lie, but an expansion of available data. Still accurate for the User's schema, but adding other schema's tables accessible to the User. An expansion of available data that the User is needing. Seems to me to be a perfect use of a private synonym when a code change isn't possible or very difficult to implement.
>
> --
> Jack C. Applewhite - Database Administrator
> Austin I.S.D. - MIS Department
> 512.414.9250 (wk)
>
> I can't help about the shape I'm in,
> I can't sing, I ain't pretty and my legs are thin.
> But ... -- "Oh Well" F.M.
>
>
> From: Jeff Smith <jeff.d.smith_at_oracle.com>
> Sent: Tuesday, October 18, 2016 10:29 AM
> To: Jack Applewhite; Oracle-L
> Subject: RE: Changing USER_TAB_COLUMNS Synonym
>
> I ask for my schema’s columns, and I get all the columns in the database
>
>
>
> Maybe the database isn’t broke, but it’s lying to me.
>
>
>
> From: Jack Applewhite [mailto:jack.applewhite_at_austinisd.org]
> Sent: Tuesday, October 18, 2016 11:26 AM
> To: Oracle-L <oracle-l_at_freelists.org>
> Subject: Re: Changing USER_TAB_COLUMNS Synonym
>
>
>
> I second that. It's just a single private synonym. I see no possibility of "breaking the database" as another reply put it.
>
> --
> Jack C. Applewhite - Database Administrator
> Austin I.S.D. - MIS Department
> 512.414.9250 (wk)
>
> I can't help about the shape I'm in,
> I can't sing, I ain't pretty and my legs are thin.
> But ... -- "Oh Well" F.M.
>
>
>
>
>
> From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on behalf of Powell, Mark <mark.powell2_at_hpe.com>
> Sent: Tuesday, October 18, 2016 10:21 AM
> To: Oracle-L; oracle_at_1001111.com
> Subject: Re: Changing USER_TAB_COLUMNS Synonym
>
>
>
> Dave, I do not see a problem with modifying a specific username to give them different visibility to database objects if changing the application itself is not really an option at this point.
>
> From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on behalf of Dave Morgan <oracle_at_1001111.com>
> Sent: Tuesday, October 18, 2016 10:56:57 AM
> To: Oracle-L
> Subject: Changing USER_TAB_COLUMNS Synonym
>
>
>
> Hello All,
> Does anyone know of bad consequences or side effects to altering
> a single schema's USER_TAB_COLUMNS synonym to point at ALL_TAB_COLUMNS?
>
> Our sophisticated developers used a data owner schema in their ORM to code
> against and since they don't have access to those accounts in production ........
>
>
> --
> Dave Morgan
> Senior Consultant, 1001111 Alberta Limited
> dave.morgan_at_1001111.com
> 403 399 2442
> --
> http://www.freelists.org/webpage/oracle-l
>
> Oracle-L mail list - FreeLists
>
> www.freelists.org
>
> Welcome to Oracle-L_at_FreeLists.org An unmoderated forum for the discussion of anything to do with using Oracle databases. Maintain your subscription:
>
>
>
> Confidentiality Notice: This email message, including all attachments, is for the sole use of the intended recipient(s) and may contain confidential student and/or employee information. Unauthorized use of disclosure is prohibited under the federal Family Educational Rights & Privacy Act (20 U.S.C. §1232g, 34 CFR Part 99, 19 TAC 247.2, Gov’t Code 552.023, Educ. Code 21.355, 29 CFR 1630.14(b)(c)). If you are not the intended recipient, you may not use, disclose, copy or disseminate this information. Please call the sender immediately or reply by email and destroy all copies of the original message, including attachments.
>
> Confidentiality Notice: This email message, including all attachments, is for the sole use of the intended recipient(s) and may contain confidential student and/or employee information. Unauthorized use of disclosure is prohibited under the federal Family Educational Rights & Privacy Act (20 U.S.C. §1232g, 34 CFR Part 99, 19 TAC 247.2, Gov’t Code 552.023, Educ. Code 21.355, 29 CFR 1630.14(b)(c)). If you are not the intended recipient, you may not use, disclose, copy or disseminate this information. Please call the sender immediately or reply by email and destroy all copies of the original message, including attachments.
>
>
>
> --
> Howard A. Latham
>
>
> Confidentiality Note: This message contains information that may be confidential and/or privileged. If you are not the intended recipient, you should not use, copy, disclose, distribute or take any action based on this message. If you have received this message in error, please advise the sender immediately by reply email and delete this message. Although ICAT, Underwriters at Lloyd's, Syndicate 4242, scans e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. Thank you.

--
http://www.freelists.org/webpage/oracle-l