Re: Changing USER_TAB_COLUMNS Synonym

​no it happened they imported the app code twice select * from dual;
x
x

two rows selected
cant say who just think oil.

On 21 October 2016 at 18:03, Dave Morgan <oracle_at_1001111.com> wrote:

> Hi All,
> Wow, just wow. Comments and more details about the situation are
> inline.
> Please forgive me for the snarky ones and treat them as (poor?) DBA humour.
>
> Thanks to Mark P, Jack A, Matt P, Jeff S, Kellyn P, and Howard L.
>
> From: Dave Morgan <oracle_at_1001111.com>
>> Date: Tue, 18 Oct 2016 08:56:57 -0600
>>
>> 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
>> ........
>>
>
> --
>
>
>> Instead of hacking the data dictionary, why not just fix your
>> application? Breaking the database for
>> just the app instead of fixing the app doesn't seem like a good idea.
>>
>
> Good idea? Six figure cost and a production database rollback were
> involved. I hate rollbacks.
> I did not want to trust my sophisticated developers rushed fix if I had a
> rushed fix of my own.
>
> Also I like being the fscking hero who saves the day instead of Da Biggest
> A****** around. :)
>
> how about changing the mindset of your developers?
>>
>
> If you could provide a 3-10 page document describing how to achieve this
> objective it
> would be extremely helpful and greatly appreciated. Based on the responses
> on this list,
> I think once the effectiveness of your method was proven it would make you
> at least $US 50,000.
>
> 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.
>>
>
> No it's not. Setup up private synonyms that point to the public ones.
> If you don't have the privs to do that then the DBA has done that for a
> reason.
> Make nice and go ask him why. Otherwise, ask yourself why you haven't
> fixed it.
>
> 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.
>>
>
> I just felt a very similar pain. Even while helping them I was killing my
> self laughing.
> There is no such thing as "too gun shy" to a production DBA
>
> There is a very valuable rule that DBAs [especially] always need to
>> remember- “Just because it seemed like a simple change doesn’t
>> mean it wasn’t impacting. Think globally, isolate locally.”
>>
>
> Amen brothers and sisters, amen
>
> I drove 400 miles to a plant in the North of England once to find they had
>> two rows in dual!.
>>
>
> Excellent, I always thought the "2 rows in dual" story was apocryphal.
> Thank you.
>
> Summary, we adde3d the private synonym, everything worked, the development
> team will deliver
> the proper fix within 72 hours. The hero has left the building, the DBA is
> back. He was heard
> questioning whether 72 hours was a reasonable time line.
>
> Have fun all!
>
> Dave
>
> --
> Dave Morgan
> Senior Consultant, 1001111 Alberta Limited
> dave.morgan_at_1001111.com
> 403 399 2442
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

-- 
Howard A. Latham

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