Navision posting-Strange problem!

ashimarathi

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,

kine

It seems that the process was modified and there are some Commits which are doing this problem.

arindom

R u use navisionserver or SQL server ?

ashimarathi

arindom wrote:

R u use navisionserver or SQL server ?

We are using SQL server.

Thanks,

ashimarathi

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

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.

NavStudent

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.

ashimarathi

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

[/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

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.

DenSter

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.

ashimarathi

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