SIFT calculation bug for SQL Server Option 3.60

meranamerana Member Posts: 41
edited 2006-02-23 in Navision Attain
I have a situation with wrong Amount calculated on GL Entry for "G/L Account No.,Posting Date" key. If I sum all amounts in GL entry for specified account, the result is not the same as calculated Amount field on that same account. I found a difference between tables $17$0 and G_L Entry for a specific date and account (for all bucket levels from day to year). It seems that SQL Server did not execute SIFT trigger on G_L Entry in a right way. If I recreate that key, things get correct.
Is anyone familiar with this problem?

Answers

  • DenSterDenSter Member Posts: 8,307
    Have you or your customer ever tried to modify the trigger code on SQL Server?
  • kinekine Member Posts: 12,562
    No, I had never problems with SIFTS, but of course, you can rebuild the sifts by modifying the key and save the object (for example remove all SumIndexFields in the key, save, add the fields back, save)
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • meranamerana Member Posts: 41
    The trigger wasn't changed definitely, even none (neither we or our customers) should know about its existence if we talk about Navision functionality only.
    There is no problem to fix it but to identify such a situation:
    It seems only 1 entry out of about 250000 GL entries missed to be registered by SIFT trigger; I didn't checked other accounts or even other tables and sumindexfields because it is a lot of processing and manual work to get all tables data on all keys for all SIFT levels using SQL queries and compare it with precalculated SIFT tables).

    By the way,I discovered this bug accidentally while checking something else.


    Thanks for the replies!
  • meranamerana Member Posts: 41
    Hello,

    We found the cause of the problem. We used DTS (SQL server Export/Import wizard) to import data in the table and DTS doesn't fire a trigger on insert by default.
    (We had to import a few GL entries because they were deleted by accident and it seemed much easier to do it using DTS than dataports or entering it manually).


    :D
  • DenSterDenSter Member Posts: 8,307
    Thanks for updating us, I was worried there may actually be a bug in SIFT on SQL Server. Were you able to rebuild your SIFT tables though?
  • PhennoPhenno Member Posts: 630
    DenSter wrote:
    Thanks for updating us, I was worried there may actually be a bug in SIFT on SQL Server. Were you able to rebuild your SIFT tables though?

    Yes, we were able to rebuild SIFT tables by remove/adding keys (that made keys to rebuild it selfs automatically
Sign In or Register to comment.