Re: Sub-Report
We obviously are not on the same wave length. I understand what you are saying in your example. That is not the points I am trying to make:
1.The way Alpha has worded what little help there is, does not explain the meaning of Include from parent. To someone who is very well versed in the design structure of A5 itself, it gets the job done. However, most A5 users are not in that category and it should be explained on their level. Add to those, someone like me who reads it for what it says which in this case, the same definition is used for all three and the definition states: Include records from parent when child exists or when no child is found. It simply states to always include all parents, whether a child is found or not.
2. My other point is this. Each sub-report has its own properties. However, when one sub-report is set to "MATCH", it affects all remaining sub reports and there is nothing to tell the user what will happen or why. It just does it and we are left with many, many hours of trying to figure out what is happening.
I disagree with the manner in which this works but then maybe the talented folks at alpha have a very good reason and then again, maybe it's just happenstance. In any event, there should either be an explanation or it should be corrected.
This is like may other property settings which have no value, i.e. the fields used in a report have a tab order property. Why? A user assumes that if there is an active property setting for any object, that property is valid for that particular object.
Granted, it takes time to clean up the "minor" issues but none the less, they must be cleaned up. Sooner or later, the minor issues become a big issue. In my occupation, a minor issue left unchecked can and does become a BIG issue and the case is lost. That's my mind set, that's how I look at things. It's the details which make it or break it.
"does not match means the opposite of the above"
Which one, None, Match or both?
Earlier, I called this a bug which to me, it is, simply because at the very least, if this is the way Alpha intends this to be, then, not only should there be an explanation in the Alpha Help, but certain properties in the remaining sub-reports should be disabled. On the other hand, if this is not the manner in which Alpha intends a sub-report to affect other sub-reports, then.....
I hope we are closer to the same wave length.
kenn
We obviously are not on the same wave length. I understand what you are saying in your example. That is not the points I am trying to make:
1.The way Alpha has worded what little help there is, does not explain the meaning of Include from parent. To someone who is very well versed in the design structure of A5 itself, it gets the job done. However, most A5 users are not in that category and it should be explained on their level. Add to those, someone like me who reads it for what it says which in this case, the same definition is used for all three and the definition states: Include records from parent when child exists or when no child is found. It simply states to always include all parents, whether a child is found or not.
2. My other point is this. Each sub-report has its own properties. However, when one sub-report is set to "MATCH", it affects all remaining sub reports and there is nothing to tell the user what will happen or why. It just does it and we are left with many, many hours of trying to figure out what is happening.
I disagree with the manner in which this works but then maybe the talented folks at alpha have a very good reason and then again, maybe it's just happenstance. In any event, there should either be an explanation or it should be corrected.
This is like may other property settings which have no value, i.e. the fields used in a report have a tab order property. Why? A user assumes that if there is an active property setting for any object, that property is valid for that particular object.
Granted, it takes time to clean up the "minor" issues but none the less, they must be cleaned up. Sooner or later, the minor issues become a big issue. In my occupation, a minor issue left unchecked can and does become a BIG issue and the case is lost. That's my mind set, that's how I look at things. It's the details which make it or break it.
As to the interpretation of those choices, it's pretty much what I describes:
None means, do not limit the parents table to either condition, i.e. all parent records are game.
match means if the child table has records to match the parent
does not match means the opposite of the above.
None means, do not limit the parents table to either condition, i.e. all parent records are game.
match means if the child table has records to match the parent
does not match means the opposite of the above.
Which one, None, Match or both?
Earlier, I called this a bug which to me, it is, simply because at the very least, if this is the way Alpha intends this to be, then, not only should there be an explanation in the Alpha Help, but certain properties in the remaining sub-reports should be disabled. On the other hand, if this is not the manner in which Alpha intends a sub-report to affect other sub-reports, then.....
I hope we are closer to the same wave length.
kenn
Comment