Skip to Main Content

DevOps, CI/CD and Automation

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Oracle 12.2 ODBC driver installation on MacOS with unixodbc

dseverskiFeb 9 2018 — edited Feb 23 2018

I've had a devil of a time figuring out how to get the 12.2 Oracle Instant Client (Basic Lite) and ODBC drivers working under MacOS Sierra. Repeating some content from https://stackoverflow.com/questions/48635297/how-to-get-macos-oracle-odbc-client-working-with-unixodbc , I've extracted the Basic Lite client and ODBC file to /opt/ora12/ and setup the symlinks to /usr/local/lib, but when I point a DSN to the libsqora library, the connections always fail. Looking at the lib with `otool -L` it looks like some of the dependencies are not being followed, specifically all those linked with `@rpath`. If I pull down the 12.2 SQLPlus client, extract that into /opt/ora12, that is able to find all the libraries fine, but I don't know how to get unixODBC to do the same when it's @rpath doesn't know about my /opt/ora12 location.

Any pointers/docs on where I'm going wrong would be super appreciated. I'm not very familiar with DYLIB loading under MacOS so I'm likely misunderstanding something basic here.

David

This post has been answered by Sdhamoth-Oracle on Feb 20 2018
Jump to Answer

Comments

Gianni Ceresa

Honestly for me it sounds "obvious" that the "keep it stupid simple" approach is the one to use.

All the 3 have different meanings, provide different answers for different requirements.

For a "standard" outer join you definitely must start by the one in the Business model diagram, when you draw the join between Fact and Dim, that's a standard simple outer join between a fact a dimension.

This is also the easiest to maintain.

If you start playing with LTS I would say you must a real need and model built to work in that way.

Just for the example: adding you dim in the fact LTS => your dimension is into the Fact logical table, you don't have a dimension anymore. Without a dimension OBIEE will not validate your model.

With the opposite you are bringing fact columns into the dimension, if you don't add at least a column of the fact table source into the logical table of the dimension you have a warning.

Both these solutions are not clean, generate warning during the consistency check and are a perfect source of huge issues in the future when you are going to expand your model.

PS: do we agree you must not have a single warning in your RPD, right? (not that it doesn't work with warnings, but doings things right now it's the best way to avoid problems tomorrow)

1 - 1
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Mar 23 2018
Added on Feb 9 2018
11 comments
7,594 views