Rollback

roshandilruk · 2006-11-02

Hi All,

I have a senario, that a night batch job for some process some times get fails, it doesnt happen every time. To track where it fails, I m writing to a text file when batch job runs. I'm write few data line by line as the batch job execute. Well the idea is if batch job get fails I can find the last record in the text file and then can continue investigation from that point, means I will get to know where exactly the batch job got failed.

But my question is, if the batch job fails, navision will roll back everything, so will this text file remain with the written data???? or will the text file also get clear???

Plz help!

roshandilruk · 2006-11-02

BlackTiger wrote:

Best way to log:

1. Open file
2. Write (append) message/line
3. Close file

Navision buffers file writes and sometimes you will loose all buffered output.

Can anybody confirm this plz??

Kowa · 2006-11-02

I would use a new batch log table instead. That is the only way to be sure that the exact point of failure is the last entry.

Miklos_Hollender · 2006-11-02

Navision surely does not roll back text file operations. So it's a good idea. What BlackTiger suggests is OK as there is no "autoflush" option for text files, so it's safer this way.

Kowa, for that you'd need to issue commits.

Kowa · 2006-11-02

Miklos Hollender wrote:

Kowa, for that you'd need to issue commits.

I assumed that some process is repeated several times. In that case a commit at the end of the process is unavoidable, otherwise the whole batch is rolled back when an error occurs.

David_Singleton · 2006-11-02

Just an important point.

In Navision there is no such thing as "Rollback", in fact this is one of the fundamental reasons that runnig Navision on SQL can be probematic.

Navision uses what is called the Version Principle. As a function of this, Navision has no need for Row locking, an instead is able to work with Optomistic concurrency.

Normally I would say that anyone who wants to seriously program in Naviison needs a clear understanding of the Version Principle that it uses, though with Navision strongly heading to SQL, maybe that is not so valid anymore.

In a Roll back system, you maintain a transaction log, and if a "roll back" is required AT THE END OF THE TRANSACTION, then you simply unapply all the changes that were made in that transaction. With the version principle, AT THE BEGINING of the transaction, you make a duplicate of all the records you are about to change, and you make your changes only to the copy. Once your transaction (its not really a transaction in Navision, but lets just call it that) is complete your tell the server to change its pointers to your copy, and then that becomes the valid data. If you never reach the point of the COMMIT where the pointer is changed, then the original data is unchanged. Now since the copy is made in what is called COMMITCACHE, there is no significant system overhead, since its in ram anyway. But the advanage is that for most ERP type transactions there is no need to lock tables, since if there is a clash, you simply do not commit the clashed data. Of course this means that if you write code (like say dimensions) with SQL row locking in mind, then you are going to have problems, but that is for another thread.

Anyway in your case, its not that the system is rolling back, its simply that the version was never committed.

David_Singleton · 2006-11-03

BlackTiger wrote:

Hmmm... Not quite true about "versioning". Just imagine some table(s) with several millions of records...

...

Its very important to understand The Version Principle to write good code in Navision. It does not matter if there are 10 million records, Navision only versions the ones you are using.

Rollback

Comments

Categories