locked
close all tables at data session RRS feed

  • Question

  • how can i close all tables open on data session?
    Tuesday, January 1, 2013 2:28 PM

Answers

  • Ending the datasession is the natural way, that is closing the form. You don't need to do anything.

    Naomi is totally right you can CLOSE TABLES ALL, but this will cause all kinds of errors, if controls are still bound to controls. You don't have to do anything, the session cleans itself.

    The question is: What is your problem? Why do you want to close tables? Does a session not end? Do you get any errors in databinding?

    There are a few things to consider in regard of form datasessions, transactions and locking. In the first place, the main reason a session stays open and still is listed in the dropdown list of the datasession window, if there are open transactions involved and so DBFs are really locked.

    Cleanup code for that situation would rollback open transactions:

    Do While Txnlevel()>0
       Rollback
    EndDo

    In contrast, uncomitted changes in buffers are no problem, they will be auto-committed, as far as they aren't in conflict with locks, concurrent changes or - again - transactions. 

    Bye, Olaf.

    PS: Another thing: AutoCloseTables.

    If your form has it's datasession property set to the default session, the data environment property AutoCloseTables comes into play. If your form works in the default data session that simply means it works in the datasession that was active, when the form started, so it shares that session with other forms or objects. It's not good to set this .T. then, as you don't just close the tables your form uses, but also close tables of other form, eg the main form.

    Another reason to go for private datasessions with each form as the normal case and only start a form in the default session, when you know why and how to share the same open tables and don't close them while they're still needed. You can share the same DBFs via private datasessions, too, reopening them in each session, with the disadvantage to need to reposition and set order, but you certainly share the data the same way as it's shared between multiple users.


    • Edited by Olaf Doschke Tuesday, January 1, 2013 7:50 PM
    • Proposed as answer by Pavel Celba Wednesday, January 2, 2013 10:25 AM
    • Marked as answer by Youen Zen Thursday, January 10, 2013 8:34 AM
    Tuesday, January 1, 2013 7:49 PM

All replies

  • Look at the CLOSE TABLES ALL in Help.

    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Tuesday, January 1, 2013 2:53 PM
  • Ending the datasession is the natural way, that is closing the form. You don't need to do anything.

    Naomi is totally right you can CLOSE TABLES ALL, but this will cause all kinds of errors, if controls are still bound to controls. You don't have to do anything, the session cleans itself.

    The question is: What is your problem? Why do you want to close tables? Does a session not end? Do you get any errors in databinding?

    There are a few things to consider in regard of form datasessions, transactions and locking. In the first place, the main reason a session stays open and still is listed in the dropdown list of the datasession window, if there are open transactions involved and so DBFs are really locked.

    Cleanup code for that situation would rollback open transactions:

    Do While Txnlevel()>0
       Rollback
    EndDo

    In contrast, uncomitted changes in buffers are no problem, they will be auto-committed, as far as they aren't in conflict with locks, concurrent changes or - again - transactions. 

    Bye, Olaf.

    PS: Another thing: AutoCloseTables.

    If your form has it's datasession property set to the default session, the data environment property AutoCloseTables comes into play. If your form works in the default data session that simply means it works in the datasession that was active, when the form started, so it shares that session with other forms or objects. It's not good to set this .T. then, as you don't just close the tables your form uses, but also close tables of other form, eg the main form.

    Another reason to go for private datasessions with each form as the normal case and only start a form in the default session, when you know why and how to share the same open tables and don't close them while they're still needed. You can share the same DBFs via private datasessions, too, reopening them in each session, with the disadvantage to need to reposition and set order, but you certainly share the data the same way as it's shared between multiple users.


    • Edited by Olaf Doschke Tuesday, January 1, 2013 7:50 PM
    • Proposed as answer by Pavel Celba Wednesday, January 2, 2013 10:25 AM
    • Marked as answer by Youen Zen Thursday, January 10, 2013 8:34 AM
    Tuesday, January 1, 2013 7:49 PM