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.