Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / Oracle / Oracle Server / August 2005

Tip: Looking for answers? Try searching our database.

MERGE COMMAND WITH DECODE AND INNER SELECT

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
srini - 24 Aug 2005 21:03 GMT
I have the below MERGE command with a decode function as part of the
select clause.Irrespective of the data, the value of column
ABND_ELEC_PYMT_FEE_IN, always evaluates to a 'N'. once the MEREG
command runs successfully.

MERGE INTO ELECPYMT_OWNER.UNUSE_ELEC_PYMT_FEE_RPT@DVTBOLT T
USING (SELECT DISTINCT
        FEE.ELEC_PYMT_FEE_ID,FEE.RQST_PYMT_PROC_DT,FEE.ALT_ELEC_PYMT_FEE_ID,
        DECODE( NVL(p.ELEC_PYMT_FEE_ID,0),0,'Y', 'N') AS
ABND_ELEC_PYMT_FEE_IN,
         FEE.CRE_USR_ID,FEE.CRE_TS,FEE.UPDT_USR_ID,FEE.UPDT_TS
         FROM
           (SELECT

E.ELEC_PYMT_FEE_ID,E.RQST_PYMT_PROC_DT,E.ALT_ELEC_PYMT_FEE_ID,E.UPDT_TS
            FROM   ELEC_PYMT_FEE E, ELEC_PYMT PYMT
            WHERE  E.ELEC_PYMT_FEE_ID = PYMT.ELEC_PYMT_FEE_ID (+)
            AND    PYMT.ELEC_PYMT_FEE_ID IS NULL
            AND    (E.UPDT_TS BETWEEN TO_DATE('&1','MM/DD/YYYY HH24:MI:SS') AND
TO_DATE('&2','MM/DD/YYYY HH24:MI:SS')- (3/24)
                )
            ) FEE , ELEC_PYMT P
          WHERE  FEE.alt_elec_pymt_fee_id = P.ELEC_PYMT_FEE_ID (+)) E
ON(
      T.ELEC_PYMT_FEE_ID = E.ELEC_PYMT_FEE_ID
      AND
      T.RQST_PYMT_PROC_DT = E.RQST_PYMT_PROC_DT
)
WHEN MATCHED THEN
UPDATE SET
        T.ALT_ELEC_PYMT_FEE_ID = E.ALT_ELEC_PYMT_FEE_ID,
        T.ABND_ELEC_PYMT_FEE_IN = E.ABND_ELEC_PYMT_FEE_IN,
WHEN NOT MATCHED THEN
INSERT (
        T.ALT_ELEC_PYMT_FEE_ID,
        T.ABND_ELEC_PYMT_FEE_IN,

)VALUES (
        E.ALT_ELEC_PYMT_FEE_ID,
        E.ABND_ELEC_PYMT_FEE_IN,
        )

if i execute the select clause all by itself without the MERGE command
, as below, then the value of ABND_ELEC_PYMT_FEE_IN evaluates perfectly
with values of 'Y' as well as 'N' depending upon the data.

SELECT DISTINCT
        FEE.ELEC_PYMT_FEE_ID,FEE.RQST_PYMT_PROC_DT,FEE.ALT_ELEC_PYMT_FEE_ID,
        DECODE( NVL(p.ELEC_PYMT_FEE_ID,0),0,'Y', 'N') AS
ABND_ELEC_PYMT_FEE_IN,
         FEE.CRE_USR_ID,FEE.CRE_TS,FEE.UPDT_USR_ID,FEE.UPDT_TS
         FROM
           (SELECT

E.ELEC_PYMT_FEE_ID,E.RQST_PYMT_PROC_DT,E.ALT_ELEC_PYMT_FEE_ID,E.UPDT_TS
            FROM   ELEC_PYMT_FEE E, ELEC_PYMT PYMT
            WHERE  E.ELEC_PYMT_FEE_ID = PYMT.ELEC_PYMT_FEE_ID (+)
            AND    PYMT.ELEC_PYMT_FEE_ID IS NULL
            AND    (E.UPDT_TS BETWEEN TO_DATE('&1','MM/DD/YYYY HH24:MI:SS') AND
TO_DATE('&2','MM/DD/YYYY HH24:MI:SS')- (3/24)
                )
            ) FEE , ELEC_PYMT P
          WHERE  FEE.alt_elec_pymt_fee_id = P.ELEC_PYMT_FEE_ID (+)

But when I run the MERGE command as a whole the value of column
ABND_ELEC_PYMT_FEE_IN, always evaluates to a 'N'.
Am I missing something ? Is this an issue of MERGE command ?
Please help.

Thanks
fitzjarrell@cox.net - 24 Aug 2005 21:29 GMT
Comments embedded.
> I have the below MERGE command with a decode function as part of the
> select clause.Irrespective of the data,

And, apparently, the version of Oracle you're using.  Without such
information your question is unanswerable as only pure speculation is
available as a diagnostic tool.

> the value of column
> ABND_ELEC_PYMT_FEE_IN, always evaluates to a 'N'. once the MEREG
[quoted text clipped - 65 lines]
>
> Thanks

You're missing MUCH, including the Oracle release, patch level and
operating system you're running.  Provide this information and help may
be forthcoming.  Do not expect people to respond to incomplete
questions.  Also do NOT use all capitals in your message title.  You
may think that it implies urgency; we find it annoying.

David Fitzjarrell
srini - 25 Aug 2005 15:08 GMT
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.4.0 - Production

Operating System:
AIX 5.2 - (UNIX)
fitzjarrell@cox.net - 25 Aug 2005 16:31 GMT
> Connected to:
> Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
[quoted text clipped - 3 lines]
> Operating System:
> AIX 5.2 - (UNIX)

Does this information also apply to the remote database?  This may be
an issue with your db link.  Have you tried making a copy of the table
locally and running the same basic MERGE?

David Fitzjarrell
srini - 25 Aug 2005 18:43 GMT
Yes the information about the ORACLE version, and operating system
applies for the remote DB as well.

I am in the process of testing the MERGE locally. DBA is helping me
copy the tables in the local database.

Meanwhile, what I have obeserved, is that the MERGE command above works
properly if I replace the column inside the decode below with any other
column, say FEE.RQST_­PYMT_PROC_DT. The rows after the MERGE command
executes successfully, contain values of 'Y' as well as 'N' for the
column ABND_ELEC_PYMT_FEE_IN, depending upon the data.

 DECODE( NVL(p.ELEC_PYMT_FEE_ID,0),0,'Y­', 'N') AS
ABND_ELEC_PYMT_FEE_IN.

Is there a chance that the MERGE is not able to resolve the ambiguity
on column, ELEC_PYMT_FEE_ID since I am using this as part of the join
clause twice , a second time to do a self join ?The column
ELEC_PYMT_FEE_ID , is present in ELEC_PYMT as well as ELEC_PYMT_FEE
tables.May be it is always resolving the column to be from the
ELEC_PYMT_FEE table, and since FEE.ELEC_PYMT_FEE_ID is never null, the
DECODE statement always evaluates to a 'N'.

Thanks
David
srini - 25 Aug 2005 19:40 GMT
hi David,

I tried  executing the MERGE command locally(without the DBLINK), and
MERGE works like a charm.
DECODE( NVL(p.ELEC_PYMT_FEE_ID,0),0,'Y­­', 'N') AS
ABND_ELEC_PYMT_FEE_IN.
decode function above evaluates correctly.
I am novice to ORACLE/SQL, can you suggest ways of fixing this issue ?
Is there any alternative to DBLINK, any property that need to be set on
the DBLINK  ?

Thanks again.
fitzjarrell@cox.net - 25 Aug 2005 22:49 GMT
> hi David,
>
[quoted text clipped - 8 lines]
>
> Thanks again.

My first suggestion is to patch to at least 9.2.0.6 for both instances.
Presuming you have no SQL*Net issues changing the tnsnames.ora file
may cause problems in other areas in an attempt to fix the dblink
issue.  Also have the DBA peruse Metalink to find possible bugs in
9.2.0.4 affecting dblinks and any one-off patches that may be available
to correct those bugs.  These bugs may be fixed in 9.2.0.6 so patching
to that level may correct the problem.

David Fitzjarrell
srini - 26 Aug 2005 14:53 GMT
Thanks for the suggestion David.
srini - 30 Aug 2005 21:04 GMT
Reversing the DBLINK, has done the trick. MERGE command ran
successfully, and the decode function below evaluates to 'Y' as well as
'N' based on the data.
DECODE( NVL(p.ELEC_PYMT_FEE_ID,0),0,'Y', 'N') AS ABND_ELEC_PYMT_FEE_IN

Intially the select/join of data was done locally(production database
with large volumes of data) which was runnning on ORACLE 9i version
patch level 4. and data was pushed remotely to reporting database which
is ORACLE 9i version patch level 5. in other words the MERGE command
was executed on production database.

I tried reversing the DBLINK, to execute the MERGE command on the
reporting database, and MEREG command ran sucessfully.

Now my concern is(as i do more tests) the impact on performance,
because now I am pulling data from a remote database as opposed to
pushing it earlier.Thoughts ?
srini - 31 Aug 2005 16:37 GMT
Oracle Support was able to reproduce the problem on their end.

They were able to reproduce the problem on two 9.2.0.6 databases. They
will file a bug for this.

The same workaround was suggested. That is to run the MERGE on the
reporting database that had the UNUSE_ELEC_PYMT_FEE_RPT table.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.