Errors on F49002 TC for an upgrade from Xe to E812

[Jfreyre]

Hi guys, I'm facing some strange issues with the TC for F49002 table in an upgrade from Xe to E812, (1 Enterprise Server Merged with the Oracle database server running in HPUX, 1 windows 2003 Deployment Server)

As far I've been searching on the logs for that TC I'm having some issues inserting the current registries for F49002 into the F49002TCTEMP table, as you can see in the next line from the Log:

TCEngine Level 0 \builds\8.96.03.02.07\Rels\common\TCEngine\tcapi.c : TCE9000 - ITCEAlterTable - JDB_InsertFromSelect failed on input table F49002, temporary table F49002TCTEMP..

After seing that I tried to made a Describe for that tables, and I've found something pretty odd, the Table F49002TCTEMP has two columns with an incorrect datatype, the TXDGCP and the TXDSRC are NUMERIC instead of CHAR(1) as it should be, even worse If I look for those values in DD they are parametrized as It should be CHAR(1).

Does anyone have any clues?

 

[Sebastian Sajaroff]

Hi José

Where are you running this table conversion?
Locally on the Deployment or directly on the Enterprise Srv?

 

[Jfreyre]

Hi sebastian, this is a technical TC and threof is running on Deployment Server. (I forgot to put that, thanks)

 

[radi8]

I may be going in the wrong direction here, but the first thing I would do would be to look at the make table process of the conversion UBE R8949002.

First, open this UBE up in designer. You will see the conversion mappings and can verify that they are correct in the UBE (if DD is correct, these should be ok). From here, you can tell the conversion process to log all kinds of info from the logging tab of the conversion properties window.

Second, load this UBE into the debugger and put a break point on the first ER row in 'Process begin'

third, launch UBE with LOGGING enabled. When the debugger stops the process, go to the SQL manager and look at the column definitions and then verify it with the LOG file make table statement.

I recommend to do this because I have had strange things happen with SQL when importing spreadsheets. If SQL sees the first column element as a number, it may change the column attributes (it tries to be smart, SQL 2000 at least).

Look, I know this is a totally different process and it should never work this way, but eliminate it as a possibility. If the table definitions are correct when it is first made, then the data should convert into that format. This may at least point you in the right direction.

 

[Jfreyre]

Hi rady thanks for your answer but I don't know why my TC scheduler is not using R894002 for that table conversion instad is using an *ALTER TC API, ad Far I've been researching R98405A is calling Launch Table Conversion which is calling some functions on TCEngine.dll directly and I have No Idea how to make a breakpoint at that level

 

[Jfreyre]

Hi guys,

Well I started a Service Request with issue at Metalink3, but maybe I will try another approach and create the new table by myself using the OMW and transfering the data from a backup from the old table to the table with the new format. After doing that I will change the value for that TC in the upgrade plan in order to continue with the others TC.

what do you think? Do I have any flaws in what I'm going to do?

 

[Jfreyre]

well, since I started this thread there are been so many issues, even If I made a workaround for the first table with this error I had to start a Service Request because I had the same trouble with the F00166's TC. Right now Oracle sent me an ICE (with a new Jdekernel.dll) and I will try this custom solution.

 

[Jfreyre]

Even if we received an ICE it didn't solve the issue and we made that convertion manually through SQL