When we match/approve purchase invoices, the system takes around 4 - 5 minutes to return with the results. The sessions involved are tfacp1110s000 and tfacp1130s000. We must have a flag set incorrectly or maybe there is a session or table booster to fix this. Any ideas would be greatly appreciated.

Hi Ron.

We have some pretty heavy performance problems within the tfacp1110s000 session mainly based around the packing slip entry wherby the session goes away and thinks about the packing slip for approx 1 minute.

The time for the session was approx 90 seconds before we ran some of the archiving sessions in this area.

The main problem seems to be based around the number of records in the table tdpur045 - Receipts. We reduced this by running tdpur4223m000 - Process Delivered Purchase Orders session with the delete flag set to Yes for orders up to the end of 2000. You could also look at running the session tfacp2250m000 Remove Fully Paid Purchase Invoices which would reduce the number of records in tfacp200.

However despite our problems we still have performance problems in this area which we are discussing with Baan.

Regards

Neal Matthews
Intier Automotive - Project Leader

Hi Neal,

We though that would be an issue as the database grew, but this was the case with the very first purchase order. I don't think it should be that slow that early. We have been working with it for quite some time to no avail. It has been slowing down more and more, but the very first purchase order we tried to match (at the time there were only 6 very small purchase orders in the system) still took almost 4 minutes. Most things in the system have good performance levels, so I don't believe it is a hardware issue.

Baan doesn't seem to care about assisting a company as small as ours (they do seem VERY interested if our support payment is coming due though - we get lots of attention for a few days a year). We are also afraid of any answers we get from Baan Support (frequently they tell us to install a patch that ends up taking our system down completely - 16 patches and several hours later, we end up back where we started). I have lost all faith in the Baan support desk, which is why I would rather only deal with the user community (which has proven to be extremely effective and knowledgable).

I'll keep looking into it. I hope you can get your issue resolved as well. If you come up with anything on your end, it would greatly appreciated if you could pass it on. I'll post to this thread if I find out anything else that might help. Thank you for any assistance .

Regards,

Due to turnover, the Baan help desk is often staffed with new recruits. Once someone actually knows something they leave for greener pastures (even now). There are developers behind the first and second line staff: If you push for escelation and ask for these people again by name, the answers come more quickly and you receive less of the blind patch application answers.

In terms of performance, also check for archiving in the general ledger. These posting transactions tend to build up quickly and can overwhelm the system very quickly.

Hello again,

I would certainly agree with Stephen that sometimes you can a better service from second level once you get past the first level of solutions and patch loading.

However painfull the patch loading seems though it is a process that you have to go through.

At the very start of our implementation we had numerous problems with the tf module especially in invoice matching. It seems that B40c3 was a bit of a buggy release so somebody once told me and we had to load numerous patches to get to where we are now with the latest versions of the sessions. We now have very few problems which we don't already know about such as performance.

We now have a very small oustanding case list and I believe that there was a big drive on support within Europe last year and now the turnaround of our cases is relatively quick.

I'm not quite sure how far down the line you are with Baan but you certainly get a lot more out of support if you can talk to them more in their own language (provide session traces etc) and always have pretty upto date versions of the object.

I would also agree that if only a few parts of a system are giving you performance problems then it is unlikely that you have a hardware problem. We spent a lot of time looking at the OS and the database without solving our key performance issues but all this sort of work helps.

Finally I don't think you mention this anywhere but what version of Baan are you running ?

Hope some of this helps and good luck.

Regards
Neal Matthews
Intier Automotive - Project Leader

Hi Neal,

You already pegged our version in your last message. We are using B40c3. I'm glad to hear things are getting better at the Baan support desk. I might even break down and call them this time. Thanks.

Regards,

Ron,

A few questions --

1. What database and platform are you on?

The optimization of the query and the use of optimizer statistics are commonly a cause of the problem in situations like this and the answer is dependent on what you are running on.

2. I would recommend looking to see what patches are out there for this particular session. You mention you are on IVc3 so I know that some are not available for you, but have you checked? Baan commonly has problems like this tghat are fixed with a patch.

Once I know the database and version, I will have some more suggestions.

I have seen this exact behaviour before and I fixed it with the combination of generating the statistics and a single Baan patch.

-- Jim

Hi James,

We are using Informix 7.3 on Windows NT 4.0 (SP3 for the server, SP5 for the workstations). I hope this helps. Thanks for the assistance.

Regards,

Ron,

First of all, are you running UPDATE STATISTICS on your Informix database regularly? This is imperative for good query performance.

Have you checked to see if a patch is out there for this session? I am 80% sure this has been fixed in a patch (I checked and this fixed a problem in matching receipts a few years ago in a IVc2 Informix account -- it had been using the wrong index).

-- Jim

Hi Neal ...

Since u are on informix i would advise u to use to use infstat command to check where actully time isbeing taken steps:

goto configure before logging in
in command field type SET -INFSTAT <time in seconds>
eg SET -INFSTAT 5

This command will amke a text file in your root directory (infstat) in the format as all the querries which are taking more than 5 seconds and would also give the time taken against the same...

this way you could trap the bottleneck of the problem....

try it out ..... respond in case of any querry..

rgds,

Himanshu

Correction:

Hi RON!

On the command line of the BW client you can use the following syntax to enable these two Informix tools. The stats will tell you what the database is doing at a summary level every n seconds. The profile (which I generally find more useful) will show you all database activities that exceed a specified threshold.

-- -set INFPROF=0.1 (every action taking longer than a tenth of a second. 0.01 is the lowest value that can be set)

-- -set INFSTAT=20 (time in seconds. In this case every twenty seconds)

Details on these two commands can be found in the Informix database driver technical reference manual for your version of Baan.

Feel free to send me the output via email if you have questions.

--Jim