Page 1 of 1

can not find metabag information for object

Posted: Tue Mar 25, 2008 12:21 am
by ShaneMuir
Hi All,

Has anybody come across this error before:
"Internal error, can not find metabag information for object J\326\V0S101P3."

A quick search of the forum finds only one hit, but didn't provide much in the way of a solution.

It started to appear after I changed a lookup file set stage to a sql Server stage for my lookup AND added a condition to the lookup file stage.

It doesn't seem to matter what condition I put in the lookup file stage it comes back with the same error. (I am checking an input column to see whether the field is blank). When I remove the condition it works fine.

When I press the More button i get the following:

Code: Select all

APT LookupOptions (SAP_HR_LOAD_0009_Bank_Details.Lookup_101)

*** Internal Generated Transformer Code follows:
0001: //
0002: // Generated file to implement the V0S101_SAP_HR_LOAD_0009_Bank_Details_Lookup_101 transform operator.
0003: //
0004: 
0005: // define our input/output link names
0006: inputname 0 fromlkpBankType;
0007: tablename 0 lnk_Valid_BSB;
0008: outputname 0 fromlkpValidBSB;
0009: 
0010: initialize {
0011: 	// define our row rejected variable
0012: 	int8 RowRejected0;
0013: 
0014: 	// define our null set variable
0015: 	int8 NullSetVar0;
0016: 
0017: }
0018: 
0019: mainloop {
0020: 	// initialise our row rejected variable
0021: 	RowRejected0 = 1;
0022: 
0023: 	// evaluate condition for link: lnk_Valid_BSB
0024: 	if ((string_length(trimc_string(fromlkpBankType.bsb_cde)) != 0))
0025: 	{
0026: 		lookup(lnk_Valid_BSB);
0027: 		if (!is_match(lnk_Valid_BSB)) {
0028: 			rejectrecord 0;
0029: 		};
0030: 	} else {
0031: 		rejectrecord 0;
0032: 	};
0033: 	// evaluate columns (no constraints) for link: fromlkpValidBSB
0034: 	writerecord 0;
0035: 	RowRejected0 = 0;
0036: }
0037: 
0038: finish {
0039: }
0040: 
*** End of Internal Generated Transformer Code
If anybody can shed some light on this it would be greatly appreciated.

Posted: Tue Mar 25, 2008 12:28 am
by BugFree
The error message you are getting is from a transformer stage. Is the SQL Server stage connected to a transformer and then to the lookup stage?

Posted: Tue Mar 25, 2008 12:31 am
by Nripendra Chand
Lookup condition uses tranformer functions. this is why this error message is coming like this.

Posted: Tue Mar 25, 2008 1:14 am
by ShaneMuir
Nripendra Chand wrote:Lookup condition uses tranformer functions. this is why this error message is coming like this.
Yes - but why is it occuring?

Posted: Tue Mar 25, 2008 1:32 am
by ray.wurlod
There is at least a logical inconsistency between the records in DS_JOBOBJECTS, in particular in the record J\326\V0S101P3, which is a "pin" record (one end of a link). It is missing some information that it should have. It is unlikely that this is physical corruption. Can you try saving the job with a different name and compiling that?

Posted: Tue Mar 25, 2008 5:15 pm
by ShaneMuir
Ok more information.

I have managed to resolve the problem by placing a copy stage before the lookup.

Code: Select all

         Sql                        Sql
          |                          |
          |                          |
          V                          V
Sql ---> Lkp1 --rej_link--> Cpy ---> Lkp2 ---> Xfm ---> Sql
          |                          |
          |                         rej
          |                          |
          V                          V
         odbc                       odbc
Above is how the job looks now. What I failed to mention earlier - and this is probably important - is that the link into Lkp2 was directly from the reject link from Lkp1. I am assuming that this was the problem (please tell me if this is not the case), and that by placing the copy stage between the two lookup stages the metabag information is once again available for the condition.

Posted: Thu Oct 08, 2009 3:08 pm
by asorrell
Just confirming this problem still exists in 8.1 - and the same solution just worked for me.

Posted: Thu Apr 27, 2017 9:43 am
by chucksmith
And at 11.5, but the copy stage solution still works.