8.10 table conversions

[rbd]

Did anyone run across these errors when doing table conversions for 8.10. The tables look ok and have the new fields but I received this error on several of the Alter steps and was wondering if I need to worry about it. The F4111TCTEMP is no longer on the 400 so I have to believe this is a bogus error.

TCEngine Level 1 /E810SYS/tcengine/tcapi.c : Starting ITCEAlterTable
TCEngine Level 1 /E810SYS/tcengine/tcapi.c : Call JDB_OpenForeignTable for input table F4111.
TCEngine Level 1 /E810SYS/tcengine/tcapi.c : Input table F4111 is using data source Business Data - TEST .
TCEngine Level 1 /E810SYS/tcengine/tcapi.c : Call JDB_OpenTable for output table F4111.
TCEngine Level 1 /E810SYS/tcengine/tcapi.c : Output table F4111 is using data source Business Data - TEST .
TCEngine Level 1 /E810SYS/tcengine/tcinit.c : Assigning table F4111 the temporary name F4111TCTEMP
TCEngine Level 1 /E810SYS/tcengine/tcapi.c : Call JDB_OpenForeignTable for temporary table F4111TCTEMP.
TCEngine Level 1 /E810SYS/tcengine/tcapi.c : Temporary table F4111TCTEMP is using data source Business Data - TEST .
TCEngine Level 1 /E810SYS/tcengine/tcapi.c : Input table F4111 contains 68 column(s).
TCEngine Level 1 /E810SYS/tcengine/tcapi.c : Temporary table F4111TCTEMP contains 68 column(s).
TCEngine Level 1 /E810SYS/tcengine/tcapi.c : Call JDB_InsertFromSelect for input table F4111, temporary table F4111TCTEMP.
TCEngine Level 1 /E810SYS/tcengine/tcapi.c : Call JDB_DropTable for input table F4111.
TCEngine Level 1 /E810SYS/tcengine/tcapi.c : Call JDB_RenameTableExtended for temporary table F4111TCTEMP
TCEngine Level 0 /E810SYS/tcengine/tcapi.c : TCE9000 - ITCEAlterTable - JDB_RenameTableExtended failed on temporary table F4111TCTEMP..
TCEngine Level 1 /E810SYS/tcengine/tcapi.c : Table F4111 converted unsuccessfully. Elapsed time - 1856.329000 Seconds.

 

[JDEPrincess]

Bryan -

I've more 400 experience than JDE but based on the sequence of the events leading to the failure, I suspect that JDB_DropTable for input table F4111 failed but that fact has not been registered.

Rename of the F4111TCTEMP to F4111 would fail if F4111 still exists.

If F4111 exists on the system, then it could mean that my conjecture is correct.

Unfortunately, it could also mean that you are right and that rename succeeded but the program reports a bogus error. Hard to tell.

In my scenario, issue would be with the Drop program not reporting failure. I’d say this is a more likely scenario.

For what its worth....

 

[jde_cnc]

I am seeing the same errors here. No word yet from GSS what is causing them, and whether it is a rename/drop error or something else. Let me know if you come across an answer. Thanks!

 

[jstooge]

If it were me, I'd run the R9698711 and see if anything glaring comes out. If the alter didn't work, it'll kick out as an inconsistency, and then you might be under the problem that the princess mentioned. If the specs match the table, then it may be a ignorable error (is ignorable a word?). TC logs are often not an indication of success or failure, especially as I'm assuming you went into IFS to determine the *TCTEMP tables were gone.

I'd feel satisfied with the conversion if the R9698711 said the specs matched, and there's data in the darn thing.

 

[jde_cnc]

Lots of good points. On my end (Win2k3/SQL), the tables in question are all empty, both in source and destination. Also, once the process fails and the error is thrown, the *TCTEMP tables are still in existence in the database (d'oh). I am actively trying to force the TCs to run on the Enterprise Server, as this error is occuring when they are run on the Deployment Server, but no luck so far.

 

[jstooge]

If the TC fails (for real) then you need to delete the *TCTEMPS prior to rerunning. Not sure if you are doing that. The original post specifically said the new table looked as if it matched from a data item standpoint. If your original table still has the same table layout for the old release, you can assume the TC did fail, and then delete the *TCTEMP's used in the process and re-run the TC.

 

[jde_cnc]

Yep, right there with you. I am running scripts to clear the temp tables each time, but they are continuously failing. only about 20 out of the entire TC list, so I am trying to figure out what is unique about them. Planner ESU is up to date, toolset is 8.95_D1, etc.

Thanks again

 

[jde_cnc]

Just looked over at the 8.95_C1 thread on the main page--someone said that that tools release was causing havoc on table conversions when attempting to upgrade. Wonder if that could be the case here...

 

[jstooge]

I'm going to bite my tongue and not comment on any attempt at using 8.95 during upgrades...the earliest "best guess" one off of 8.95 with fixes found for _A1 through _C1 (I'm not up to speed on the issue with _D1) is _F1. Very possible the TC issues are also problematic to the tools release...I agree.

Good luck, and if you do find from Denver that it is caused by the tools release, please let us all know.

 

[jde_cnc]

Looks like these errors are mostly bogus. Every error like this that I got was for a table that was empty before and after conversion. Oracle advised to just regenerate the tables manually in OMW, set the status to Installed, and move on. As this iteration was all on the Deployment Server, I am going to replan the pathcode upgrade and rernun on the Enterprise Server to see if the results change.

 

[Sebastian Sajaroff]

Hi,

Check that you have installed the latest ESU planner.
Could be causing several of your errors.
And if any your TC fails (such as this F4111), you have
to drop its temporary F4111TCTEMP table before retrying.

Regards and good luck... E810 upgrades are not easy.

 

[voetd]

Instead of just re-running the failed TC that is on status 50, change every conversion program for the file to status 30; also the one that is already on 60 or 70. Delete also the temp files. Restore the original file from XE and rerun.That solved it (but we upgrade to 8.11).