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

  • #16
    Re: Canceling methodolgy for sets

    I use a utility(my word) script on close of the database that checks the tables for blanks and deletes all blank table fields. This applied to the tables I have found with that problem.
    Dave Mason
    [email protected]
    Skype is dave.mason46

    Comment


    • #17
      Re: Canceling methodolgy for sets

      MikeC,

      If I am understanding your solution correctly, you are talking about opening up the child record(s) in a separate form and canceling or saving each child record individually. What about a form with an embedded browse where the user can change the parent record and/or one or more child records directly from the open form, as in Alpha Sorts invoice form? Any ideas??

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

      Comment


      • #18
        Re: Canceling methodolgy for sets

        Just a note about Quickbooks. I am guessing that there is a flag set when a new record is entered even though the record is saved during data entry (it can be printed eg.); the flag is not "committed" until the user either moves off the record or uses one of the save buttons. Such a flag would help in determining whether posts occur or not. Since QB seems to make deletion/ clearing of records while still on the record, pretty effortless. The setting of such a flag dependent upon mode would not be that difficult. QB is probably trapping all the navigation keys to test the setting of this flag.

        Just my thoughts.
        Robin

        Discernment is not needed in things that differ, but in those things that appear to be the same. - Miles Sanford

        Comment


        • #19
          Re: Canceling methodolgy for sets

          Dan,

          I think Robin is Correct in how it would be set up. There is no easy way to set a variable to more than just the one record that is changed...but if this was a case in which it HAD to be done, I think with a lot of script it could be accomplished. I really don't think it would be worth the effort. Stick to being able to cancel only one child and one parent record as it is not that hard to do this with the method I use or the others that have been suggested. In the child embedded browse you refer to you would have to make it so that if a record was edited or changed then the only way to cancel it would be prior to moving off the record--I experimented around with the sample I gave in attempting this and am close but when allowed to move off the changed record it gets a bit complicated (for me!! :) ).

          Again, I would keep to one record (of parent and one of child) to cancel.
          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


          • #20
            Re: Canceling methodolgy for sets

            Maybe I am being difficult, but I'm really not satisfied with limiting myself to one parent and one child. I'll go back to my previous post; 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? The user sees the whole form and all the data in it and doesn't know (or need to, in my mind) that it is from different tables and needs to be handled differently. I really want to come up with a way to cancel any changes to any data in the set.

            The problem seems to be with the child records. Could you call multiples of the same variable for the child records from the CanRowChange (or similar) event of the embedded browse?

            Or would I be better off from a secure point of view to copy all data to a different table/set and edit from there and then when saved, overwrite the data in the first table/set?

            Also, just ran across something in the help file I thought was interesting. Look in the 'how to...' for "Tracking Changes to Table Fields". Could I use a form of that?

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

            Comment


            • #21
              Re: Canceling methodolgy for sets

              Dan,
              If you are trying to implement the QB model for canceling a new invoice then add referential integrity to the set and do a delete on the parent record of the form. Because this is what QB does when you cancel - you lose the whole invoice. QB prompts the user to save and if No is selected then the record(s) are removed. All your button needs to do is pass a Ctrl-D.

              But if you want to cancel changes to an already existing record then you will have to do something more involved - no way around that. The ESC key will cancel any changes that have not been saved - in the region in which it is used.

              Perhaps there is something else that should be addressed as to why your users make entries they must cancel?
              Last edited by MoGrace; 04-24-2008, 12:18 PM.
              Robin

              Discernment is not needed in things that differ, but in those things that appear to be the same. - Miles Sanford

              Comment


              • #22
                Re: Canceling methodolgy for sets

                Just so it is not misunderstood, I am not trying to be offensive with this post.

                I do not know the QB program or how it does things. I can understand what you are asking for in your request. QB don't make the millions of dollars that they do just by rolling code from STANDARD scripts. I am sure that they are writing a lot of very complicated code to do the things that they do to make things easier for the customer. Unfortunately, it is a fact of life with programming that if you want to make things easier for the user, it almost always equates into more work for the programmer. What you are asking for can be done in Alpha with a lot of coding. You would need to dig into the Xbasic and XDialog and get VERY familiar with each. eg) Roll your own dialog that will enter all data into variables, perform data checks as necessary along the way, save data when you want, clear child information upon saving the record and set the cursor to the starting object for the child data to continue.

                I must agree with the other posters here that the way that Alpha deals with a basic form with child tables is the very best way that it should be done. It caused me untold grief while I have been learning A5 (it is a never ending avocation) as I too wanted more polished looking apps. That is until I appreciated the fact that there is more power behind this beast than any single person will ever be able to fully grasp.

                My suggestion, whenever you hear yourself saying to yourself something like:

                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?
                Quickly slap yourself in the face and say something like:

                If I new all there was to know about A5, what would be the best way to achieve what I want so that I can give my users an easier to use app.
                Look up other possibilities in the docs and if you're not able to find an answer, come to the board and ask something like: "I have been creating my forms like this in the past and have found these limitations. This, however, is what I am trying to achieve. Is there a way that someone could point me in the direction of to accomplish my goal." Then I'll bet you'll see some pretty creative answers. Right now the way I am reading it, you are telling everybody that "I am doing it this way, this is the way I want to do it cause this is what I know, and I want it changed so that it works the way I want - why can't this be done!" The complexities of forms are fantastic but there needs to be logical rules behind them. As you can tell from the discussion here, most people believe the rules are correct for the vast majority.

                You have had some very good creative thinkers on this board chime in here to give you some suggestions. I think it is time to go back and look over them and weed out the advice they have given. In the end, it doesn't hurt them if you don't heed the advice but they might not be as ready to continue the thread!

                Comment


                • #23
                  Re: Canceling methodolgy for sets

                  "I am doing it this way, this is the way I want to do it cause this is what I know, and I want it changed so that it works the way I want - why can't this be done!"
                  I am sorry if this is the way I was coming across. Sometimes it's easy to write something and not realize how it may sound to someone else!

                  I am not trying to knocking Alpha's design, it is a very powerful program and I like a lot about it (this feature is not one of them, yet) :), and I was just using QB as an example. I was hoping I missed something when I read in the help file that sets are just like tables and then found out I can't cancel the same way. I was also hoping someone from Alpha would chime in and show what they had in mind for canceling changes to sets.

                  Perhaps there is something else that should be addressed as to why your users make entries they must cancel?
                  One example would be if a customer ordered several items and then called back to see about adding to or changing the order. The user could simply pull up the order, make the desired changes and give them a verbal answer and then cancel or save depending on the customers decision.

                  Anyway, back to the issue; looks like we have about 3 choices;

                  1) Use <tbl>.record_data_get() and....set(), simple, but with limits of one parent and one child, unless there is a way to repeat it for each child record.

                  2) Use variables on the form instead of fields attached to tables. Haven't worked with this type of form, so would need some help with this one.

                  3) Copy data to temporary tables, make edits in temporary tables and then write back to the primary tables. Would this be more secure? I guess the same as #2. If the user left the form open on their computer while editing and the electric blinked, changes would be lost, but the original record(s) would be left intact, right?

                  Am I missing any?
                  Any comments on these different (or others) approaches?

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

                  Comment


                  • #24
                    Re: Canceling methodolgy for sets

                    Dan,
                    First, I think that unless a user is extremely new to any type of database, or application for that matter, most would not expect to be able to cancel something after moving on to a completely different record...I mean, if this were the expectation where would you stop?? After two records are created...10 records??....or maybe a week later??? (being a bit obnoxious now! :) ). There has to be a limit really. But if your users want something like this that is a different story and am sure it could be coded via any of the 3 ways presented to you.

                    1) Use <tbl>.record_data_get() and....set(), simple, but with limits of one parent and one child, unless there is a way to repeat it for each child record.
                    This could be repeated by having different Blob variables being assigned whenever a record changed and then either an all-out cancel performed or with maybe xdialog a list of choices could be made for the user to cancel only certain ones....this procedure would be the most difficult I am thinking to incorporate.

                    2) Use variables on the form instead of fields attached to tables. Haven't worked with this type of form, so would need some help with this one.
                    This is similar to the prior method that uses a Blob variable except that your fields now become variables and as the table fields are not set to these variables until you decide to, if the user decides to cancel there is nothing to do---that is you simply do not set the actual table value to the variable that was changed. To do this with multiple child records.....am not sure if this can be done easily either (if at all). To do this you would have to have some sort of method to change the field variable names so that they would be different for each different record.

                    3) Copy data to temporary tables, make edits in temporary tables and then write back to the primary tables. Would this be more secure? I guess the same as #2. If the user left the form open on their computer while editing and the electric blinked, changes would be lost, but the original record(s) would be left intact, right?
                    This is most likely the route to take as it gives you the opportunity to cancel a multitude of changes made, but am thinking this would be an all or nothing proposition. It may be possible to tag each record that is changed and then present the user with a list of the records and cancelling only the ones wanted...I believe it is doable but not for the really inexperienced person--

                    More secure?? I'm not understanding this I guess...you can prevent a user from doing any or all of any of the above procedures.

                    And yes, original records are not touched until they are....so if nothing has been written back from the temporary table then the original record has not been changed. I guess this is what you asked...?

                    I guess now it is up to you to decide on which method you want to pursue. Then when you are to a point where you get lost, come back to the forum and post your problem (in a different thread I would think).
                    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


                    • #25
                      Re: Canceling methodolgy for sets

                      I'll try to stick to the QB theme here ;). Your app ought to follow standard accounting principles - eg. when you write a check and need to change it, you must void it and write another. The same principle should follow for any records that are printed as verification to a customer. Now there is nothing that says you have to do things this way, but some decisions ought to belong to management and not the data entry person. You do not want your users deciding which orders and invoices they will delete if those records have already been sent to your customer, because they provide them proof and give you some control over where the money goes. Which is the beauty and potential harm of a computer system.

                      With manual records all papers are accounted for and any missing ones would be suspect of potential foul play. It happened to me once with a girl in the office who had written herself some checks and forged the signature. Had she not removed the cancelled checks from the bank reconciliation, I would probably not have discovered what she had done.

                      Obviously there is more to consider than just the ease of use of your program.
                      Robin

                      Discernment is not needed in things that differ, but in those things that appear to be the same. - Miles Sanford

                      Comment


                      • #26
                        Re: Canceling methodolgy for sets

                        OK, I will do some experimenting, and see what I can figure out from here.

                        Thanks to all who contributed.

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

                        Comment

                        Working...
                        X