Message F554201 : JDB9909149 - OneWorld TMS Internal Error

Hello List,

With a new application P554201 which has only a fix/inspect form, based on a business view V554201 which is in its turn based on my own table F554201, in ADD mode, every thing works fine. But when I am in UPDATE Mode, if I configure the PC NOT to use the TS service as following:
[LOCK MANAGER]
Server=
RequestedService=NONE

Every thing is Ok, the Update happens well.

But,if I set the following in jde.ini:
[LOCK MANAGER]
Server=ES_SRV
RequestedService=TS

I have the following message (in a message box and in jde.log):
F554201 : JDB9909149 - OneWorld TMS Internal Error (Failure to read the table specs on the server). Update Failed!

I Saw such a problem with 2 applications and 2 tables (which are user table, not jde ones).

After check-in, I had built a full package, I deployed it to the ES and client, and this do not work. In an old post, I followed the steps which are: generating glbltbl.ddb and glbltbl.xdb with R92CRTGL on the fat client and copying the 2 files to the ES under pathcode/specs/

But this do not work too.
Has any one an idea ?

PS: If I use suppressUpdate and do a tableI/O with an Update in the OK event, this works well, but this is not good at all (the form have to do the good sql request insert or update).


My Config: ES and DS: NT4.0 SP6a, SQL7 SP3, MDAC 2.5, B733.2 SP 17.1, Fat Client: Win98 and Win2k Pro.

Maher SAMET
Groupe MEUBLATEX - Tunisia

Maher,

I found an answer to this issue on the JDEList a while back, so I'll pass on what I learned. In your JDE.INI file, there is a section which lists the default environment, and I believe it is this environment that the system is trying to validate table specs against. The default environment is specified in the following section:

[DB SYSTEM SETTINGS]
...
Default Env=PD7333
Default PathCode=PD7333
...

I ran into your exact issue until I moved the table specs into my default environment and built an update package to move those specs up to the enterprise server. Once I did this, I could get rid of the special [LOCK MANAGER] section settings, and the updates worked just fine.


Don Sauve
Wagstaff, Inc.
OW XE, Update 1, SP15.1, HP-UX 11.0, Oracle 8.1.6

Maher,
the lock manager is an enterprise process that validate your db operation and it must know table format. It uses the enterprise specs for the table format. So if you build a server package with your new table and deploy it to your enterprise, problem should be solved.
Gigi

Hi,

My objects are developed in CRP, and I found that [DB SYSTEM SETTINGS] on the ES pointing to CRP. On my PC, it was pointing to PRD733 and PRODB733, so I change it to CRP733 and CRPB733. Nothing happened.

I copied the object from CRP to PROD. And I loggued on PROD, generate the table. Ok.

But this do not work.

Under CRP, and under OL, I copied the table using Form/CopyTable from CRP to PROD. And when I start my application (always in UPDATE mode), it worked well. BUT unfortunately, when I exit from OW and logged again, this do not work (and the form/CopyTable again corrects the problem but only for the session).

Any other idea ?

PS: I tried to make an update package on a full CRP package for both client and server, compressing only SPECs, not building BSFNs, the package is ok for client, but not for server; it finished with error but all directories on the ES under my package are empty ! Any idea, or how to build an update package for server containing just one object (the table) that has no NER associated (no trigger) ?

Thanks.

Maher.

Regarding your server update package error(s), I too received errors on doing the server update package. I made a second package with the same objects in it, and the second server update package built fine. I'm not sure why, but I observed this behavior twice.

Also, have you built an update package in PROD yet? That might still be worth trying.

Don Sauve
Wagstaff, Inc.
OW XE, Update 1, SP15.1, HP-UX 11.0, Oracle 8.1.6