When can I use Commit function?
Hi, You can use the COMMIT function to end the current transaction and start the new transaction.
With COMMIT you submit changes made to database. You must use COMMIT after .MODIFY, .INSERT, .RENAME functions.
quote:
You must use COMMIT after .MODIFY, .INSERT, .RENAME functions
Isn’t that only half the story?.. it’s only true IF you want to run… - A form with .RUNMODAL - A Dataport or Report with .RUNMODAL if the requestform is used - A Codeunit function with a returnvalue …after using one of the commands you listed, but before the system has stopped running the current transaction. Supawan, just make sure you’re clear about what data you will have changed should an error occur after the COMMIT in your code.
quote:
Originally posted by Arthur
You must use COMMIT after .MODIFY, .INSERT, .RENAME functions.
Arthur, watch out for those infamous “modal verbs” in the English language.[;)] Writing “You must” is a bit dangerous here - it suggests that you have to use a COMMIT every time you make modifications in the database, which, of course, is not the case. COMMIT should be used only when you want to save all the changes you have made so far, even if the rest of your code throws an ERROR.
Yes, of course if you want changes to be saved you must use COMMIT. Sorry for my bad English [:)]
quote:
Originally posted by Arthur
Yes, of course if you want changes to be saved you must use COMMIT.
Let’s try to keep this thread not too confusing [:D]- If you want your changes to be saved, you must avoid any ERRORs. [;)]
- It is not necessary to use COMMIT just to save your changes - this will automatically be performed by the system when the transaction ends without an ERROR.
- Only if you decide that your changes should be saved right in the middle of a transaction which will then be continued, you can and must use COMMIT. You also must use a COMMIT in the cases described above, i.e. before a RUNMODAL etc.
Oh, and I did not intend to call your English “bad”, Arthur. I think it’s the second language for most of us, and even native speakers sometimes tend to make mistakes in their own language [B)]. Just like a single bug does not make a bad program, a single misplaced word does not make a bad speaker [;)] - and who am I to critisize other people’s language abilities?
quote:
Originally posted by xorph [*]It is not necessary to use COMMIT just to save your changes - this will automatically be performed by the system when the transaction ends without an ERROR.
It’s not true. Even if your code runs without any error changes will not be saved in database untill COMMIT (tested). COMMIT is needed only in code to submit code not user actions.
quote:
It’s not true. Even if your code runs without any error changes will not be saved in database untill COMMIT (tested). COMMIT is needed only in code to submit code not user actions.
Well, I guess that’s 95% of my code that shouldn’t work then… Seriously, this is from the horse’s mouth (C/SIDE Reference Guide):
quote:
When the system exits a C/AL code module, it automatically ends the write transaction by committing the updates made by the C/AL code. This means that if you want the C/AL codeunit to perform a single write transaction, the system automatically handles it for you. However, if you want the C/AL codeunit to perform multiple write transactions, you must use the COMMIT function to end one write transaction before you can start the next. The COMMIT function separates write transactions in a C/AL code module.
quote:
Originally posted by Arthur
It’s not true. Even if your code runs without any error changes will not be saved in database untill COMMIT (tested).
[?][?][?] Erm… Now you did confuse me.[;)] I have written numerous objects of all sorts that did and still do modify the database - and I have never written a single COMMIT in my entire life [:D] (except maybe for the cases where a COMMIT was required before a RUNMODAL). Could you please be a bit more specific about how you did test this behavior?
I’m surprised of your answers but I used to modify value of fields without commiting them. No changes were made to table data (in report). Also wrote some code that inserts records without commit to test the code. No records were added. So what I don’t understand and do wrong??? I was 100% sure COMMIT works this way [:)] Every day brings something new [:)].
Arthur, without looking at your code and the exact circumstances of its execution we can only make wild guesses about what went wrong. For example, IIRC it does make a big difference if a dataport is executed from within design mode with Ctrl+R or from the designer with “Run”. But rest assured that an explicit COMMIT is almost never necessary [:)]
just adding my two cents, I guess COMMIT is one of those “unclear” functions in C/SIDE… as several point out, and mentioned in the online help, you do not need to COMMIT to write changes to the db, whenever your process finished Navision handles this automatically, e.g. most Navision standard processing only reports do not have a COMMIT at the end. Rather I have been told in the Navision courses, that the use of COMMIT is not recommendable because you might write changes to the db without being sure that the entire process will be processed correctly and you might end up with half way processed data. A necessary use of COMMIT arises from the versioning principle that Navision uses. Consider the following scenario: 1) you use a record variable to change data, in the end you MODIFY (e.g. T18 customer) 2) the process continues and you open the same table (T18) with a new record variable record variable (Customer2). As the “version” of 1) has not yet been “commited”, the Customer2 variable won’t contain the changes of step 1… In this case, you either use again the inicial customer variable, or use commit to write the changes of step 1 to the database, but be sure that you won’t end up with mixed up data. C80 is a good example (as always), initially there are certain write transactions on vbles that get commited, in order to work with these changed variables all along. Hope I made myself understood. [;)] Nils
hi Use Commit only when there is no other option to work out a given problem.Some time using COMMIT will lead you to deep trouble [:D] Harikesh
v3.60A This is a rather timely discussion, as it pertains to a situation that I have just encountered.The customer wants the Sales Order to be archived, then have the Bill of Materials exploded automatically when the order is Released. Using the following code: OnPush()
ArchiveManagement.ArchiveSalesDocument(Rec); CurrForm.UPDATE(FALSE); CurrForm.SalesLines.FORM.ExplodeBOM;
Causes the error message regarding “form with .RUNMODAL… Dataport or Report with .RUNMODAL…” etc. If the functionality to explode the BOM is removed, the Order is archived and released. I have not been able to get the third action to take place. Any suggestions on automating this series of events would be appreciated. Rick.
First thing that comes to mind is using a COMMIT after the update… but it will give you trouble if you do: After calling the ArchiveManagement function on the header and doing the CurrForm.UPDATE you’ll have lost the actual record that was on the saleslines subform (let’s say you were on line 50000 after the update you’ll be on line 10000), so the explodeBOM could give you an error. An idea could be checking the ExplodeBOM function on the subform, keeping the line no. on a variable before running the archivesalesdocument function, then having your own function for exploding the BOM as you have the line no. you’re wanting to explode and then doing the CurrForm.UPDATE. Regards,
Except for the example of Nils, there is rarely the circumstance to use COMMIT. I have learned much about transactions when I was working with another database, whereas in Navision it is not explained extensively. Although I have read about it (Programming Manual?). But the concept of transaction has much to do with COMMIT. Michael
Nils, can you explain what you mean. I think there is a problem with what you’re saying. I assume what you mean is that MODIFY etc do not make database changes until COMMIT is done, and therefore those changes are not public to other reads and modifications? Public meaning for example available to other record variables other than the one that did the modify. This is not the case. Take this example: C1.GET('BR'); C1.Name := 'xxx'; C1.MODIFY; C2.GET('BR'); C2.Name := C2.Name + 'yyy'; C2.MODIFY; The C1.MODIFY wrote to the database and any other variable reading that record gets that modified value. In my example the Name field contains ‘xxxyyy’. There is no need for COMMIT. There is no pollution of the issue with the versioning that the Navision database uses. Its a clear requirement that all data read/written within a user’s transaction must be consistent. Perhaps you meant something else?
Hi Robert, actually I did exactly refer to the case you are testing, I might have forgotten to include a step which involves calling a new object (e.g. codeunit fuction, processing only report) which then calls again the first variable. It looks like if you are in the same object, the handling is ok, but in case of working with several opbjects the COMMIT is necessary to have initial changed variable for the new object. Anyone else could shed some light on this strange issue… [xx(] Saludos Nils
Do you have any example source code?