Table - Physical and Logical Mismatch - Physical Incorrect

peterbruce

peterbruce

Legendary Poster
JDEList,

This is all in development (CRP/PY and DV).

I have a custom application that does a lookup on a custom table. I had to add a column to the table some time ago, so I deleted the fetch single event rules and created new ones. Everything was working fine for a number of weeks and many changes to the application, until I made an unrelated change. Now I get the mismatch on the web client, but not on the fat client local web. The log from the server manager shows the physical columns (table prefix with data dictionary alias) missing the column I inserted and the logical columns (just the data dictionary alias) with all the columns.

Clearing Enterprise server and JDBJ caches did not help. Bouncing the JDE services on the enterprise server did not help. Removing the 6 .ddb and .xdb files did not help. I checked out/in the table rebuilt and deployed the package, all with no affect.

I am at a loss as to what to do next. It had crossed my mind to create a whole brand new table.

The custom table is only used in the is application and the associated UBE. It is manually maintained in the database, though there is no anticipation for much change. The application is in production. This project introduced the table, so the table is not in production.

Once this is fixed the project is ready for UAT. But at the moment that is not possible because this error prevents the application from processing properly.
 
If you look at the table in the database is the column there? (did someone restore an old version of the table or delete the column)

Is database column level security applied to this column? This would explain your being able to see it on the local fat client but not on the web server (with different credentials).

Is the table really where you think it is? In other words is there an ocm mapping in place for DV910 that is missing for JDV910?

That's what I could think of off-the-cuff. I'm sure there's more possibilities ...

Let us know what you find please
 
Clearing the JDBJ cache should have fixed it. Have you tried restarting the web server (assuming you have the leeway to do that)?
 
Larry,

Thanks for taking the time to reply.

The column is definitely there in the table in the database. I have not applied any security to the table with exception of removing public access. It would be highly unlikely that any of our DBAs would add security without informing me. The table is in the normal business data schema. I'll check all the OCM copies to make sure there are no strange entries. However, it seems to be able to find the table - I think. It is very confusing for me.
 
Hari,

Thanks for your time.

You mentioned about the only thing I haven't done - restart the web server. I'll get that done today.

My fall back position is to create a new table. It is only accessed by three objects, so it would be a relatively simple task.
 
Hari,

It Worked! Thanks!! It had to be about the only thing I hadn't tried.
 
I suspected that it will. There is probably a bug in the JDBj table cache reset (or maybe it was never meant to do that?). What is your Spec Cache Purge set to (in JDBj runtime) for this HTML server?
 
Hari,

We have two servers with the same settings as below.

Cache Configuration:


Cache Object Expiration Check Interval = 300000
User Session Cache Timeout = 14400000
Spec Expire = 0
User Profile Cache Timeout = 1200000
Menu Cache Timeout = 3600000
Glossary Text Cache Expiration Check Interval = 7200000
E1Page Check Interval = 300000


JDBj Runtime Properties:


OCM Cache Purge Timeout = 600000
Security Cache Purge Timeout = 600000
Service Cache Purge Timeout = 600000
Spec Cache Purge Timeout = 600000
Menu Cache Timeout = 600000
 
The tooltip on the spec cache purge says this:

"Time (in milliseconds) before inactive spec cache entries are purged. 0 means to never purge spec cache entries. Values are 0 or greater."


When exactly does a spec cache become "inactive"? I have no idea. Your timeout is set to 10 minutes, so the web server should have let go of the previous cache after 10 minutes (I am sure you waited that long between retries). Either that, or I am misreading what this setting means.
 
Back
Top