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

What does "Show update commands" do?

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

    What does "Show update commands" do?

    In the grid builder "Update Settings" pane, there is a "Debugging" section with "Show update commands." Now, silly me, I thought that if I enabled this, then maybe I'd see the SQL on my browser when I submit the form, but nooooo...

    Just where am I supposed to go to see the "update commands" that are supposedly being "show[n]?"

    BTW, if this is in the Help file, I couldn't find it. If you know where it is, please let me know. All the help references stop short of explaining how/where one gets to see the update commands.

    Thanks.

    #2
    If you check show update commands, and submit the form, it will show either the xbasic (or I suspect, the SQL, depending on the database you are using), such as below. It appears just above the component in the A5W page, in the browser. Its in the Help under "Setting Update Properties", but its skimpy. Its for debugging.

    1|Table alias: tr_assets
    tp_1.enter_begin()
    tp_1.Account_no = ""
    tp_1.Account_type = ""
    tp_1.Amount = 0
    tp_1.Institution_address = ""
    tp_1.Institution_city_st_zip = ""
    tp_1.Institution_name = "test"
    tp_1.Ownership = ""
    tp_1.Job_id = "020106132600490659"
    tp_1.enter_end(.T.)
    Steve Wood
    See my profile on IADN

    Comment


      #3
      Originally posted by Steve Wood
      If you check show update commands, and submit the form, it will show either the xbasic (or I suspect, the SQL, depending on the database you are using), such as below. It appears just above the component in the A5W page, in the browser. Its in the Help under "Setting Update Properties", but its skimpy. Its for debugging.

      1|Table alias: tr_assets
      tp_1.enter_begin()
      tp_1.Account_no = ""
      tp_1.Account_type = ""
      tp_1.Amount = 0
      tp_1.Institution_address = ""
      tp_1.Institution_city_st_zip = ""
      tp_1.Institution_name = "test"
      tp_1.Ownership = ""
      tp_1.Job_id = "020106132600490659"
      tp_1.enter_end(.T.)
      Thanks for the reply, Steve. I had guessed that that's how it would work, but it doesn't when one chooses "0" in the "Rows of data" (Grid Properties sheet, Layout Options, Rows of data)!! If I flip between "0" and, say, "10", the SQL command disappears and reappears.

      This seems to be yet another anomaly of that setting's behavior (see also my thread, here.)

      I'm still waiting for an AlphaSoftware representative to reply to that thread, but, if you've got the time (and largeness of heart :D) maybe you could try it for me? I'd like to see another person verify the (mis)behavior.

      Comment


        #4
        Please help me on this one.

        Comment


          #5
          Are you saying that the debug output appears in one case and does not appear in another, and the variable is the number of rows in the grid?

          Comment


            #6
            Sorry, I must've missed it when you posted the reply back in February

            Yes, that's one thing I'm saying. There are two problems, both tied to the setting of a Grid Builder's Grid/Properties/Layout Options/Rows of data. Here they are:

            1. When set to zero, the SQL debug is not generated on the page. This option is under Grid/Update Settings/Debugging/Show update commands
            2. When set to zero, SQL commands themselves are not executed! See also the post above with the URL pointing to http://msgboard.alphasoftware.com/al...ad.php?t=59433.

            So, when I set it to 0, no database updates are applied when the user presses SUBMIT. The only "workaround," if one really wants to see all the rows possible, is to set Rows of data to some high number, like 999. The fatal downside to this approach is that the form takes "months" for the WAS to generate.

            On the other hand, one can theoretically live with something more reasonable like, say, 10. The problem here is that, as the user goes through (say) 5 pages of 10 rows, they have to press SUBMIT for each and every page on which they've made a change. That is, SUBMIT (arguably correctly) only affects the rows on the given page of ten. Not a good "look 'n' feel" deal for the user :(

            Could you please help? I've got to believe that this is a BUG and should be addressed with a patch or something. It's holding me back from finishing up my implementation.

            Thanks.
            Last edited by pruel; 04-27-2006, 02:11 PM.

            Comment


              #7
              It is very hard to see why this would be a show stopping issue.

              Setting the row count to 0 (which means 'show all of the rows') is really designed to be used for readonly grids.

              In the case of an updateable grid, if you set the row count to 0 and there are a lot of rows, then the page becomes very slow becuase of the large amount of data that a5 has to compute and then store in a hidden field in the grid. (the data in the hidden field is used to implement optimistic record locking - i.e. prevent two users from overwriting each other users changes).

              If you want to display a large number of rows and still give the user the option of doing updates, you should define a grid with an updateable detail view.

              when you have an updateable grid, you must apply updates to the page before you navigate to the next page. if you navigate to the next page without doing a submit, the updates are lost. You may not think that this is a good 'look and feel' for the user, but it is typical of all web applications.

              Comment


                #8
                Originally posted by Selwyn Rabins
                It is very hard to see why this would be a show stopping issue.

                Setting the row count to 0 (which means 'show all of the rows') is really designed to be used for readonly grids.

                In the case of an updateable grid, if you set the row count to 0 and there are a lot of rows, then the page becomes very slow becuase of the large amount of data that a5 has to compute and then store in a hidden field in the grid. (the data in the hidden field is used to implement optimistic record locking - i.e. prevent two users from overwriting each other users changes).

                If you want to display a large number of rows and still give the user the option of doing updates, you should define a grid with an updateable detail view.

                when you have an updateable grid, you must apply updates to the page before you navigate to the next page. if you navigate to the next page without doing a submit, the updates are lost. You may not think that this is a good 'look and feel' for the user, but it is typical of all web applications.
                I'm sorry, but once again I seem to have missed the key caveat in the user's manual that says I can't or shouldn't do what I'm trying to do. Just how was I supposed to know that using "0" is "really ... for readonly grids?" If that is truly the case, then why doesn't the option disappear if I make the grid editable?

                Regardless, I would have thought that "0" was meant to be a convenience for the designer who might not know a priori what the optimal number of lines per page should be. In my particular case, the number of rows displayed is likely to be very small, but choosing the "right" value is kinda like choosing a "polling" interval -- Murphy's Law will guarantee that I choose the wrong value every time. If I choose something small (say 10) so that the component is both saved quickly in the developer's UI and displayed quickly by the WAS on a browser, then - on the odd chance that the number of rows exceeds 10 - I'm back to the bad "design" of multiple pages, each requiring SUBMIT if a change is made*.

                The idea of using a detail would seem like a possibility, but I'm a) unfamiliar with them, and b) reluctant to change the screen designs already approved by the business. How do they appear to the user? Do they pop-up? If so, then this is not a good idea because the users here have pop-ups blocked. This is pretty typical in corporations in which I've worked. If they don't (or can be prevented from) pop-ups, then it would have to be a new page, with the concomitant browser back arrow, etc. to continue on. I'd be interested to hear back on this, but remember caveat b).

                Please forgive the irritation in the tone of my response, but I have run across a number of little glitches in A5 and, every time I do:
                • I'm either promised that they will be fixed in some future release
                • I'm told that I'm misusing the product, or
                • I'm basically told to "get over it."

                This time it's a combination of 2 and 3.

                I believe this is a legitimate concern - no - it's a bug and it should be fixed. Either I should not be allowed to use this feature in some component types, or I should. But the fact that it doesn't work as advertised should not be a fault on my part; and let's not forget that it fails to update the table(s).

                * By the way, this doesn't really work naturally for the user, either. If you go to page 4 of 7, make a change, and press SUBMIT, when the page is redisplayed, the user is put back on page 1. Of course I understand why it was implemented that way, but the user bellyaches about having to now go to page 5 to see if there any items there needing changes, SUBMIT, back to page 1, go to page 6, etc. It's really not a good user experience.

                Comment


                  #9
                  Paul,

                  If you believe you have found a bug, please send a bug report to [email protected] (or just go to the help menu and select "Send a bug report"). Make sure to include any necessary files along with a detailed description of exactly how to reproduce the problem. If possible, please try to send the smallest reproduceable case rather than an entire application.

                  Aaron
                  Aaron Brown
                  Alpha Software Development Team

                  Comment


                    #10
                    This is another great example of a developer spending unnecessary time trying to debug a WAS application with little or no tools.

                    If Alpha would spend a few minutes and add some real debugging tools so the developers could see what is happening in WAS it would save the developer hours if not weeks of development time.

                    In fact it is so bad that the time saved using A5 for a web application is lost in the hours and hours of debugging an application blind.

                    Below is my previous thread from months ago that Alpha doesn't even find the time to respond.
                    http://msgboard.alphasoftware.com/al...ad.php?t=57606

                    If you read preivous items in this thread, Please forgive the irritation in my tone also. Its combination 2 and 3 for me as well.

                    Comment


                      #11
                      Originally posted by ab042
                      If Alpha would spend a few minutes and add some real debugging tools so the developers could see what is happening in WAS it would save the developer hours if not weeks of development time.
                      We are working on it, but "minutes" is hardly an accurate description. "Months" is more reasonable. It is not a trivial project.

                      Below is my previous thread from months ago that Alpha doesn't even find the time to respond.
                      http://msgboard.alphasoftware.com/al...ad.php?t=57606
                      There are several responses from Alpha Software employees in that thread. However, this message board is user supported and we do not read every thread. If you require an Alpha response, the only way you can ensure that we see your message is to email us directly.
                      Aaron Brown
                      Alpha Software Development Team

                      Comment


                        #12
                        THANK YOU so much for at least responding and letting us know you are working on debug features. A good WAS Debugger isn't a feature that would be nice. Its a feature that is desperately needed to allow A5 to compete as a development product.

                        We are working on it, but "minutes" is hardly an accurate description. "Months" is more reasonable. It is not a trivial project.
                        I agree months is reasonsable and its been months since you or anyone at Alpha has taken two minutes out of your vaiable day to even respond to any of my kiss up messages over the last 5 months concerning the debug issue.

                        However, this message board is user supported and we do not read every thread
                        You and everyone on this board knows Alpha employee's read and respond on this board all the time, you can blow that smoke up someone else.

                        Now if you said you selectively respond, that would be a true statement.

                        Again, I really do thank you for the response and I hope you do release some kind of real WAS debug feature soon.

                        Comment


                          #13
                          Originally posted by ab042
                          You and everyone on this board knows Alpha employee's read and respond on this board all the time, you can blow that smoke up someone else.
                          Yes, we do read and respond to the board frequently. We do not read every message on the board, however.
                          Aaron Brown
                          Alpha Software Development Team

                          Comment


                            #14
                            I don't know about others, but I would not respond at all to someone that told me to "blow smoke" (a statement that normally has the phrase "your butt" in it). On debug, you'd have to take a vote, but I wouldn't describe it as desperately needed.
                            Steve Wood
                            See my profile on IADN

                            Comment

                            Working...
                            X