• #34131
     Anjali #8
    Forcetalks

    Limitations of using a Savepoint in apex

    What are the limitations of using a Savepoint in apex?

    #34137
    Forcetalks

    Hello,

    Limitations of using a Savepoint are :-

    • If you set more than one savepoint, then roll back to a savepoint that is not the last savepoint you generated, the later savepoint variables become invalid.

    • Each savepoint you set counts against the governor limit for DML statements.
    • Static variables are not reverted during a rollback. If you try to run the trigger again, the static variables retain the values from the first run.
    • Each rollback counts against the governor limit for DML statements. You will receive a runtime error if you try to rollback the database additional times.
    • The ID on an sObject inserted after setting a savepoint is not cleared after a rollback.

    Thanks.

    #34140
    Forcetalks

    Hi Anjali,

    Limitations of using Savepoint in apex are:

    • If you set more than one savepoint, then roll back to a savepoint that is not the last savepoint you generated, the later savepoint variables become invalid. For example, if you generated savepoint SP1 first, savepoint SP2 after that, and then you rolled back to SP1, the variable SP2 would no longer be valid. You will receive a runtime error if you try to use it.
    • References to savepoints cannot cross trigger invocations because each trigger invocation is a new trigger context. If you declare a savepoint as a static variable then try to use it across trigger contexts, you will receive a run-time error.
    • Each savepoint you set counts against the governor limit for DML statements.
    • Static variables are not reverted during a rollback. If you try to run the trigger again, the static variables retain the values from the first run.
    • Each rollback counts against the governor limit for DML statements. You will receive a runtime error if you try to rollback the database additional times.
    • The ID on an sObject inserted after setting a savepoint is not cleared after a rollback. Create an sObject to insert after a rollback. Attempting to insert the sObject using the variable created before the rollback fails because the sObject variable has an ID. Updating or upserting the sObject using the same variable also fails because the sObject is not in the database and, thus, cannot be updated.
    #34148
    Salesforce | Parul Parul #2
    Forcetalks

    Hi,

    Below some limitations are mentioned :

    Each savepoint you set counts against the Governor limit for DML statements.
    If you insert the ID on an SObject after setting the savepoint, the ID will not be cleared after a rollback.
    Static variables are not reverted during a rollback. If you run the trigger again, the static variables will retain the values from the previous run.

     

    Thanks.

    #34156
     Prachi #9
    Forcetalks

    hi,

    The limitations of Savepoint or Transaction Control in Apex are:

    1. Each savepoint you set counts against the governor limit for DML statements.
    2. Static variables are not reverted during a rollback. If you try to run the trigger again, the static variables retain the values from the first run.
    3. Each rollback counts against the governor limit for DML statements. You will receive a Runtime error if you try to rollback the database additional times.
    4. The ID on an sObject inserted after setting a savepoint is not cleared after a rollback.

    Thanks

    #34201
    Salesforce | shariq shariq #1
    Forcetalks

    Hi,

    All requests are delimited by the trigger, class method, Web Service, Visualforce page or anonymous block that executes the Apex code. If the entire request completes successfully, all changes are committed to the database. For example, suppose a Visualforce page called an Apex controller, which in turn called an additional Apex class. Only when all the Apex code has finished running and the Visualforce page has finished running, are the changes committed to the database. If the request does not complete successfully, all database changes are rolled back.

    Sometimes during the processing of records, your business rules require that partial work (already executed DML statements) be “rolled back” so that the processing can continue in another direction. Apex gives you the ability to generate a savepoint, that is, a point in the request that specifies the state of the database at that time. Any DML statement that occurs after the savepoint can be discarded, and the database can be restored to the same condition it was in at the time you generated the savepoint.

    The following limitations apply to generating savepoint variables and rolling back the database:

    • If you set more than one savepoint, then roll back to a savepoint that is not the last savepoint you generated, the later savepoint variables become invalid. For example, if you generated savepoint SP1 first, savepoint SP2 after that, and then you rolled back to SP1, the variable SP2 would no longer be valid. You will receive a runtime error if you try to use it.
    • References to savepoints cannot cross trigger invocations because each trigger invocation is a new trigger context. If you declare a savepoint as a static variable then try to use it across trigger contexts, you will receive a run-time error.
    • Each savepoint you set counts against the governor limit for DML statements.
    • Static variables are not reverted during a rollback. If you try to run the trigger again, the static variables retain the values from the first run.
    • Each rollback counts against the governor limit for DML statements. You will receive a runtime error if you try to rollback the database additional times.
    • The ID on an sObject inserted after setting a savepoint is not cleared after a rollback. Create an sObject to insert after a rollback. Attempting to insert the sObject using the variable created before the rollback fails because the sObject variable has an ID. Updating or upserting the sObject using the same variable also fails because the sObject is not in the database and, thus, cannot be updated.

    Example –

    Account a = new Account(Name = ‘xxx’); insert a;
    System.assertEquals(null, [SELECT AccountNumber FROM Account WHERE Id = :a.Id].
    AccountNumber);

    // Create a savepoint while AccountNumber is null
    Savepoint sp = Database.setSavepoint();

    // Change the account number
    a.AccountNumber = ‘123’;
    update a;
    System.assertEquals(‘123’, [SELECT AccountNumber FROM Account WHERE Id = :a.Id].
    AccountNumber);

    // Rollback to the previous null value
    Database.rollback(sp);
    System.assertEquals(null, [SELECT AccountNumber FROM Account WHERE Id = :a.Id].
    AccountNumber);

    Hope this helps.

    #34735
    Forcetalks

    Hi,

    Sometimes during the processing of records, your business rules require that partial work (already executed DML statements) be “rolled back” so that the processing can continue in another direction. Apex gives you the ability to generate a savepoint, that is, a point in the request that specifies the state of the database at that time. Any DML statement that occurs after the savepoint can be discarded, and the database can be restored to the same condition it was in at the time you generated the savepoint.

    #35034
     Prachi #9
    Forcetalks

    hi,

    Hi Anjali,

    Limitations of using Savepoint in apex are:

    If you set more than one savepoint, then roll back to a savepoint that is not the last savepoint you generated, the later savepoint variables become invalid. For example, if you generated savepoint SP1 first, savepoint SP2 after that, and then you rolled back to SP1, the variable SP2 would no longer be valid. You will receive a runtime error if you try to use it.
    References to savepoints cannot cross trigger invocations because each trigger invocation is a new trigger context. If you declare a savepoint as a static variable then try to use it across trigger contexts, you will receive a run-time error.
    Each savepoint you set counts against the governor limit for DML statements.

    thanks

Viewing 8 posts - 1 through 8 (of 8 total)

Please to reply to this topic.

CONTACT US

We're not around right now. But you can send us an email and we'll get back to you, asap.

Sending

About Us

Forcetalks is a Salesforce collaboration platform for coders & developers, geeks & nerds, consultants & business heads, admins & architects, managers & marketers and of course the business owners. A community where you can learn from, where you can contribute to. For you. For Salesforce. Read More...

Copyright 2018 Forcetalks. All Right Reserved.

Log in with your credentials

or    

Forgot your details?