Thanks Simon.

We ran the bulk compile. That's how we found the problem. I have since raised a TAR with Oracle and it looks as if we have an old version of a function. They have supplied a patch that we are in the process of applying. I'll post our findings here.

We have had the 'value exceeded allowable range' message pre FP K also but a particular formula that was ok pre FP K now gives the error, so I am assuming the maximum character length has reduced. (Uh!)

Cheers,

Del

Del
Could you post the patch number?

Cheers
Baz

We have a minor problem in that when we first enter our 11.5.10 FP K env we need to do anything in core forms first before switching resp and doing any functions in Manager Self-service, otherwise we get the old "System Error, contact your System Administrator" message.

Does anyone have a fix for this please?

Thanks, Sandra

Baz,

The Court Order patch number is 4395503

Just found another little gem with FP K. New fields have been introduced on the User Defined Table Structure form. In the columns button there is a new field 'User Column Key'. When you apply FP K this is populated with the column name. "So what?" you might say, "Am I bovvered?" You will be if the column name is more than 30 characters cos that's the limit of the User Column Key and you get a forms truncation error. You might also get corrupt characters appearing as well. These will be different every time you query the form. I also tried to create a new table structure and when I entered a column name more than 30 characters it truncated the User Column Key, saved the record and I could no longer query back the column. I have TAR'd it and will keep you posted.

Well, it's a known bug. Oracle advise to apply patch 4685013 to resolve the problem.

Cheers,

Del

Not sure if this is another FP.K. special, but very recently I have had occasion to run the 'delete element entry' api. Well after much faffing about with setting profile options (HR:Purge Element Entry Permission= All) and thereafter doing the apps_initialise thing to pick up said profile option value, the api duly does the business.

However, an interesting side effect is, it doesn't seem too fussed about the presence of run results any more. In fact it left 20 of the poor little blighters orphaned, all alone in the world without their parent element entries to keep them warm and safe from harm. I am not in a position to try this out on a non-FP.K. instance, so if anyone else out there could try it, I'd be very interested to know the outcome...

Strangely the system does not need the element entry to support the run results. This has been the case for many a year (as I can testify having loaded pay history into the results and result values tables without the originating entries - all you need is an element link).

However should the need arise to run a retropay, these results will get negated because of the missing original element entry.

Another problem doing the rounds.
Slow performance of code that uses the function pay_balance_pkg.get_value

APPLY PATCH 4745996 which fixes pay_balance_pkg to run faster.
------------------------------
Bug 4745996: Performance of pay_balance_pkg.get_value on a balance.
Functional Description:
The CBO elected a sub-optimum plan for a particular statement used within pay_balance_pkg.get_value. CBO hints have been added to the statement to assist the CBO is slecting the optimum plan.

Technical Description:
The CBO elected a sub-optimum plan for a particular statement used within pay_balance_pkg.get_value. CBO hints have been added to the statement to assist the CBO is selecting the optimum plan.

A ha! That would explain several things....
Cheers for this Vinoo...Put another beer on the tab