ALEPH table or screen change doesn't take effect.

Description

The ALEPH u-tree table has been changed (or alephe/www... screen) but the system acts as though this change has not taken place;  the version being used is the old version.

Resolution

If this table is in the ./xxxnn/pc_tab/catalog directory, you have to run util m/7 to recreate the Catalog package (and then done "Import tables" or restarted the GUI Cataloging client).

If this table is in the ./xxxnn/tab ($data_tab) directory, has the server (or process) which you expect to be using it been refreshed or restarted?

In order to reflect aleph table changes immediately in the GUI, the pc_server must be restarted using util w/3/3.

In order to reflect aleph table changes immediately in the Web, the www_server must be restarted using util w/3/1.

With other servers (oclc_server, sc_server, z39 server), you need to stop/restart the server with util w in order for the change to take effect. In the case of daemons (ue_01, ue_08, etc.) you need to stop/restart the process (using util e). {For batch jobs submitted from the command line, no special recycling is necessary for $data_tab changes to take effect.}

Check, in the relevant server log in the $LOGDIR directory, the *exact* name of the table/screen being loaded. It may have a suffix or something else which you aren't accounting for. (True for tab_sub_library or edit_doc_999.lng.See below.)

In the case of changes to tables/screens in alephe, you need to change the ./u22_1/alephe/... *not* the ./a22_1/alephe/...

For aleph_start , see article Changes to aleph_start or aleph_start.private not taking effect

For edit_doc_999.lng or tab_sub_library.lng, see article Change to edit_doc_999.eng or tab_sub_library.eng doesn't take effect

*** For a discussion of the case where a *restored* version of the table or screen does not take effect, see article Restore of Aleph table or screen doesn't take effect *"MASTER RECORD**. ***

• Article last edited: 1-Sept-2016