Table Update Error

[amwalshjde]

I have a custom table, that after I created I modified. I then created a new BSVW and new APPL, everything seemed to work okay. However, now it seems that when I try to update records in this table I get the following error

JDB9909149: One World TMS Internal Error (failure to read table specs on Sever)

I have tried everything to fix it. I have created new BSVW's and APPL's. I have even tried deleting the table (from everywhere) then creating the table from scratch. All to no avail. Has anyone seen this before? I am really stuck on this one.
I am getting the errors on fat and thin (citrix) and the only work around I have found so far is based on JDE KG call 4775413 which indicated turning off the lock manager requested sevice in the JDE.INI file by changing the requested service to "NONE" from "TS". However the CNC group is against doing that on a large scale.

Thanks,
Aaron

Xe Update 3 SP 18; Oracle

 

[clee]

Deploy the BSVW to the JDE enterprise server. I had a similar issue and
that worked for me.



Chi Lee
IT Project Leader, Va International Terminals, Inc.
B7331 SP11.3, NT4 ES/DS, Citrix, Win2K clients, SQL Server7

 

[got_to_love_jde]

Aaron,

I assume you are getting this error when it runs in batch. Silly question, but what was the end result of the update package you sent to the enterprise server containing the changed table information ?
Also, I would assume you have sent out updated packages to the clients.
Can you see the proper table layout in Oracle ?
dave

 

[Gergely_Pongracz]

Hi,
I had the same issue and our CNC guys switched off the lock manager... It doesn't seem to do any good anyway.
However before I learned about this trick I solved the problem by programming. Into the Before ... Updated (grid or form record cases for headerless detail and fix/inspect forms respectively) I wrote:
Suppress Update()
Table.Update
Into the update command I mapped all the business view fields (BC).
Regards:
Gergely Pongrácz

 

[shazbot]

what's your server? On AS/400, when making a change to a table, we also had to delete our SQLPKG objects that referred to that table (OWEXPLORFJA if it's only used in applications, or look for an SQLPKG with the same name as the UBE you're running). If you run a PRTSQLINF (again, AS/400 command so may not be applicable) on those objects, you'll be able to see if there are any SQL statements in them referring to your table. If there are, and they're incorrect, deleting the SQLPKG will make it rebuild next time your application or UBE runs. I understand SQLPKGs should be cleaned up on a regular basis anyway.

Sharon