Apply Claude Code suggestions

Author: MarkvanMents

content/en/docs/refguide/modeling/application-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md

@@ -13,7 +13,7 @@ This activity can be used in both microflows and nanoflows.
 The **Commit object(s)** activity works on one or more objects. For persistable entities, committing an object writes it to the database. Committing non-persistable entities stores the current attribute values and association values in memory. This allows a rollback to revert to those values. See also [Persistability](/refguide/persistability/). External objects cannot be committed. To store changed values of external objects, use the [Send External Object](/refguide/send-external-object/) activity.
 
 {{% alert color="info" %}}
-A Mendix commit does not always behave like a database commit. See [How Commits Work](#how-commits-work), below, for more information.
+A Mendix commit does not always behave like a database COMMIT. See [How Commits Work](#how-commits-work), below, for more information.
 {{% /alert %}}
 
 ## Properties
@@ -133,7 +133,7 @@ When you work on an object in memory, Mendix records whether the object has been
         * The object in memory still has your changes but it was marked as unchanged after your previous commit
         * The **Commit object(s)** activity does not see the changed marker and so does not recognize that your object in memory has changes which need to be written.
 
-    If you want to keep the changes in the version which is in memory, you will have to work around this behavior.
+    If you want to keep the changes in the version which is in memory, you will have to work around this behavior by creating a new object which contains the changes.
 
 * Deleting an object and then committing it has different outcomes depending on whether the object has already been committed or not:
 

content/en/docs/refguide/modeling/application-logic/microflows-and-nanoflows/events/error-event.md

@@ -10,17 +10,17 @@ This event can only be used in **Microflows**.
 
 ## Introduction
 
-An error event defines where a microflow will stop and re-throw an error that occurred earlier. If you call a microflow, you may want to know whether any errors occurred within the microflow or not. This event throws the error again, so the caller of the microflow can catch them.
+An error event defines where a microflow will stop and throw a new error based on the error that occurred earlier. If you call a microflow, you may want to know whether any errors occurred within the microflow or not.
 
-When you use this event, it creates a new error of the type which occurred earlier. Because this is a new error, even if the error that occurred earlier was caught **without rollback**, all database actions within the current transaction will be rolled back (for more information, see [Error Handling in Microflows](/refguide/error-handling-in-microflows/)).
+When you use this event, it creates a new error with the same information as the original error. Because this is a new error, even if the error that occurred earlier was caught **without rollback**, all database actions within the current transaction will be rolled back (for more information, see [Error Handling in Microflows](/refguide/error-handling-in-microflows/)).
 
 {{% alert color="warning" %}}
 You can only use an error event if an error is in scope: Studio Pro does not allow you to connect the normal execution flow to an error event, because there would not be an error to pass back to the caller.
 {{% /alert %}}
 
 ## Example of Error Event
 
-In the example below, an error flow is defined when committing an object to the database. Any error is caught, and the flow continues to the error event where the error is passed back to the caller of the microflow. This allows you to implement your error handling on multiple levels.
+In the example below, an error flow is defined when performing a Mendix commit. Any error is caught, and the flow continues to the error event where the error is passed back to the caller of the microflow. This allows you to implement your error handling on multiple levels.
 
 {{< figure src="/attachments/refguide/modeling/application-logic/microflows-and-nanoflows/events/error-event/error-event.png" class="no-border" alt="A microflow with a parameter of 'MyEntity'. It has a single action committing 'MyEntity' which has an error flow ending in an error event and the normal flow ending in an end event" >}}
 

content/en/docs/refguide/modeling/application-logic/microflows-and-nanoflows/microflows/error-handling-in-microflows.md

@@ -60,7 +60,7 @@ In this example, the error handling in **Microflow 2** is the default: **Rollbac
 When **Microflow 1** starts with a button click, a savepoint is created at the very beginning of **Microflow 1**. When an error occurs in **Microflow 2**, the default error handling is to roll back all changes to the state of this savepoint (so changes made in **Create Order** and in **Create Customer** are both reverted.), **Microflow 2** terminates, then **Microflow 1** terminates, the error is logged, and a system error message is shown to the end-user.
 
 {{% alert color="warning" %}}
-Rollback does not mark any uncommitted objects as changed. See [How Commits Work](/refguide/committing-objects/#how-commits-work) in *Commit Object(s)* to see the implications of this.
+After a rollback, previously committed objects remain marked as unchanged in memory, even though their database state has been reverted. See [How Commits Work](/refguide/committing-objects/#how-commits-work) in *Commit Object(s)* to see the implications of this.
 {{% /alert %}}
 
 ### Error Handling - Custom with Rollback
@@ -214,7 +214,7 @@ To ensure that every end-user or process can only see persisted data, data chang
 When an object is updated, your app will place a write lock on that object until the transaction/microflow ends. While the microflow is running, nothing else can write to that same object and anything that attempts to do so will have to wait. This lock is released automatically as soon as the microflow ends, allowing any waiting processes to continue normally.
 
 {{% alert color="info" %}}
-This doesn't prevent two end-users editing the same object. Two end-users can read the same object and change it. However, neither will see the changes that the other has made. They can both commit the changes and the change committed second will be applied.
+This doesn't prevent two end-users editing the same object. Two end-users can read the same object and change it. However, neither will see the changes that the other has made. They can both commit the changes and the change committed second will overwrite the changes committed first.
 {{% /alert %}}
 
 ## Read More