Capture rejects of different schemas to a single table

chetan.c · Post by **chetan.c** » Sat Aug 04, 2012 6:53 am

Hi,

I have 3 Oracle Tables with different schemas.
Each table has a reject link and the rejected records are captured in a Sequentail file.

The rejected records need to be captured in a target table whose definition is not yet defined as it depends on how we can capture these records.

Kindly let me know how this could be desinged.

Current thoughts in my mind is to concatenate all columns in a sequential file except RejectERRORCODE,RejectERRORTEXT and have 4 column table with filename and Reject inofrmation and actual reject Data.

Thanks,
Chetan.C

chulett · Post by **chulett** » Sat Aug 04, 2012 9:24 am

I'd be curious what the purpose of the table would be. You've captured them all in one table... and then what? How you would leverage it would drive the design, it would seem to me.

Poovalingam · Post by **Poovalingam** » Sun Aug 05, 2012 12:54 pm

Hi Craig,

I have seen a similar kind of common error log table. This table will be used by support team to understand the reason for rejection. Sometimes business will query this table and ask for the fix if any significant data is identified as missed.

chulett · Post by **chulett** » Sun Aug 05, 2012 2:48 pm

Sure, I've seen them too. But more interested in what our friend Chetan.C has to say on the subject. It's their table after all.

ray.wurlod · Post by **ray.wurlod** » Sun Aug 05, 2012 5:19 pm

Chetan.C tells us that the table design has yet to be defined. I think that doing that is the absolutely vital first step - what information about data errors does Chetan.C need to capture?

This is not something we can do (in spite of having some experience in these areas). Chetan.C must come up with Chetan.C's requirements.

I'd be happy to design the table, but that counts as consulting and comes at a fee.

aartlett · Post by **aartlett** » Mon Aug 06, 2012 12:51 am

What happens if you ask a consultant the time?

He asks to borrow your watch, tells you and then keeps it.

I've "consulted" on this situation many times, and the down and dirty normally is a lot of data collected and stored for absoulutly no reason.

chetan.c · Post by **chetan.c** » Mon Aug 06, 2012 7:40 am

chulett wrote:Sure, I've seen them too. But more interested in what our friend Chetan.C has to say on the subject. It's their table after all. ...

I did ask the same question , and the answer was "what's way the best way we can be showing this ?" ... so decided to give it a try.

chetan.c · Post by **chetan.c** » Mon Aug 06, 2012 7:53 am

ray.wurlod wrote:Chetan.C tells us that the table design has yet to be defined. I think that doing that is the absolutely vital first step - what information about data errors does Chetan.C need to capture?

Well , Chetan.C has been asked to see how best he can be showing the data without any specification as to how they want to see it ( or even who will be seeing it)

Today , I have insisted on who will be looking into this and how they want to look at it ( Querying a table or through a web portal) and waiting for an answer

As for the consulation fee Ray , I think the knowledge you all veterans have here is priceless

.

Thanks,
Chetan.C

BI-RMA · Post by **BI-RMA** » Mon Aug 06, 2012 9:41 am

One of the easiest ways to store data of different formats into a table or file with identical format is to combine all or selected columns of a record in a single column using the Column Export Stage.

This action can be reversed using the Column Import Stage.