Hmmm

I thought that we now use HR_ALL_POSITIONS_F as the key table for the position definitions.

Some investigations for a bit of custom work have revealed that here at the nations health provider we have both this table and PER_ALL_POSITIONS existing within the HR schema - and both appear to have significant valid data in them.

Am i missing something here? Is there a backwards-compatibility issue that has meant that the old positions table (PER_ALL_POSITIONS) needs to remain in existance? Or is this something we've done?

Cheers

(oh, by the way - this is on 11.5.10.2)

They are two separate tables, holding (in theory at least) the same position records. I believe there is an internal process somewhere that keeps them in step - I also believe it's a historical thing for other apps that use positions and still need to refer to the (old) table PER_ALL_POSITIONS

splendid.
I'll get me coat and turn the light off on my way out

Can't see very well here as some fool turned all the lights off, but for what it's worth, it appears the package PER_REFRESH_POSITION takes care of all that keeping-in-step malarky, in conjuncion with the column COPIED_TO_OLD_TABLE_FLAG on HR_ALL_POSITIONS_F

.. ah .. what version of the api you running clive ? the two cursors here dont seem to take account of the flag in the date tracked table at all and there has been a big divergence in the data between the two tales as the conc prog has not been running properly .. We are :
create or replace
PACKAGE BODY PER_REFRESH_POSITION AS
/* $Header: hrpsfref.pkb 115.12 2005/08/12 16:27:01 hsajja ship $ */
--

seems old ...

That's the same version we have here in Fort Apache.

In what way does the data diverge where you are?

I have had a quick look at the 2 tables here, and there are no divergences on position_id. However, there are divergencies on position name, which kind of reflects the historical nature of position name changes.

One is a more purchasing focused table, and the other is a date tracked HR table.

The job which keeps them in sync is 'Synchronize Positions'. Which is program code PERPSFSN

HTH!

Gary

.. still got an SR open ;-) as we have a problem with the sync roles for wf - which uses the "more purchasing focused table" .. personally looking at the API underneath i cant see how it works - although new entries via professional forms get put into both tables at the same time .. but the date from the _F forms no part of the sync process !!! bizarre ..

.. so today we have a NULL position name in the "more purchasing focused table" ..

Neill