ANSI/ISO JOIN SYNTAX

DEAR Friends,
How can i write the ansi/iso syntax for below query
select a.company,b.fpm_ac_code from facmast a,fparty b, fstatus c
where a.company = b.company(+)
and a.fac_ac_code = b.fpm_ac_code(+)
and a.company = c.company(+)
one method is
select a.company ,b.fpm_ac_ccode from facmast a right outer join fparty b on a.company = b.company
and a.fac_ac_code = b.fpm_ac_code
,facmast c right outer join fstatus d on c.company = d.company
but this is equivalent
select a.company,b.fpm_ac_code from facmast a,fparty b,facmast c, fstatus d
where a.company = b.company(+)
and a.fac_ac_code = b.fpm_ac_code(+)
and c.company = d.company(+)
pls help me
Siddharth singh

I would transpose this statement...
select a.company, b.fpm_ac_code
from facmast a, fparty b, fstatus c
where a.company = b.company(+)
and a.fac_ac_code = b.fpm_ac_code(+)
and a.company = c.company(+)
into this...
SELECT a.company, b.fpm_ac_code
FROM facmast a
LEFT OUTER JOIN fparty b
ON a.company = b.company
AND a.fac_ac_code = b.fpm_ac_code
LEFT OUTER JOIN fstatus c
ON a.company = c.company
I think this may be closer to what you want.
Remember, the (+) goes on the side that is deficient in information; but the LEFT or RIGHT keyword points to the table on the side of the JOIN clause (not the ON condition) from which you want information.
Best!

Similar Messages

  • ANSI/9i Join Syntax and Pretty Code

    I've always tried to keep my SQL statement code formatted in a way that I think helps readability. I picked up the following style because I found it easy to quickly find the FROM clause and the JOINS or conditions:
    select e.ename,
           e.sal,
           d.dname
    from   emp e,
           dept d
       * Joins
    where  e.deptno = d.deptno
       * Conditions
    and    d.dname = 'SALES'
    /Of course, for such a simple query I wouldn't have used the comments to divide the WHERE clause into joins and conditions...
    Anyway, since Tom Kyte and the 9i documentation suggest using the ANSI join syntax (amongst other reasons), I have decided to begin changing my ways. However, I am having troubles figuring out how to format my SQL to still be "pretty."
    For the previous example, a new formatting style seems easy:
    select e.ename,
           e.sal,
           d.dname
    from   emp e
      join dept d          on e.deptno = d.deptno
    where  d.dname = 'SALES'
    /Now, when we use an example that has optional joins is where I can't figure what my style should be:
    select e.ename,
           m.ename as manager
    from        emp e
      left join emp m      on e.mgr = m.empno
    where  e.deptno = 10
    /I don't really like this style since it gets so wide, causing problems when indenting for subqueries/inline-views. It also looks kinda clunky because the tables are indented more than everything else...
    Anyway, since I don't want to spend a bunch of time figuring out things like style, I'd like to see what other formats people are using. I'd appreciate seeing how others are formatting thier SQL when using the new 9i (old-ANSI) syntax.
    Thanks, Stan

    That looks to me like left aligned (but I may be on the wrong side of the looking glass...)
    By preference is to left-align the KEYWORDS and the data words, using indentation to distinguish the start of the different clauses (SELECT, FROM, WHERE, ORDER BY, etc.). This approach is easily standardised with Textpad or similar editing tools. Quite how one programs a text editor to turn one's code into a Rorschach blot is beyond me.
    I haven't done much with ANSI joins, so I hadn't come up with a standard for layout. The following is what I think I would do if I ever had to, and is basically an adaption of what I do now ...
    FROM   user_indexes i
           , user_ind_columns ic2
           , user_tab_columns c2with the ANSI join stuff indented and aligned. I find rigourous application of UPPER and lower case tends to assist clarity: indentation and alignment are not enough.
    SELECT i.table_name
           , i.index_name
           , ic2.column_position
    FROM   user_indexes i
           INNER JOIN user_ind_columns ic2
           ON i.table_name = ic2.table_name
           AND i.index_name = ic2.index_name
           INNER JOIN user_tab_columns c2
           ON ic2.table_name = c2.table_name
           AND ic2.column_name = c2.column_name
    WHERE  i.uniqueness='UNIQUE'
    ORDER  BY i.table_name
           , i.index_name
           , ic2.column_position
    /

  • ANSI inner join syntax

    Hi,
    Is there a way to configure BI Server 11g to generate ANSI join sytax ("INNER JOIN" clause) for Oracle, as it does when using OUTER JOINs?
    Thank you.

    OBIEE will not generate ANSI syntax for Inner Joins and as you said it only generates for Outer joins. Hope this clears your doubt.

  • URGENT - need help with ansi/iso outer joins

    Hi,
    I am currently preparing for the OCP sql exam for the 9i developer track and I think a statement is printed wrong in my study book, please could somebody confirm the following:-
    Oracle Outer Join syntax
    from tab_a, tab_b
    where a.col_1 (+) = b.col_1
    ANSI/ISO Equivalent
    from tab_a a left outer join tab_b b
    on a.col_1 = b.col_1
    Should n't the above be a right outer join
    Please could somebody confirm or explain if I am wrong.
    Thanks in anticipation.
    Simon
    Note. The book is OCP Introduction to 9i sql (1Z0-007) page 115 (table 3-1) - author Jason Couchman

    It seems so....
    See
    http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96540/statements_103a.htm#2107297

  • ANSI SQL 92 SYNTAX OUTER JOIN PERFORMANCE ISSUE

    Good Morning
    Could anyone explain why the excution time for these two (ment to be identical)
    queries run so differently.
    oracle syntax execution time 1.06 seconds
    select COUNT(*) from
    PL_EVENT_VIEW pev,
    PL_EVENT_STAFF_VIEW pesv
    WHERE pev.EVENT_ID=PESV.EVENT_ID(+)
    AND pev.WEEKS=PESV.WEEK_NUM(+)
    AND pev.event_id=2520
    ansi sql 92 syntax execution time 7.05 seconds
    select COUNT(*) from
    PL_EVENT_VIEW pev
    LEFT JOIN PL_EVENT_STAFF_VIEW pesv
    ON (pev.EVENT_ID=PESV.EVENT_ID
    AND pev.WEEKS=PESV.WEEK_NUM)
    WHERE pev.event_id=2520
    Thanks
    David Hills

    BTW Oracle outer join operator (+) and ANSI SQL OUTER JOIN syntax are NOT equivalent. Consider following:
    DROP TABLE T1;
    CREATE TABLE T1 (C1 NUMBER);
    DROP TABLE T2;
    CREATE TABLE T2 (C2 NUMBER);
    DROP TABLE T3;
    CREATE TABLE T3 (C3 NUMBER);
    -- Following SELECT works:
    SELECT COUNT(*)
         FROM T1, T2, T3
         WHERE C2 = C1
              AND C3(+) = C1
    COUNT(*)
    0
    -- But:
    SELECT COUNT(*)
         FROM T1, T2, T3
         WHERE C2 = C1
              AND C3(+) = C1
              AND C3(+) = C2
    AND C3(+) = C1
    ERROR at line 4:
    ORA-01417: a table may be outer joined to at most one other table
    -- However with ANSI syntax:
    SELECT COUNT(*)
         FROM T1
         JOIN T2 ON (C2 = C1)
         LEFT JOIN T3 ON (C3 = C1 AND C3 = C2)
    COUNT(*)
    0

  • Flow accept error when using ANSI join syntax

    Hi
    I had a region populated by a query joining two views (one in-line using connect by). When trying to create the region if the join was coded using ANSI syntax (INNER JOIN .... USING) I got a flow accept error when either trying to proceed using the wizard, or apply changes when editing the region.
    After changing to the old style Oracle join (using predicates), I was able to create the region and everything worked ok. I found the solution after reading this post Error 404 wwv_flow.accept was not found in which the OP says he would raise a bug. Did the bug get raised? I ask since his problem arose whilst he was selecting from a view using ANSI joins and using instead of triggers, and I was joining an in-line view to a view using ANSI joins and instead of triggers, but neither view has been changed, just the join syntax. The view defined in the database is used in other regions and works fine. This could indicate the OP's problem was fixed, but one still exists.
    Incidentally this is the only time I have used non-ANSI joins in the entire apex app - the rest work!. Unfortunately it is impossible for me to demo the app.
    Richard
    using ApEx 3.0.1.00.07 and 10g (10.2.0.1) EE on Wintel

    Tyler,
    Apologies, what I was trying to say was that I couldn't put the application on the Oracle APEX site.
    Yes, I do have a work-around, but that does not mean a bug may still exist. I count myself fortunate I saw that post and, therefore, experimented with the syntax of the join - there is no reason APEX should not accept ANSI join conditions, in fact , it does. The ANSI-joined SQL statement executed perfectly in TOAD and SQL*Plus, but I could not even save it in APEX.
    regards
    Richard

  • Difference between oracle join syntaxes and ANSI join syntaxes

    What is difference between oracle join syntaxes and ANSI join syntaxes ?
    why oracle is having different syntaxes for joins than ANSI syntaxes ?
    Also Join syntaxes are different in some oracle vesrions ?

    BluShadow wrote:
    3360 wrote:
    Yes it is. The Oracle database wasn't initially designed to be ANSI compliant. As you correctly state the ANSI standards weren't around when it was initially designed, so the statement is perfectly correct. ;)Ok, in one sense it may be correct but it is a completely misleading statement. Not sure why you think it's misleading.Because there was no ANSI standard, so making it sound like a design choice The Oracle database wasn't initially designed to be ANSI compliant. would suggest to most readers that there was a standard to be compliant to.
    Like saying Ford originally did not design their cars to incorporate safety features such as ABS, seat belts and air bags.
    The OP asked "why oracle is having different syntaxes for joins than ANSI syntaxes ?" and the answer is that Oracle wasn't initially designed with ANSI compliance, so it has it's old non-ANSI syntax,As shown above, the old syntax was ANSI compliant at the time and to call it non-ANSI is either incorrect or misleading dependent on your point of view.
    and since ANSI syntax became the standard it now supports that. And since ANSI switched to a new standard, Oracle had to implement the new standard as well as the previous ANSI standard would be more accurate in my opinion.
    Nothing misleading as far as I'm aware in that.I find the whole discussion about ANSI and Oracle's supposed non-compliance, reads like it was Oracle's choice to deviate from the standards, when it was ANSI's bullheaded decisions to pointlessly change standards that left Oracle and other vendors out of compliance, and that was a decision made solely by ANSI.
    This is probably the reason ANSI no longer produces SQL standards, the endless syntax fiddling would eventually have made forward left under outer joins a reality.
    {message:id=1785128}

  • Use ansi join syntax

    From what i have been reading is better to use the new syntax(dont know how new it is)

    The ANSI join syntax was new to Oracle in Oracle 8i in 1998 - that's 15 years old.
    It can produce more readable code, and is both more readable and less human-error prone for outer joins.
    The ANSI format lets you outer join between multiple tables in a way the old oracle-specific ( + ) syntax did not and introduces FULL OUTER JOIN which you should use very rarely.
    You should not use NATURAL JOIN in code - adding unrelated columns to the tables involved can make it give very different results.
    There have not been significant bugs for ANSI joins in Oracle since Oracle 10.2 was introduced about 8 years ago.
    As Paul said, the ON part should be the join criteria between the tables. The were clause should be the filtering of the joined tables.
    So assuming start_date, end_date and in_property_id are variables
    SELECT resv_num, unit_date
        FROM p_resv_unit ru
        INNER JOIN p_pm_unit_night pun
        ON pun.resv_unit_id = ru.resv_unit_id
        WHERE pun.property_id = in_property_id
        AND pun.unit_date BETWEEN start_date AND end_date
        AND pun.pm_unit_num = cvUnitNum;
    If start_date and end_date were columns in p_resv_unit the query would be:
    SELECT resv_num, unit_date
        FROM p_resv_unit ru
        INNER JOIN p_pm_unit_night pun
        ON pun.resv_unit_id = ru.resv_unit_id AND pun.unit_date BETWEEN ru.start_date AND ru.end_date
        WHERE pun.property_id = in_property_id
            AND pun.pm_unit_num = cvUnitNum;
    Inner join queries work with criteria in the wrong place, but they're harder to read. Outer joins don't work unless you put the criteria in the right place.

  • Bug in JOIN syntax? (oracle 9i)

    Hi,
    take these three tables:
    MASTER (id NUMBER, name VARCHAR2(10))
    DETAIL (id NUMBER, master_id NUMBER)
    SUBDETAIL (id NUMBER, detail_id NUMBER, name VARCHAR(10)
    When I perform this query:
    SELECT SUBDETAIL.id as did, MASTER.id as mid
    FROM SUBDETAIL
    JOIN DETAIL ON (SUBDETAIL.detail_id = DETAIL.id)
    JOIN MASTER ON (DETAIL.master_id = MASTER.id)
    WHERE
    name = 'joe';
    I would expect the parser to give me 'column ambiguously defined' (because the 'name' field from the whereclause is defined in both subdetail and master).
    However, it does not say that. Instead, it assumes that it should use the name field from master. This is confusing, as this could easily lead to mistakes (as it did in my application)
    Greetings,
    Ivo

    There seems to be a difference between the way Oracle resolves column names using the ANSI join syntax and Oracle's syntax. It appears that Oracle does not know about the columns, until it processes each join, and further, the last table joined seems to be sued to resolve nameing conflicts. Consider:
    SQL> SELECT * FROM master;
            ID NAME
             1 joe
    SQL> SELECT * FROM subdetail;
            ID  DETAIL_ID NAME
             1          2 fred
    SQL> SELECT * FROM detail;
            ID  MASTER_ID
             2          1
    SQL> SELECT subdetail.id AS did, master.id AS mid
      2  FROM subdetail
      3       JOIN detail ON (subdetail.detail_id = detail.id)
      4       JOIN master ON (detail.master_id = master.id)
      5  WHERE name = 'joe';
           DID        MID
             1          1
    SQL> SELECT subdetail.id AS did, master.id AS mid
      2  FROM subdetail
      3       JOIN detail ON (subdetail.detail_id = detail.id)
      4       JOIN master ON (detail.master_id = master.id)
      5  WHERE name = 'fred';
    no rows selected
    So, it is clearly going after master.name. However,
    SQL> SELECT subdetail.id AS did, master.id AS mid
      2  FROM detail
      3       JOIN master ON (master.id = master_id)
      4       JOIN subdetail ON (subdetail.detail_id = detail.id)
      5  WHERE name = 'joe'
    no rows selected
    But,
    SQL> SELECT subdetail.id AS did, master.id AS mid
      2  FROM detail
      3       JOIN subdetail ON (subdetail.detail_id = detail.id)
      4       JOIN master ON (master.id = master_id)
      5  WHERE name = 'joe'
           DID        MID
             1          1
    Old style syntax gives:
    SQL> SELECT subdetail.id AS did, master.id AS mid
      2  FROM subdetail, detail, master
      3  WHERE subdetail.detail_id = detail.id and
      4        detail.master_id = master.id and
      5        name = 'joe';
          name = 'joe'
    ERROR at line 5:
    ORA-00918: column ambiguously defined
    and note that
    SQL> SELECT subdetail.id AS did, master.id AS mid
      2  FROM subdetail
      3      JOIN master ON (detail.master_id = master.id)
      4      JOIN detail ON (subdetail.detail_id = detail.id)
      5  WHERE name = 'joe'
        JOIN master ON (detail.master_id = master.id)
    ERROR at line 3:
    ORA-00904: invalid column nameSo, in ANSI syntax, order matters, and whatever the syntax good testing matters.
    TTFN
    John

  • Outer Join Syntax in sql2k to Oracle Migration

    All of my existing SQL Server 2000 code is using the (INNER, LEFT OUTER, RIGHT OUTER) JOIN syntax which according to Oracle SQL Reference (A90125-01) is supported. The migration workbench seems to want to convert this to the old style syntax of putting (+) in the where clause conditions. I am therefore getting lots of warnings telling me that "complex outer joins are not reliably supported". Is there a setting somewhere that will tell the migration workbench to maintain (subject to required conversion) the original syntax format.

    Hi Doug,
    The issue you report has been tackled in a recent internal build released by the OMWB team. OMWB version 9.2.0.1.6 which is freely downloadable on the http:\\mtg.ie.oracle.com site. As I've mentioned, this is an internal release and is therefore not supported - although it is very stable and has already been used by several internal customers. We expect to have a fully supported release of OMWB available on OTN in December.
    In version 9.2.0.1.6, there is an option in the "Parse Options" tab on the Stored Procedures property sheet called "Generate Oracle 8i Outer Joins" - this setting is switched off by default in this build and would therefore preserve your ANSI compliant joins by default. Switching the setting on causes the OMWB parser to generate the joins in the old (+) Oracle syntax standard.
    I hope this helps,
    Tom.

  • Configure "Query Builder" for Theta-Style Joins over ANSI-Style Joins

    Can SQL Developer be configured to auto generate theta-style joins instead of ANSI-style joins when building queries? This happens when I generate a query using the Query Builder and then switch over to the Worksheet tab to see the SQL code.
    Sample code:
    Theta-style join syntax uses commas to separate multiple table names and creates the joins in the Where clause:
    SELECT c.name
    FROM instructors i, courses c
    WHERE i.firstname = 'Mary' AND i.lastname = 'Williams'
    AND i.course_id = c.course_id;
    ANSI syntax uses the JOIN and ON keywords instead:
    SELECT c.name
    FROM instructors i JOIN courses c
    ON i.course_id = c.course_id
    WHERE i.firstname = 'Mary' AND i.lastname = 'Williams';

    Hi Wes,
    There is no preference for configuring this that I know of, but Query Builder is fairly clever about detecting your flavor of SQL from the worksheet then sticking with it. If you design it graphically, the default flavor is ANSI, but QB seems to respect any worksheet edits that switch it to another flavor. I wouldn't vouch for that absolutely, but perhaps it's behavior you can take advantage of.
    Regards,
    Gary
    SQL Developer Team

  • When Mig Workbench will support the JOIN syntax?

    Oracle 9i supports the ANSI SQL standard. The current workbench
    version converts the JOIN syntax into the (+) syntax. Does
    anybody know if and when the Migration Workbench will support
    the JOIN syntax i.e. not try and convert it?
    Thanks
    Costas

    Hi,
    Oracle 9i now supported ANSI standard outer joins. We are
    currently planning our coming releases of the Workbench and we
    would hope to include outer join capability in version 2.0.3 of
    the Workbench . We have not finalised plans yet but it looks like
    being Q1 next Calendar year.
    Regards
    John

  • Converting oracle join to Ansi sql join

    Hi Guys,
    I am new to SQL and trying to convert the following Oracle query (joins) into ANSI sql joins...Can someone please help me?
    SELECT M.EXTERNALCODE, M.NAME AS MNAME, SC.BIRIM, SM.TRANSACTIONDATE, SMD.AMOUNT,
    SMD.UNITPRICE, SM.ID AS SMID, SMD.ID AS SMDID, F.NAME AS FNAME,
    IFNULL (SMD.AMOUNT, 0, SMD.AMOUNT) * IFNULL (SMD.UNITPRICE, 0, SMD.UNITPRICE) AS TOTALPRICE, SMD.AMOUNT AS RECEIVED_QUANTITY,
    PD.ORDERID, PD.AMOUNT QUANTITY, PO.PROCESSDATE
    FROM STOCKMAINTRANSACTION SM,
    STOCKMAINTRANSACTIONDETAIL SMD,
    MATERIAL M,
    STOCKCARD SC,
    FVSTOCK FVS,
    FIRM F,
    PURCHASEORDER PO,
    PURCHASEORDERDETAIL PD,
    PURCHASEORDERDETAILSUPPLIED PDS
    WHERE SM.ID = SMD.MAINTRANSACTIONID
    AND SMD.MATERIALID = M.ID
    AND SMD.STOCKCARDID = SC.ID
    AND SM.PROPREF = FVS.RECORDID(+)
    AND FVS.FIELDID(+) = 2559
    AND FVS.FLEVEL(+) = 'F'
    AND F.ID(+) = SUBSTR (FVS.FVALUE, 1, 9)
    AND SM.TRANSDEFID in (999,2329,2344,2370,150000903,150005362)
    AND SMD.CANCELLED = 0
    AND SMD.STOCKUPDATED = 1
    AND SMD.ID = PDS.STOCKMAINTRANSACTIONDETAILID
    AND PDS.ORDERDETAILID = PD.ORDERDETAILID
    AND PO.ORDERID = PD.ORDERID
    AND (M.ID = {@MATERIALID@} OR {@MATERIALID@} = 0)
    AND (SM.STOREID = {@STOREID@} OR {@STOREID@} = 0)
    AND (F.ID = {@SUPPLIERID@} OR {@SUPPLIERID@} = 0)
    AND SM.TRANSACTIONDATE BETWEEN {@STARTDATE@} AND {@ENDDATE@}
    ORDER BY F.NAME, M.EXTERNALCODE, SM.TRANSACTIONDATE
    Really appreciate the help!
    Thanks.

    Hi,
    Welcome to the forum!
    To convert to ANSI syntax, replace join conditions in the WHERE clause
    FROM           x
    ,             y
    WHERE         x.x1  = y.y1
    AND           x.x2  = y.y2with ON conditions in the FROM clause:
    FROM           x
    JOIN             y   ON    x.x1  = y.y1
                             AND   x.x2  = y.y2In inner joins, conditions that do not reference 2 tables are not really join conditions, so it doesn't matter if they are in the FROM clause or in the WHERE clause.
    In your case
    SM.TRANSDEFID in (999,2329,2344,2370,150000903,150005362)could be part of a join condition involving sm, or it could be in the WHERE clause. Most people find it clearer if 1-table conditions like this are in the WHERE clause.
    Again, this only applies to inner joins. For outer joins, all conditions that apply to a table that may lack matching rows must be included in the FROM clause, like this:
    LEFT OUTER JOIN  fvstock   fvs  ON   sm.propref       = fvs.recordid
                                    AND  fvs.fieldid  = 2559
                        AND  fvs.flevel   = 'F'Try it.
    If you have trouble, post your best attempt, along with CREATE TABLE and INSERT statements for a little sample data from all the tables involved, and the results you want from that data. Simplify the problem. Post only the tables and columns that you don't know how to handle.
    See the forum FAQ {message:id=9360002}
    user8428528 wrote:
    AND (M.ID = {@MATERIALID@} OR {@MATERIALID@} = 0)
    AND (SM.STOREID = {@STOREID@} OR {@STOREID@} = 0)
    AND (F.ID = {@SUPPLIERID@} OR {@SUPPLIERID@} = 0)
    AND SM.TRANSACTIONDATE BETWEEN {@STARTDATE@} AND {@ENDDATE@}This is not valid Oracle SQL. Is {@MATERIALID@} some kind of variable?

  • Request your expert opinions -- 9i join syntax?

    Are you who do SQL programming going to use the new 9i JOIN syntax? Is the old syntax (using the + sign) going to be depricated soon? What do you think? Why should I switch to the new format? I am wondering what others are doing or planning to do.
    Thank you very much for your time.

    Personally, I think the ANSI compliant syntax is clearer and easier to read. Also it has FULL OUTER which is something the old Oracle syntax doesn't support.
    However, I don't think (+) will be deprecated before 10i and I think it will remained suppported for the foreseeable future: there're just too many lines of SQL code out there using it!
    my tuppence halfpenny worth, APC

  • Non-ANSI Outer Join Operator Issue (reposted due to text issues)

    I am currently using Designer 11.5.0.0. Itu2019s XI Rel 2, but Iu2019m not sure what service pack. I have created several universes with outer joins against a SQL Server 2005 database, but when I try using them in a Crystal report, I get the following error:
    Failed to retrieve date from the database. Details: 42000:[Microsoft][ODBC SQL Server Driver][SQL Server] The query uses non-ANSI outer join operators (u201C=u201D or u201C=u201D). To run this query without modification, please set the compatibility level for current database to 80 or lower, using stored procedure sp_dbcmptlevel. It is strongly recommended to rewrite the query using ANSI outer join operators (LEFT OUTER JOIN, RIGHT OUTER JOIN). In the future versions of SQL Server, non-ANSI join operators will not be supported even in backward-compatibility modes.
    Here is my ODBC DSN configuration:
    Microsoft SQL Server ODBC Driver Version 03.85.1132
    Data Source Name: FlexOPS
    Data Source Description:
    Server: dalsvrw031
    Database: (Default)
    Language: (Default)
    Translate Character
    Data: Yes
    Log Long Running Queries: No
    Log Driver Statistics: No
    Use Integrated Security: No
    Use Regional Settings: No
    Prepared Statements Option: Drop temporary procedures on disconnect
    Use Failover Server: No
    Use ANSI Quoted Identifiers: Yes
    Use ANSI Null, Paddings and Warnings: Yes
    Data Encryption: No
    Okay, so I understand what the issue is. It appears that the version of Designer that I am using does not default the ANSI92 parameter to u201CYesu201D. So all the outer joins I have created in each of my universe are using the old *= as the join operator. And apparently, the ODBC driver I am using is not very happy with that.
    As I understand it from what Iu2019ve read on other sites, I have the following options:
    1) Set the ANSI92 parameter to Yes, drop all my joins, close and re-open Designer, and recreate all of the joins.
    2) Find a different driver or connectivity method that will support non-ANSI joins.
    3) Set my database back to SQL 2000 compatibility.
    Option 1 is unappealing as it will cause a lot of time redoing all the work that Iu2019ve spent the past month doing. Option 2 is only a band-aid fix at best. Option 3 really isnu2019t an option for us.

    So I am wondering what other options I have to change these non-ANSI joins to ANSI compatible joins. Do I need to update Designer with a service pack? Is there a script out there that will automatically do this in each of the universes? I would appreciate any suggestions or guidance on this.
    Thanks,
    Lee

Maybe you are looking for