Speed problem 'Post Inventory Cost to G/L' report

Roelof

Hi,

One of our customers has a speeding problem when Posting Inventory Cost to G/L (report 1002). They are using version 3.70. I checked the ocde of this report and it seems to work fine regarding keys. However, what they do is adding an additional filterfield to the ValueEntry tab: 'Inventory Posting Group'. Might that slow down things?

Thanks,
Roelof.

Savatage

1) this is not a fast report, it probabaly takes us 1 hr or 2 give or take. I run it as I'm walking out the door so I'm not really timing it - I just know it takes forever.

Plus we do adjust costs about every 2 to 3 weeks. so there is a build up.

2)we never filter anything.

3) we have about 7000 items and 16 GIG DB.

Can you explain the speed problem. Is it way too slow for the database size?

PS) it's significatly faster when we run it from the server instead of a client.

DenSter

I'd also like to kno about the platform, if they are on SQL or on C/SIDE. Is there a lot of custom development? How many dimensions do they have? Are their analysis views automatically updated?

kine

We are using our adjustment scheduler to run the batches daily. In this case, the batch is running around 10-20 minutes...

Shenpen

Filtering for anything but the current key always causes speed issues, and I think on the native one a bigger one than on SQL.

I mean the native is an ISAM database engine - I think it's a derivation of the popular RAIMA engine of the eighties. The point is with all ISAM databases that they maintain index tables for all keys and therefore filtering for a key is a fast binary search. Filtering for something not in the current key makes the engine read all records and decide whether it is included in the records set or not one by one.

SQL might cope better with it - OK it's also an ISAM somewhere deep below, but somewhat better suited for non-indexed queries.

I would suggest to create an appropriate key and customize the batch job to use that.