Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Canceling methodolgy for sets

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Canceling methodolgy for sets

    I am trying to understand the proper methodology of undoing (canceling) changes to records in a form base on a set, including canceling new records. When I say records, I am referring to the complete form, including all the data from all the tables. If I want to give the user the option of saving or canceling before moving to the next record or closing the form, I can do it just fine in a form based on a single table by using the following code in the 'CanSave' and 'CanExit' events.

    Code:
    dim vMode as C
    vMode = parentform.Mode_Get()
    	if vMode <> "VIEW" then
    		dim vAns as N
    		vAns = msgbox("Save?","You have made changes, do you want to save them before leaving?",UI_ATTENTION_SYMBOL+UI_FIRST_BUTTON_DEFAULT+UI_YES_NO_CANCEL)
    		if vAns = UI_YES_SELECTED then
    			'Yes selected,
    			'do nothing, record saved automatically
    		elseif vAns = UI_NO_SELECTED then
    			'No selected
    			topparent.cancel(.t.)
    		elseif vAns = UI_CANCEL_SELECTED then
    			'Cancel selected
    			cancel()
    		end if
    	end if
    end if
    Alpha's help file says:
    In almost every case, Alpha Five treats sets exactly like tables. You can create layouts and perform and save operations for a set. When entering data into a form designed for a set, the information is automatically placed into the correct table along with the necessary linking information.
    But this code does not work for a form base on a set. Alpha saves (commits) the changes to the table for each table affected as you move around on the form. So, what is the proper method of canceling...

    I'll use Alpha Sports for an example...

    Open up Alpha Sports and open the invoice form,

    on any existing invoice; add/change a credit card number in the credit card field,
    then move down and add a line item to the invoice,
    then move up and edit the price on an existing line item...

    ... now cancel all of the above... how do I do it?

    Thanks, Dan
    - Dan Hooley
    - Custom Desktop or Web database development -

  • #2
    Re: Canceling methodolgy for sets

    Dan, on your Invoice form example I'll wager the parent table record is saved automatically when focus shifts to a row in the items browse. Right? This is Alpha's way of assuring no loss in data. The same is true if you start a change in a row in the browse and then shift focus to a field on the form from the parent table. No data loss because the change is commited automatically.

    Because the data is stored in separate tables I think Alpha's design choice is a good one. You wouldn't want the user entering child table records and then have the parent table record get cancelled, leaving orphans behind, for example. In many cases, too, the key field in the primary table is based on an autoincrement field rule. This value is not "fixed" until the primary table record is saved. What you see on screen is only a tentative or preliminary key field value and it will change if another user on the network saves their new primary table record before you.

    So, you're asking a hard question. Basically you're saying you want to abandon the built in safeguards of the table by table commits and roll your own data entry sequences. This can be done of course, but it's a lot of work. Here are some ideas. Perhaps others will have better suggestions for you, too.

    a) Do the data entry using temporary tables, providing the user with a button to push that will create (copy) records from the set's temporary tables to the real ones. I don't see a way this will work with an autoinc field rule in your real tables, but then you may want to roll your own autoinc sequences, too <grin>.

    b) Use xdialogs and data entry fields that are bound to variables. Again, you probably will hve to roll your own autoinc sequence.

    c) Force the user to push a button to begin edits. The button script would store the current records (primary and linked child) in arrays. Put a button on the form to cancel all edits. Have that button overwrite the edited records with original field values.

    If you head down this path you will need to plan for undoing single record enters, edits, and deletes, as well as undoing composite record enters, edits, or deletes. Not an easy task.

    In my own work I shift the responsibility to the user where possible. Before permitting focus to shift to an embedded browse I check the mode of the form and if it's not VIEW I ask the user to cancel or save edits before proceedings. Ditto when the user wants to shift focus away from an embedded browse. This prevents the "accidental" save that's built in by default.

    -- tom
    Last edited by Tom Cone Jr; 04-22-2008, 02:10 PM.

    Comment


    • #3
      Re: Canceling methodolgy for sets

      Why would the data be lost when it is still on the screen? Wouldn't there be just as much chance of data lose on a form based on a single table? It's not committed until you go to the next record or close the form. That is all I want with a set. Why do I need to explain to my user (just for forms based on sets) that certain data is coming from multiple tables and therefore needs to be save individually? How does QuickBooks do it. I can change any part of an invoice, PO, Bill, etc, (existing or new) all day long, and turn around and cancel the whole thing. This was a problem in Access and I was hoping Alpha would be different. It creates a lot of work for the programmer to have to figure out a way around this, unless someone has a simple solution. I wonder what the Alpha programmers would say.

      Dan
      Last edited by danh; 04-22-2008, 05:39 PM.
      - Dan Hooley
      - Custom Desktop or Web database development -

      Comment


      • #4
        Re: Canceling methodolgy for sets

        I'm sure the folks at Intuit worked very very hard to make things seem seamless. Perhaps others will have better suggestions for you. My guess is that you'd be happier with a form upon which all the objects were bound to variables, using a single event or button click to save or cancel all edits. This runs counter to the flow of typical Alpha Five forms. The design choice was made long ago to bind the form and its objects to the underlying data structures automatically, by default. This has many benefits. Unwinding a set based transaction is not one of them. -- tom
        Last edited by Tom Cone Jr; 04-22-2008, 05:34 PM.

        Comment


        • #5
          Re: Canceling methodolgy for sets

          edit: sorry Tom, I was slow typing with both fingers.


          Dan,

          You have the option as a programmer to make your own screen with all variables on it. copy the data from a file and then modify all you want. Once modified, you can the put the changes back in the table(s) or cancel and nothing is changed.
          It is a lot of work, but you can do this.

          If you work with alpha as it is with the drawn forms, you are kinda doing the same thing, but as soon as you do something(knowingly or not) to save it, it cannot revert back.

          Now think of this. If you redo your sets to cascade/changes and deletes? for the cihild tables? It may help you. You can also setup to copy the previous record to a new one(button) and change as needed then copy changes back. You can have 2 sets with identical(but not the same tables) to post back and forth.

          I am just giving methods here: I just delete what I don't want, but the delete button just marks the record so i don't see it again. Later, i may really delete it.

          Another note:
          If you had the same problem in access and alpha, it would be to presume that you will with anything else and since the programs are not going to change, the solution is..............?

          I do have 2 out of a bunch of forms that have nothing on them but variables. There are reasons for it, but most of the time it is not as good.

          EDIT: One more way, you can always copy all the fields into vars or an array and if you want to revert back, set it to a button to reput the data.
          Last edited by DaveM; 04-22-2008, 05:44 PM.
          Dave Mason
          [email protected]
          Skype is dave.mason46

          Comment


          • #6
            Re: Canceling methodolgy for sets

            Dan

            What you are looking for is a 'two-phase commit' model.

            The default Access or Alpha model doesn't use that technique.

            It usually consists of a statement that starts a transaction, does the steps of the transaction, then finishes with a transaction end statement. Then and only then is the data viewable by any other users. That includes the current user opening the same data in another session.

            I haven't tried that model with Alpha 5 on a database that supports the 'two-phase commit' and whether you can start a transaction and later finish it or abandon it. Perhaps someone else has and can comment.

            So you can try that or try one of these other options.
            1. variables - as listed previously
            2. assign a transaction id to each of the components of the transaction and build your own two-phase commit. Either save the components or roll back through the tables and remove the components with the given transaction id.

            Personally I'd try the database that supports it first.
            Al Buchholz
            Bookwood Systems, LTD
            Weekly QReportBuilder Webinars Thursday 1 pm CST

            Occam's Razor - KISS
            Normalize till it hurts - De-normalize till it works.
            Advice offered and questions asked in the spirit of learning how to fish is better than someone giving you a fish.
            When we triage a problem it is much easier to read sample systems than to read a mind.
            "Make it as simple as possible, but not simpler."
            Albert Einstein

            http://www.iadn.com/images/media/iadn_member.png

            Comment


            • #7
              Re: Canceling methodolgy for sets

              Hi,
              am wondering why a blob variable hasn't been considered using <tbl>.record_data_get() and <tbl>.record_data_set(). I have used this very effectively in "cancelling" actions after committing. Set the records to the blob prior to making any changes, then if a user wants to cancel changes made and committed, then set the record values back to the blob value.

              I have a couple of forms in which I do this---mainly when the parent record has to be committed prior to creating the child. If a user gets to this point the child can still be simply cancelled, and then the parent's value gets set back to its initial value that the blob variable holds.

              Is there something that is incorrect in this procedure ?? Sure seems to work and work easily.
              Mike
              __________________________________________
              It is only when we forget all our learning that we begin to know.
              It's not what you look at that matters, it's what you see.
              Henry David Thoreau
              __________________________________________



              Comment


              • #8
                Re: Canceling methodolgy for sets

                Mike,

                Maybe wrong, but I think it is similar to an array. or copying to seperate variables. and changing it back if nec.

                I do have one form that calls an identicla form that rolls payments(all variables in second form). If the change is liked, the changes are made to the first form.
                Dave Mason
                [email protected]
                Skype is dave.mason46

                Comment


                • #9
                  Re: Canceling methodolgy for sets

                  Hi Dave,
                  My point I guess is using <tbl>.record_data_get() and....set() can be as simple as getting the data of the parent into a blob from the button that opens up a child form using <tbl>.record_data_get(). If once on the child form and the user wants to cancel then a simple cancel does it for the child usually (if the record is not saved of course). Then if the parent also is wanted to be cancelled, then simply have the <tbl>.record_data_set() on a cancel button for the parent.

                  Two steps and, depending on how the forms are set up, possibly only two lines of script. Sure sounds like less overhead/maintenance than the other ways.
                  Mike
                  __________________________________________
                  It is only when we forget all our learning that we begin to know.
                  It's not what you look at that matters, it's what you see.
                  Henry David Thoreau
                  __________________________________________



                  Comment


                  • #10
                    Re: Canceling methodolgy for sets

                    MIkeC, I'd be interested in seeing a working example of this. Always ready to learn something new! Thanks. -- tom

                    Comment


                    • #11
                      Re: Canceling methodolgy for sets

                      Sure thing Tom--I made it slightly more involved than what I mentioned in the post but still a very easy way to "cancel" commited changes. A text box on the form should explain things. I used mostly Action Script where I could easily so that most here should be able to use this.

                      Mike
                      __________________________________________
                      It is only when we forget all our learning that we begin to know.
                      It's not what you look at that matters, it's what you see.
                      Henry David Thoreau
                      __________________________________________



                      Comment


                      • #12
                        Re: Canceling methodolgy for sets

                        Originally posted by MikeC View Post
                        Hi Dave,
                        My point I guess is using <tbl>.record_data_get() and....set() can be as simple as getting the data of the parent into a blob from the button that opens up a child form using <tbl>.record_data_get(). If once on the child form and the user wants to cancel then a simple cancel does it for the child usually (if the record is not saved of course). Then if the parent also is wanted to be cancelled, then simply have the <tbl>.record_data_set() on a cancel button for the parent.

                        Two steps and, depending on how the forms are set up, possibly only two lines of script. Sure sounds like less overhead/maintenance than the other ways.
                        Sounds to me like this would work BUT what if the parent record did not exist and then you wanted to cancel it after starting the first child record? In this case, I think the only option would be to delete the parent record. (i.e., IF blob is empty and record canceled, THEN delete the record rather than resetting to the original blob values.)

                        As for autoincrementing if using temporary tables or variables, I think that could be handled fairly easily. First, use any linking value in the temp tables. Then, since the results would have to be added to the "real" tables via xbasic, first save the parent table and get the autoincremented value after saving the record, then just add that autoincremented value into the appropriate field of the child tables as each child record is created.

                        Comment


                        • #13
                          Re: Canceling methodolgy for sets

                          Cal,
                          In the forms that I use this method, I have a few error traps that go along with what you are saying as well as a CanSave script that prevents the saving of a "blank" record--so with this in place (or a delete script as you mentioned and I have a couple of those as well in other places), even if the blob="" and this resulted in basically a blank record it simply would not be saved.

                          You do bring up some very valid points---as with most solutions/ways of doing things, there are going to be various error traps that will be necessary especially if there will be more than one user.
                          Mike
                          __________________________________________
                          It is only when we forget all our learning that we begin to know.
                          It's not what you look at that matters, it's what you see.
                          Henry David Thoreau
                          __________________________________________



                          Comment


                          • #14
                            Re: Canceling methodolgy for sets

                            Originally posted by MikeC View Post
                            Cal,
                            In the forms that I use this method, I have a few error traps that go along with what you are saying as well as a CanSave script that prevents the saving of a "blank" record--so with this in place (or a delete script as you mentioned and I have a couple of those as well in other places), even if the blob="" and this resulted in basically a blank record it simply would not be saved.
                            Think "Enter totally new record - including parent" vs. "Change existing record." Unless I'm misunderstanding something, I believe you would have to save the parent record initially in order to start the child record. If the user then decided to cancel the whole thing, the parent record would have to be deleted because it didn't even exist initially. I doubt it would be acceptable to just leave it blank.

                            Comment


                            • #15
                              Re: Canceling methodolgy for sets

                              Yep Cal,

                              That scenario is exactly where I have a delete operation in place.

                              The best way the Blob works is when a parent record is edited and commited and then a child record is brought up and the user wants to cancel everything. The child changes usually do not have to be saved and so these changes can just be cancelled. Once back on the parent form the blob can be used to cancel the changes made.

                              I find that the latter is most prevalent and the blob deals with it easily.

                              The other case in which a new parent is created as you referred to needs to have a delete operation--again fairly easy to incorporate.

                              I think here is another aspect of Alpha that should be placed in a FAQ or Newbie forum as am sure it is a question that will keep coming up time and again.
                              Last edited by MikeC; 04-22-2008, 11:34 PM.
                              Mike
                              __________________________________________
                              It is only when we forget all our learning that we begin to know.
                              It's not what you look at that matters, it's what you see.
                              Henry David Thoreau
                              __________________________________________



                              Comment

                              Working...
                              X