Navision posting-Strange problem!

ashimarathi
ashimarathi Member Posts: 10
edited 2008-04-29 in NAV/Navision Classic Client
HI,

My client told me about a strange problem they faced last week. They were in middle of posting some journals when the system just went restarted (dont know why!- prob some Vista thing :evil: ). When they restarted the PC and posted journals again, there are duplicate entries created in ledgers!! I know it sounds weird :?

Can you please help me what would be the best way to solve it, should I reverse all the transactions? They are on Nav 5.0.

Thanks,

Answers

  • kine
    kine Member Posts: 12,562
    It seems that the process was modified and there are some Commits which are doing this problem.
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • arindom
    arindom Member Posts: 52
    R u use navisionserver or SQL server ?
  • ashimarathi
    ashimarathi Member Posts: 10
    arindom wrote:
    R u use navisionserver or SQL server ?

    We are using SQL server.

    Thanks,
  • ashimarathi
    ashimarathi Member Posts: 10
    kine wrote:
    It seems that the process was modified and there are some Commits which are doing this problem.

    Yeap you are right, that developer has written a 'Commit' at some point. What should I now do to re-do my transactions? There are double G/L entries, cust ledger etc. entries created in the system. And the worst part is we dont have a backup prior to this occurence of problem.

    Thanks,
  • bbrown
    bbrown Member Posts: 3,268
    You will need to clean up the bad postings using good ole basic accounting. (post reversing/correcting entries).

    Next get your developer to remove those Commits and recode the process (as needed) to handle possible system failures, which is a standard requirement of any multi-user database system.

    Explicit Commits should be used only when absolutely required. As you see they can have disasterous results when placed in the wrong spot.
    There are no bugs - only undocumented features.
  • NavStudent
    NavStudent Member Posts: 399
    ashimarathi wrote:
    kine wrote:
    It seems that the process was modified and there are some Commits which are doing this problem.

    Yeap you are right, that developer has written a 'Commit' at some point. What should I now do to re-do my transactions? There are double G/L entries, cust ledger etc. entries created in the system. And the worst part is we dont have a backup prior to this occurence of problem.

    Thanks,

    You should find the developer and slap him with a trout, and then fire him.
    The first thing that you are told about Navision programming is to never use COMMIT.
    And the only time you use them is if you are writting your own posting routine or batch process job.
    my 2 cents
  • ashimarathi
    ashimarathi Member Posts: 10
    bbrown wrote:
    You will need to clean up the bad postings using good ole basic accounting. (post reversing/correcting entries).

    Next get your developer to remove those Commits and recode the process (as needed) to handle possible system failures, which is a standard requirement of any multi-user database system.

    Explicit Commits should be used only when absolutely required. As you see they can have disasterous results when placed in the wrong spot.

    Yeah, will try to clean up the data and get rid of the Commits.
    Thank you very much,

    Ashima
  • ashimarathi
    ashimarathi Member Posts: 10
    [/quote]

    You should find the developer and slap him with a trout, and then fire him.
    The first thing that you are told about Navision programming is to never use COMMIT.
    And the only time you use them is if you are writting your own posting routine or batch process job.[/quote]

    Thanks for your help.

    Regards,
    Ashima
  • bbrown
    bbrown Member Posts: 3,268
    The issue is not to never use explicit COMMITs but to understand their implications and to uses them appropriately. In either case they should be used when only absolutely required. When possible, recode to eliminate the need for an explicit commit.

    You will find a number of places where COMMITs are used in the base code. Take a look at CodeUnits 80 and 90.
    There are no bugs - only undocumented features.
  • DenSter
    DenSter Member Posts: 8,307
    It is perfectly fine and acceptable to use COMMIT. The trick is to use it only when a transaction is completed and finished. It always causes problems when it is used in the middle of a transaction, and then after it there's an error. The system then rolls back to the latest COMMIT, and now you have a half completed transaction in the system.
    Daniel Rimmelzwaan
    RIS Plus, LLC
  • ashimarathi
    ashimarathi Member Posts: 10
    DenSter wrote:
    It is perfectly fine and acceptable to use COMMIT. The trick is to use it only when a transaction is completed and finished. It always causes problems when it is used in the middle of a transaction, and then after it there's an error. The system then rolls back to the latest COMMIT, and now you have a half completed transaction in the system.


    Thank you all for your views. The problem has been solved, luckily I got hold on a backup of the system prior to making the postings. But will surely take care of the Commit statement. A commit has been marked in between the transactions, thats why the system didnt roll back to the beginning.

    Thanks again,
    Regards,
    Ashima

Categories