FieldToProp: Internal error - Bad number of subobjects

RodBarnes · Post by **RodBarnes** » Thu Sep 15, 2011 9:15 am

[I've found several posts that address the error "FieldToProp: Internal error - Bad number of subobjects" but none of them provide any solutions.]

A particular project has begun exhibiting this error when attempting to view properties on any routine in any sequence in the project. Based upon other posts, I ran DS.REINDEX ALL (twice) and that made no difference.

Does anyone have any additional information on this message and what it actually means?

RodBarnes · Post by **RodBarnes** » Fri Sep 16, 2011 1:44 pm

Just an update: I opened a case with IBM and they said that their typical direction is to use DS.REINDEX (or DS.TOOLS #2). Since I had already done that, they said the only options were to

1. re-import the routines from an existing export
2. export the modules from the project, recreate the project, then re-import the modules.

I'll report back on what we end up doing and whether it is successful.

chulett · Post by **chulett** » Fri Sep 16, 2011 4:08 pm

Did they give you any idea as to what caused the problem?

RodBarnes · Post by **RodBarnes** » Fri Sep 16, 2011 4:15 pm

Just the standard "This error message generally indicates corruption in the DS_ROUTINES file in DataStage." Which is what was expected to be the issue. But, if true, then I wonder why REINDEX didn't fix it.

chulett · Post by **chulett** » Fri Sep 16, 2011 5:28 pm

We all know what it indicates, I was hoping they might have some Words of Wisdom as to what actually caused the corruption. Many moons ago, I had some odd corruption in a project although we'd had none of the normal situations that were known to cause that. Turned out to be a known bug in the dsapi code...

ray.wurlod · Post by **ray.wurlod** » Fri Sep 16, 2011 7:41 pm

DS.REINDEX only rebuilds the indices - it does not touch the underlying table. You can verify whether the table itself is corrupted using various tools, including UVFIXFILE and dsfixtool.

RodBarnes · Post by **RodBarnes** » Mon Sep 19, 2011 3:10 pm

This is a Windows server so I don't think it has dsfixtool -- at least, I am unable to find it. I can locate and execute UVFIXFILE but am not familiar with its options.

I ran "UVFIXFILE DS_ROUTINES" and it simply reported back:

Beginning TRACE of DS_ROUTINES.
TRACE of DS_ROUTINES completed.

Scanning overflow buffers.
Scan complete.

26 group(s) processed.
41 group buffer(s) processed.
150 record(s) processed.
Number of data bytes = 29584.

Is there something else I can check?

ray.wurlod · Post by **ray.wurlod** » Mon Sep 19, 2011 3:26 pm

In version 7 it might be called simply fixtool. In any case, you've proven that DS_ROUTINES is not structurally corrupted. That isolates the problem to logical corruption in one (at least) of the records in that table. Can you identify the particuar routine that throws the error?

RodBarnes · Post by **RodBarnes** » Mon Sep 19, 2011 3:30 pm

That's the weirdest thing about this: It happens with any routine in any sequence. And it just appeared one day -- of course, no one knows what was done prior.

I can pick any sequence, right-click to view properties on any routine stage, and up comes the error.

P.S. I found "fixtool". Tried

Code: Select all

fixtool -level 3 -file DS_ROUTINES -filepath \Data\Ascential\DataStage\Projects\IT_test

and it returned

Code: Select all

Filename: DS_ROUTINES

Start Diagnostics.
        0 Errors found in physical structure.
        0 Errors found in file header.
        0 Errors found in file groups.
        0 Other errors found in file.

        451 records processed.

        No errors were found.


Fixtool Completed.

Then I tried it with level 10 but after all the other output it said "No errors were found".

ray.wurlod · Post by **ray.wurlod** » Mon Sep 19, 2011 3:48 pm

Are you running a different client version and server version?

RodBarnes · Post by **RodBarnes** » Mon Sep 19, 2011 3:57 pm

ray.wurlod wrote:Are you running a different client version and server version?

Nope. Same installation we've been running for the last three years. Client and server installed off the same media.

dsbuildinfo.txt shows

Code: Select all

Server Section
--------------
Ascential Build Date	-	Tue Jun 29 13:00:11 2004
Build Platform		-	WINNT
Build Version		-	"7.5.0.25"


DSEngine Section
----------------
Build Version		-	 7.5.1.1
Ascential Build Date	-	 Tue Jun 22 18:13:42 2004

And clients all show version 7.5.0.25.