PDA

View Full Version : Bug Report Response Time


ABC123

askoog66
02-28-2012, 05:10 PM
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

Steve Wood
02-28-2012, 05:13 PM
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.

askoog66
02-28-2012, 05:25 PM
Thanks Steve,

How do you ask? Do you send another email to a5v11bugs@alphasoftware.com, 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.

Steve Wood
02-28-2012, 05:29 PM
Since they have no other means to check up on your report, that's the only option you have.

peteconway
02-29-2012, 05:59 AM
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.

Lance Gurd
02-29-2012, 10:14 AM
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.

askoog66
02-29-2012, 12:32 PM
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

csda1
02-29-2012, 01:49 PM
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 (http://csda1.com/csda_codeutility/CSDA_CodeUtility_Tips.html) as well as consider using my free (for non-commercial use) CSDA DiagInfo utility (http://www.csda1.com/csda_diaginfo/csda_diaginfo.html), which captures Diagnostic Info and allows emailing more detail about a problem than Alpha bug reports do.

waldhorn
03-01-2012, 01:40 PM
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 (http://stackoverflow.com/questions/2430380/is-there-a-postgresql-equivalent-of-sql-server-profiler) in PostgreSQL?

JerryBrightbill
03-01-2012, 03:08 PM
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 (http://downloads.alphasoftware.com/A5V11Download/prereleasenotes.html) or HERE (http://downloads.alphasoftware.com/A5V11Download/releasenotes.html) 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.

DaveM
03-01-2012, 04:40 PM
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.

peteconway
03-01-2012, 05:19 PM
We do not regularly monitor the forum. - says it all.

JerryBrightbill
03-01-2012, 05:21 PM
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.

madtowng
03-01-2012, 06:26 PM
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.

Clipper87
03-01-2012, 06:53 PM
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) (http://www.geminiplatform.com/) 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!

drgarytraub
03-01-2012, 08:22 PM
Just to flesh out the other side of this picture, I have been using alpha for years, and have made several bug reports, two of them quite recently. In both cases, the response was the same day, actually within hours! :grin:

Steve Wood
03-01-2012, 08:58 PM
Alpha cannot make the whole bug report public or even sharable amongst us. I and others commonly send proprietary information to Alpha with the understanding that they will treat it as private.

But here is a possible partial solution if Alpha would go along with it: it would be very easy to CC or BCC the bug report to a special email address that took specific parts of the report and posted it to a database, tied to a grid for review. It can include updatable Status and a Notes section if we understand that we are responsible to update this information. By "partial" I mean it captured ONLY what the reporter placed using special tags such as:

TITLE: yada yada
SUMMARY: yada yada

This would be voluntary, not involve Alpha (unless they wanted to) and with the disclaimer that the reporter would not include any proprietary information in the summary.

Clipper87
03-02-2012, 01:43 AM
Just to flesh out the other side of this picture, I have been using alpha for years, and have made several bug reports, two of them quite recently. In both cases, the response was the same day, actually within hours! :grin:

Gary,

I second that: every single bug report I filed was solved or it was extensively explained to me that I was in error & why so it was a great learning experience. Even at times where I persisted there was a bug and Alpha believed there was no bug they did not send me walking but continued to listen. And yes in some cases it appeared to be a bug related to the fact that I (like a growing number of others) use different regional settings, in some other case it was my limited thinking that was in error but we always got out. Many of my suggestions even made in into the product and I take great pride in that.

I have not seen this with any other vendor.

Lance Gurd
03-02-2012, 09:32 AM
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) (http://www.geminiplatform.com/) 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!

You are right Frank, and Jerry has been very good at pointing me in the right direction when my bugs are my fault and patient and understanding when they are actually a bug.

But I am not a developer for other people most of the time. I develop for my own companies needs, therefore I build grids/dialogs to be used in my own real world on my live data. When something goes wrong I am usually up against deadlines to get a quote back to a customer, or final account a finished job etc.

Downloaded the latest full build so that I could install the latest feature packs, I like the look of a couple of them. Was going to play with them over the weekend, but have had to go back to previous patch again because the bug I found in build 2460 - 3877 is still there.

Therefore until someone else spots the problem of subsequent ajax callbacks on a grid throw I a XHTTPRequest Error 500 Internal server error, reports it and it is fixed I cannot play with the latest feature packs.

Pat Bremkamp
03-02-2012, 11:02 AM
I think Alpha is at its best making the hard things easy. The things we can accomplish with very little effort and even less knowlege is incredible. And, I know from trying to do it, that making the hard things easy is the most difficult thing you can do. So, I've evolved a "bug" policy that works for me.

I get paid to provide working software to my clients, so I consider every bug, (mine or Alpha's) to be my bug. If something doesn't work, I just find another way (or in extreme cases tell the client I can't do it). To that extent, I'm in the "let someone else report it" camp. Meantime, if the screwdriver doesn't work, just pound it in with a hammer.

There are two exceptions to that. One is when something that used to work now doesn't work (which still may be my problem for finding a tricky way to use something that is undocumented and later is changed). The second is when I've verified the same problem with several of my clients. Then, I'll report that I've found it and what I'm doing to get around it. Kind of an FYI report.
Sometimes this kind of report has led to Alpha providing new capability or explaning how to use the existing tools to accomplish something new.

For me, the suggestions above about public bug databases would be no help. I barely have time to read and help out on this board, much less going through a bunch of someone else's bug reports. My job is to provide solutions to my clients, not to try to get Alpha to do it for me.

So, here's what I suggest might improve the bug system. Add a priority system to the bugs that we would fill out. Categories could be:

It'd be great if it did this (IdeaScale seems to have fizzled out)
Hey, I noticed this, but it's no big deal
I can't get this to work, but then I don't know what I'm doing
My hair is on fire and the world is crashing down around me

MarionT
03-02-2012, 01:24 PM
I've had very satisfying responses to my calls for help, whether they turned out to be bugs, potholes or my error.


For me, the suggestions above about public bug databases would be no help. I barely have time to read and help out on this board, much less going through a bunch of someone else's bug reports.

I'm in this camp...

thing is, we're all at such different levels of experience and have such different needs. There is no one-size-fits-all solution.

I barely know the vocabulary, so search an existing bug log is just as hard as searching the message board

when I decided to pursue A5 since I can't afford to pay my computer guy to write a customized UI and I need a UI sooner than I would be able to learn how to do the coding, my guy told me to keep in mind that I should bend to what A5 does well, not try to bend A5 to do what I have in mind. And that there are usually multiple ways to do things.


isn't a simple option for folks to post a message to the forum when they send an email to A5, with Help Ticket or some such thing in the title? Simply repeating what they've reported to A5? And others can post whether or not they are running into similiar behavior, and the original poster can update the thread when/if they hear back from a5?

csda1
03-02-2012, 01:29 PM
I created my free CSDA DiagInfo Utility (http://www.csda1.com/csda_diaginfo/csda_diaginfo.html) for precisely the purpose of preparing a bug report and classifying it.

It gathers diagnostic information about the computer hardware, Operating System and Alpha Five environments for the purposes of reporting bugs and getting support from CSDA.

The free version has buttons on it (see attached photos) to either Email CSDA or Email Alpha. Upon doing so, it prompts for a "Support Request Classification" (see attached photos) about the nature of the problem, and adds that classification to the email. When it creates an email to Alpha Software, it uses the same email address and subject as Alpha Five's bug report.

31150

31151

Ted Giles
03-02-2012, 01:41 PM
I've read the posts and there are some good comments.
However, from a Testing perspective, I recently had a big and badly designed application using a mixture of technologies to test. My role was to record and manage the bug fixes and the help desk workarounds.
I had 25 people on the team, of which, 8 were testers.
The bug list was enormous and categorising them was not the answer. Every bug seemed to be "urgent", so it was down to me to find workarounds where possible first, and to decide what was critical from a business perspective.
As far as reporting the bugs, this was done based on detailed Test Scripts and expected responses with calculations so that the bug was repeatable or the differences explained (although some were randomly generated). I really sympathise with Alpha and the problems identifying a true bug, which I would define as "It will/can do this", and it doesn't. Given the complexity of Alpha it should be a "given" that a few Forum members give it a whirl before submitting a Bug, and when it is submitted, sample data and instructions should go along with it so that it can be replicated.
Having had the luxury of finding few bugs, and also the benefit of the whole lifecycle approach to system development, I'd be happy to put my effort into a detailed submission as has been suggested if it would help.

tekri
03-05-2012, 03:36 AM
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
I have found same issue with MySQL database, can you please let me know, when fix will be available?
Thanks

StevenMcLean
03-07-2012, 05:55 PM
I think a little communication would go a long way. With most other companies when you submit a bug or support incident, you recieve comfirmation (usually by email) opening you case and giving you a case or ticket number. Once the issue / incident is concluded you get further communication with the resolution. With this approach you know what is happening and are not being ignored.