Cust. Ledger Entry & Posting (Performance)

Hi, I am busy looking into various ways of improving performance on Navisoin 3.70A and SQL. so much to do [Sigh…]. Anyway, I have been searching all the forums and thankfully there is a lot of information or tips on what approach is best. I think I recall finding a posting that mentions a key missing on the Cust. Ledger Entry table that would speed up posting. Does anyone recall what this is or is it on another table? I was under the impression that it was a “known bug” but can’t find any valid documentation. Thanks.

Try to run the Client Monitor while posting and identify all “finds” which take long (> 30ms) and check what filter is used and what key is selected (active). It might also help to change the SQL related fields on the keys in the table where the find takes too long.

Yes, I think the Client Monitor is the only option now. BTW, I found that link I mentioned, but don’t think it applies to V3.70…

to optimize posting on table 21 on SQL server, could be useful to optimize SIFT index in table 379. Maintaining sift table in sql has big impact on performance. Usually for each record in table 21 there would be 5 or 6 records in table 379, there’s no need to maintain SIFT in SQL for few records, sql is able to quickly sum the records without sift table. So, remove the flag in MaintainSIFTIndex on the keys containing “Cust. Ledger Entry No.” (perhaps you could remove that flag from almost all the keys in table 379), I would also add a key with only “Customer No.” and on that key enable the MaintainSIFTIndex. But it depends, if you have few entries for each customer, also that SIFT would be useless and slow down the customer ledger posting. hope this helps.

Thanks, any tips on which tables keys can be turned off for, or at least removing the flag “MaintainSIFTIndex” or “MaintainSQLIndex” is helpfull. Ofcourse every installation is different, but I am sure everyone has experience some sort of performance issues with normal posting and applying etc. I am busy compiling a list of all tables I am going to look at specifically for this. Optimizing the tables is another step I am doing.

If you read this thread you will find plenty of advice, also about Indexes/SIFT to maintain …