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

Bug Report Response Time

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

    Bug Report Response Time

    I sent in a v11 Web App bug report on 2/26/2011 with a screencast video link.

    What can I expect back as a response and in what time frame? Do they say if it was in fact a bug? Do they give an estimated fix or solution?

    I haven't heard anything from them yet, rechecked my sent box to confirm it was actually sent. Just kind of wondering.

    Andy

    #2
    Re: Bug Report Response Time

    They have no official or automated system for response. It depends on if they took the bug under consideration, are reviewing it, or not. E.g., you won't know unless you ask again.
    Steve Wood
    See my profile on IADN

    Comment


      #3
      Re: Bug Report Response Time

      Thanks Steve,

      How do you ask? Do you send another email to [email protected], telephone, or another route?

      Mainly just trying to decide if I wait out a bug fix, or do a workaround and skin the cat another way.

      Comment


        #4
        Re: Bug Report Response Time

        Since they have no other means to check up on your report, that's the only option you have.
        Steve Wood
        See my profile on IADN

        Comment


          #5
          Re: Bug Report Response Time

          Skin that cat.. - your request may or may not have been a bug, I don't know - but you are a customer and you should at least get a response from a person from customer services who cares about you because you are a customer in need, from a person who's listening to your needs at a minimum. Re Steve's quote
          Since they have no other means to check up on your report, that's the only option you have.
          - There are always other options.. Post your video here and I will see if I can help.
          Insanity: doing the same thing over and over again and expecting different results.
          Albert Einstein, (attributed)
          US (German-born) physicist (1879 - 1955)

          Comment


            #6
            Re: Bug Report Response Time

            Through recent experiences I don't report bugs anymore, I just go back to a stable(ish) build and wait for someone else to sort it out.

            I have had enough of trying to provide all the back up data and documentation to report a bug, only to be told it must be something I am doing wrong. Then a few releases later there is a bug fix for my problem.

            It took me about an hour to find a bug in build 2460 - 3877 (27 Feb), it would have taken me a couple more to provide the bug report. Far simpler to switch back to the previously released patch and not have the problem.

            Comment


              #7
              Re: Bug Report Response Time

              I didn't mean to be throwing any daggers, I was just wondering about the procedures of what would happen now. I also noticed that my copy is a trial version. Not sure if they ignore reports from trial versions. I have actually bought a copy, just haven't installed it yet because not sure how I am going to setup my server yet. Didn't want to install/activate Alpha and then have to move it and go through licensing hassles.

              The following is the copy of the email I sent in as a bug report.

              E-mail Body:
              Alpha Five Version (Trial): 11
              Compiler: Microsoft C Compiler version 1600
              Build: 2448 (THIS IS A BETA RELEASE OF Alpha Five)
              Addins: 3876 (THIS IS A BETA RELEASE OF ADDINS)

              Operating System: Microsoft Windows XP Professional Service Pack 3

              Bug Description:

              Working with Steve Workings and he suggested I send in this report.

              v11 Web App is connected to PostgreSQL v9.1 backend via AlphaDAO

              Dialog with 4 repeating sections is connected to child tables with two primary key columns. The database is multitenancy and therefore always requires at least two columns in a table to uniquely identify a row. Have used the columns cid and empid to link child to parent tables and is not linking in a unique manner. i.e. Information regarding telephone, addresses, etc. for one employee are showing up in another employee's dialog. Have experimented and found that one column primary key will work, but not two column primary keys.

              Steve Working suggests that I use autoid primary key column in order to enable this functionality. Seems like I shouldn't have to do this if repeating sections can in fact use multiple column keys.

              I have tried with both current production updates as well as the beta prerelease update with the same effect.

              http://www.screencast.com/t/YiZaLYm3DC

              Comment


                #8
                Re: Bug Report Response Time

                Hi Andrew.

                If would be nice if Alpha Software had a bug reporting system that recorded the details, associated files (unfortunately, extremely large tables) and allowed for someone to determine status and disposition of the problem. But alas, they do not (or at least as far as I know). I don't believe they care whether it is a trial version or not.

                I generally find another way that avoids the issue, however I make utilities that work across many versions of A5 (typically version 6 and up), but that's not relevant for all. But if you stick to the well used (and hence well tested) functions, methods and the like, you will generally be better off.

                If you can, always encapsulate the "buggy" or "Tricky" code that you must use into a function so that it is easier to keep up with changes across versions.

                I recommend you read portions of my tips page as well as consider using my free (for non-commercial use) CSDA DiagInfo utility, which captures Diagnostic Info and allows emailing more detail about a problem than Alpha bug reports do.
                Regards,

                Ira J. Perlow
                Computer Systems Design


                CSDA A5 Products
                New - Free CSDA DiagInfo - v1.39, 30 Apr 2013
                CSDA Barcode Functions

                CSDA Code Utility
                CSDA Screen Capture


                Comment


                  #9
                  Re: Bug Report Response Time

                  Originally posted by askoog66 View Post
                  Have experimented and found that one column primary key will work, but not two column primary keys.
                  While your post concerns A5 bug tracking, I'm wondering if monitoring PostregSQL for SQL activity from A5 might help you ferret out the issue. Have you tried querying up pg_stat_activity or setting up logging via log_statement in PostgreSQL?

                  Comment


                    #10
                    Re: Bug Report Response Time

                    There seem to be many misconceptions about bug reports and how they are handled.

                    First, all bugs reports and inquiries about bug reports should be sent using the bug reporting option from the Alpha Five help menu. If a bug report is sent to another email address, it may not get forwarded to the correct people in a timely fashion. From time to time, we see reports on the forum about suggested bugs. A couple issues that were hotly discussed on the forum were never reported as bugs by anyone. If we don�t know about the problem or can�t duplicate it, a fix is very unlikely. We do not regularly monitor the forum.

                    In most cases, we try to evaluate and respond to a bug report within 1 to 2 business days, often on the same day it is received. However, some reports that require complex evaluation may take longer. If you don't hear a reply in about a week, you should report the issue again, referencing the original reports.

                    We now supply daily pre-release builds that have all of the latest fixes. If you have a problem or sent in a bug report, please check the notes HERE or HERE to see if the issue has been fixed. Not all bug fixes are listed as some apply to very limited situations or were minor in nature. Just because a fix isn�t listed does not mean it hasn�t been addressed. These pre-release builds are not usually fully tested before being listed and may have new or unexpected issues or only partial fixes.

                    If you receive a reply or request for more information, please use "reply all" in any return email so all involved parties are notified. Also, try to supply the information requested. If you are having a problem and are not running the latest production release build, update first before reporting a bug. It may have already been fixed. If the problem is web server related, may sure the development build and web server builds are the same.

                    A very high percentage of bug reports were receive are not bugs but user errors or misunderstandings about how features work. In most cases, those reports still require considerable time to analyze and verify the actual cause. We often receive minimal information and have to make requests for additional information, further complicating and delaying the process. In fact, most bug reports do not follow the guidelines in the bug reporting process and requests for clarification and information are very common, and time consuming. If the problem is a user error, we may or may not suggest a direction to find a solution.

                    When we do find a bug that we can identify in Alpha Five, we try to fix it as quickly as possible. In most cases, that is within a day or so. However, the severity of the problem or the availability of a simple workaround may impact the response time. In a very few rare cases, a fix may take considerable rework.

                    Based on current reports, any public bug reporting process would be overrun with erroneous reports that would be misleading. It could also prove rather embarrassing to some users when the nature of certain errors are revealed. We prefer to keep such revelations private and often reply privately with suggested relevant documentation or additional sources of help.

                    Comment


                      #11
                      Re: Bug Report Response Time

                      Thanks Jerry,

                      I have submitted a few bug reports over the years. I learned earley on to make sure it was a bug and try it with others here on the forum before reporting it as a bug. More often than not, the issue was here with me, not at alpha. The ones that were for sure bugs were addressed right away and a fix was supplied.

                      Thank goodness that Alpha is not like microsoft and others. Borland may have been the worse of all.
                      Dave Mason
                      [email protected]
                      Skype is dave.mason46

                      Comment


                        #12
                        Re: Bug Report Response Time

                        We do not regularly monitor the forum.
                        - says it all.
                        Insanity: doing the same thing over and over again and expecting different results.
                        Albert Einstein, (attributed)
                        US (German-born) physicist (1879 - 1955)

                        Comment


                          #13
                          Re: Bug Report Response Time

                          Originally posted by askoog66 View Post
                          I sent in a v11 Web App bug report on 2/26/2011 with a screencast video link.

                          What can I expect back as a response and in what time frame? Do they say if it was in fact a bug? Do they give an estimated fix or solution?

                          I haven't heard anything from them yet, rechecked my sent box to confirm it was actually sent. Just kind of wondering.

                          Andy
                          Andy

                          We have responded privately to your bug report. While a video is sometimes useful, without a test case we can actually run and test it is often impossible to troubleshoot behaviors. Your particular issue is tied to the data source being used and the nature of the data. In those instances, we need a copy of the actual database (or access to the database) with sample data and any component that demonstrates the problem. This is explained in the instructions for sending a bug report from the link on the Alpha Five help menu.

                          We know from past experience that the effort to create a test case from a vidoe is likely futile as we can not exactly duplicate your system.

                          Comment


                            #14
                            Re: Bug Report Response Time

                            During my time using Alpha4 and/or Alpha5, I have submitted less than a handful of problems as bugs.
                            These problems would usually come up after updating to a newer (supported) version of Alpha software.
                            I rely on documentation and feedback to help determine if I believe I have indeed run into a bug.

                            I reported a bug a couple years ago. Before I reported the issue, I spent hours trying to decipher
                            the less than helpful response from alpha5 software. I then took my question to Steve Wood,
                            Steve Workings, and Jay Talbott at the Las Vegas Alpha University. After they were unable to
                            determine what the issue was, I submitted it as a bug.

                            We all know that the forum is monitored, at least once a week, by several of the key players at Alpha software.
                            I completely understand that people often take the fastest way to solve a problem. The response I received was
                            basically presented as RTM, or pay for support to solve the problem (once I got past the bitter part, there was an
                            actual solution in the response).
                            I will always resort to reading the manual before trying to contact Alpha software with a bug report, but if the
                            manual is incomplete, or the feedback is misleading, I believe Alpha Software should supply the fix without berating
                            the developer.
                            Gregg
                            https://paiza.io is a great site to test and share sql code

                            Comment


                              #15
                              Re: Bug Report Response Time

                              Originally posted by Lance Gurd View Post
                              Through recent experiences I don't report bugs anymore, I just go back to a stable(ish) build and wait for someone else to sort it out.

                              I have had enough of trying to provide all the back up data and documentation to report a bug, only to be told it must be something I am doing wrong. Then a few releases later there is a bug fix for my problem.

                              It took me about an hour to find a bug in build 2460 - 3877 (27 Feb), it would have taken me a couple more to provide the bug report. Far simpler to switch back to the previously released patch and not have the problem.
                              Lance,

                              While I agree that creating a bug report & following it up is very time consuming I regret -no disrespect intended- you deal with (potential) bugs in the way you describe. On the other hand you are plain honest and I appreciate that.

                              That said I think Alpha cannot exist without it's user base and vice versa (!)

                              From Alpha's own developers point of view I think it is impossible to test for everything we as developers encounter with a complex & extensive tool like A5. Chances are errors you encounter will never even be encountered by other developers or maybe much later. So where does that leave you (and others) ?

                              I personally found quite a few bugs during the beta period that appeared not to be v11 bugs but v10 bugs. I think they should have been reported as I'm sure many others did encounter most of them but just did not care to report it because they found some workaround or just did not care. Again that's too bad if you ask me.

                              I do agree with the fact as pointed out by others in this thread that some kind of bug reporting & follow up tool (like the Gemini platform) would be very helpful: it does not make sens for you & me to spend time reporting the same issue or even wondering if some issue is a bug.

                              I hope you'll give it a thought!
                              Frank

                              Tell me and I'll forget; show me and I may remember; involve me and I'll understand

                              Comment

                              Working...
                              X