MS Access Forum / Reports / Printing / March 2008
Null Is Null
|
|
Thread rating:  |
jlute@marzetti.com - 10 Mar 2008 14:03 GMT I've got a text box in a report that's not returning properly. Here's its Control Source: =[Reports]![rptFGPackConfigsPKWeights]![srptFGPKConfigsSUPK_totalwt]! [SumWtg]+IIf(IsNull([Reports]![rptFGPackConfigsPKWeights]! [srptFGPKConfigsTPK_totalwt]![SumWtg]),Null,"")
This returns #Error. It's definitely my IIf statement as it returns properly when removed however there are times when [srptFGPKConfigsTPK_totalwt].[SumWtg] will be null. In fact, this subreport will not appear if no records exist. I suspect that this is the problem.
How can I write this Control Source to more properly address this?
As always, thanks for you help!
Allen Browne - 10 Mar 2008 14:32 GMT See: Avoid #Error in form/report with no records at: http://allenbrowne.com/RecordCountError.html
The core ideas are: - use the Report property to refer to the report in the subreport control - test the HasData property of the subreport.
You will end up with something like this: =IIf([srptFGPKConfigsSUPK_totalwt].[Report].[HasData], [srptFGPKConfigsSUPK_totalwt].[Report]![SumWtg], Null)
I did not follow the bit about trying to concatenate a null or zero-length string onto the end of the number.
 Signature Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org.
> I've got a text box in a report that's not returning properly. Here's > its Control Source: [quoted text clipped - 11 lines] > > As always, thanks for you help! jlute@marzetti.com - 10 Mar 2008 15:40 GMT Thanks for the response, Allen! (and Al and Duane, too!)
Since you and Duane touched on the "+" part of the string I thought I'd better explain. I'm trying to add the values of [srptFGPKConfigsSUPK_totalwt]![SumWtg] and [srptFGPKConfigsTPK_totalwt]![SumWtg]. There will be times when there won't be "TPK" records so I'm trying to arrive at an expression that will add the two [SumWtg} fields when they have values and when there isn't one in "TPK".
Hope that clarifies.
Considering that I tried this but it's returning a comma error:
=[Reports]![rptFGPackConfigsPKWeights]![srptFGPKConfigsSUPK_totalwt]! [SumWtg]+IIf([Reports]![rptFGPackConfigsPKWeights]![HasData], [srptFGPKConfigsTPK_totalwt]![SumWtg]),Null)
I didn't want to tinker too much more as this may be entirely off- track...?
> See: > Avoid #Error in form/report with no records [quoted text clipped - 38 lines] > > - Show quoted text - Allen Browne - 10 Mar 2008 16:11 GMT I don't really know if this is what you intend or not:
=IIf([srptFGPKConfigsSUPK_totalwt].[Report].[HasData], Nz([srptFGPKConfigsSUPK_totalwt].[Report]![SumWtg],0) +Nz([srptFGPKConfigsSUPK_totalwt].[Report]![SumWtg],0),0)
 Signature Allen Browne - Microsoft MVP. Perth, Western Australia Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org.
Thanks for the response, Allen! (and Al and Duane, too!)
Since you and Duane touched on the "+" part of the string I thought I'd better explain. I'm trying to add the values of [srptFGPKConfigsSUPK_totalwt]![SumWtg] and [srptFGPKConfigsTPK_totalwt]![SumWtg]. There will be times when there won't be "TPK" records so I'm trying to arrive at an expression that will add the two [SumWtg} fields when they have values and when there isn't one in "TPK".
Hope that clarifies.
Considering that I tried this but it's returning a comma error:
=[Reports]![rptFGPackConfigsPKWeights]![srptFGPKConfigsSUPK_totalwt]! [SumWtg]+IIf([Reports]![rptFGPackConfigsPKWeights]![HasData], [srptFGPKConfigsTPK_totalwt]![SumWtg]),Null)
I didn't want to tinker too much more as this may be entirely off- track...?
On Mar 10, 9:32 am, "Allen Browne" <AllenBro...@SeeSig.Invalid> wrote:
> See: > Avoid #Error in form/report with no records [quoted text clipped - 33 lines] > > - Show quoted text - jlute@marzetti.com - 10 Mar 2008 17:13 GMT Thanks, Allen. That's actually adding [srptFGPKConfigsSUPK_totalwt]. [SumWtg] with itself.
Maybe I need to phrase it this way: I'm trying to add [srptFGPKConfigsSUPK_totalwt].[SumWtg] and [srptFGPKConfigsTPK_totalwt].[SumWtg] IF [srptFGPKConfigsTPK_totalwt]. [SumWtg] has data. If it has no data then simply return [srptFGPKConfigsSUPK_totalwt].[SumWtg]
Sorry for all the confusion!
On Mar 10, 11:11 am, "Allen Browne" <AllenBro...@SeeSig.Invalid> wrote:
> I don't really know if this is what you intend or not: > [quoted text clipped - 72 lines] > > - Show quoted text - BruceM - 10 Mar 2008 16:44 GMT Allen wrote: "use the Report property to refer to the report in the subreport control" Suggested syntax followed.
The subreport is in a "container" on the main report. That container is known as the subreport control. It is a different thing than the actual subreport. In order to refer to the subreport itself rather than its container, you need to use the Report property of the subreport control. That is why Allen and Duane showed the syntax: [srptFGPKConfigsSUPK_totalwt].Report Once Access knows you are talking about the subreport, you can refer to the subreport's HasData property: [srptFGPKConfigsSUPK_totalwt].Report.HasData
Note that properties are preceded by a dot (.) rather than a bang (!). The bang indicates members of a collection. The syntax: =[Reports]![rptFGPackConfigsPKWeights] is because rptFGPackConfigsPKWeights is a member of the Reports collection. By contrast, HasData is a property of the subreport. In the expression in which you said you got a comma error, you treated HasData as a member of a collection, which it is not unless you have a field named HasData, which you should not do because HasData is a reserved word. In your example, because of the bang (!) Access was looking for a field or control named HasData.
Note also that on the report you don't need the full syntax to refer to the report. Access assumes you mean the current report. That is why the syntax Allen and Duane suggested leaves out that part.
From what I can tell you are trying to add SumWtg from srptFGPKConfigsSUPK_totalwt] and srptFGPKConfigsTPK_totalwt. If the second (TPK) field has no value, just use the value of SUPK. If so, maybe something like: =IIf([srptFGPKConfigsTPK_totalwt].Report.HasData, [srptFGPKConfigsSUPK_totalwt].Report![SumWtg] + [srptFGPKConfigsTPK_totalwt].Report![SumWtg], [srptFGPKConfigsSUPK_totalwt].Report![SumWtg])
or
=[srptFGPKConfigsSUPK_totalwt].Report![SumWtg] + IIf([srptFGPKConfigsTPK_totalwt].Report.HasData, [srptFGPKConfigsTPK_totalwt].Report![SumWtg],0)
You will see I used a 0 instead of Null. More on that in a moment. In either case the expression will be on one line. The line breaks are for clarity here.
You may want to consider simplifying your report names, at least for purposes of posting here. It would benefit you, too, in that there is less chance of a typing error with a shorter name, and it is easier to diaganose when there is a problem.
In any case, do not try to add Null to something else. Null is, essentially, "unknown". Adding that to a number will result in another unknown. Use 0 if you mean 0, an empty string if you mean that, and Null when you specifically want Null. More here: http://allenbrowne.com/casu-11.html
Thanks for the response, Allen! (and Al and Duane, too!)
Since you and Duane touched on the "+" part of the string I thought I'd better explain. I'm trying to add the values of [srptFGPKConfigsSUPK_totalwt]![SumWtg] and [srptFGPKConfigsTPK_totalwt]![SumWtg]. There will be times when there won't be "TPK" records so I'm trying to arrive at an expression that will add the two [SumWtg} fields when they have values and when there isn't one in "TPK".
Hope that clarifies.
Considering that I tried this but it's returning a comma error:
=[Reports]![rptFGPackConfigsPKWeights]![srptFGPKConfigsSUPK_totalwt]! [SumWtg]+IIf([Reports]![rptFGPackConfigsPKWeights]![HasData], [srptFGPKConfigsTPK_totalwt]![SumWtg]),Null)
I didn't want to tinker too much more as this may be entirely off- track...?
On Mar 10, 9:32 am, "Allen Browne" <AllenBro...@SeeSig.Invalid> wrote:
> See: > Avoid #Error in form/report with no records [quoted text clipped - 38 lines] > > - Show quoted text - jlute@marzetti.com - 10 Mar 2008 18:13 GMT ALRIGHTY, THEN! Thanks for the schooling, Bruce! I consistently have problems with (.) and (!). For example, this is my original code which works just fine EXCEPT for when there's no value in [srptFGPKConfigsTPK_totalwt].[SumWtg]: =[Reports]![rptFGPackConfigsPKWeights]![srptFGPKConfigsSUPK_totalwt]! [SumWtg]+[Reports]![rptFGPackConfigsPKWeights]! [srptFGPKConfigsTPK_totalwt]![SumWtg]
That's what prompted me here. I was trying to work in the EXCEPT part.
Anyway, for whatever reason I had lots of trouble arriving at the original code above BUT it works fine and this is curious because I seem to have violated the (.) and (!) rules. No...?
I tried both of your suggestions and went with the simplified: =[srptFGPKConfigsSUPK_totalwt].[Report]![SumWtg] +IIf([srptFGPKConfigsTPK_totalwt].[Report].[HasData], [srptFGPKConfigsTPK_totalwt].[Report]![SumWtg],0)
Works perfectly! Thanks so much - I was really struggling with that. Thanks a bunch!
> Allen wrote: > [quoted text clipped - 124 lines] > > - Show quoted text - BruceM - 10 Mar 2008 19:49 GMT It gets a little complex with the bang and the dot in that controls are properties of the form or report and also members of the form's or report's controls collection, so they can be preceded in many cases by either the bang or the dot.
I don't see how the original code could work since it doesn't use the report property of the subform control, but maybe there's something going on that I haven't picked up on.
I'm glad to hear you got it working. I hope you checked out the link about the use of Null. I was paraphrasing that information when I offered my explanation. It's amazing how many things will fall into place once you get a handle on Null.
ALRIGHTY, THEN! Thanks for the schooling, Bruce! I consistently have problems with (.) and (!). For example, this is my original code which works just fine EXCEPT for when there's no value in [srptFGPKConfigsTPK_totalwt].[SumWtg]: =[Reports]![rptFGPackConfigsPKWeights]![srptFGPKConfigsSUPK_totalwt]! [SumWtg]+[Reports]![rptFGPackConfigsPKWeights]! [srptFGPKConfigsTPK_totalwt]![SumWtg]
That's what prompted me here. I was trying to work in the EXCEPT part.
Anyway, for whatever reason I had lots of trouble arriving at the original code above BUT it works fine and this is curious because I seem to have violated the (.) and (!) rules. No...?
I tried both of your suggestions and went with the simplified: =[srptFGPKConfigsSUPK_totalwt].[Report]![SumWtg] +IIf([srptFGPKConfigsTPK_totalwt].[Report].[HasData], [srptFGPKConfigsTPK_totalwt].[Report]![SumWtg],0)
Works perfectly! Thanks so much - I was really struggling with that. Thanks a bunch!
On Mar 10, 11:44 am, "BruceM" <bam...@yawhodotcalm.not> wrote:
> Allen wrote: > [quoted text clipped - 132 lines] > > - Show quoted text - jlute@marzetti.com - 10 Mar 2008 21:30 GMT > It gets a little complex with the bang and the dot in that controls are > properties of the form or report and also members of the form's or report's [quoted text clipped - 4 lines] > property of the subform control, but maybe there's something going on that I > haven't picked up on. I know it's weird but I swear it works! I've had other problems with dot and bang in the past - I wish I could remember where they were. In any case, I've had to use one or the other in the wrong way in order to make something happen. I can't imagine that I have a corrupted copy of Access because the "wrong" code works on any other computer I've tried.
> I'm glad to hear you got it working. I hope you checked out the link about > the use of Null. I was paraphrasing that information when I offered my > explanation. It's amazing how many things will fall into place once you get > a handle on Null. I did check it out, thanks! Allen is a GREAT resource, too. I don't know that I have a handle on it but it's definitely a good reference.
BruceM - 11 Mar 2008 14:07 GMT If you have a text box or a field with a reserved word as its name you can get unexepected results. If you used the bang or the dot in the "wrong" way to get the desired result then something else is going on. For instance, if you have a yes/no field named "Visible" (which you shouldn't because it's a reserved word), if you have the code: Me.Visible = False you will probably end up hiding the form. However, Me!Visible = False should set the field's Value to False. Another Yes/No field may be named Inactive, so Me.Inactive = False and Me!Inactive = False should accomplish the same thing (setting the field's value to False). I have run into mysterious errors with reserved words. In one case I had record navigation functions named FirstRecord, PrevRecord, NextRecord, LastRecord, and NewRecord. Some of them (NextRecord and NewRecord, I think) are reserved words, so I was getting some unexpected results when I called those functions. Other reserved words are more obscure, and can be quite frustrating to track down. Reserved words are among the first things I check when I get unexpected results. Several links to more information may be found here: http://www.accessmvp.com/JConrad/accessjunkie/resources.html#ReservedWords In particular, Allen Browne's consolidated listing is comprehensive, and his Issues Checker utility can be very useful.
On Mar 10, 2:49 pm, "BruceM" <bam...@yawhodotcalm.not> wrote:
> It gets a little complex with the bang and the dot in that controls are > properties of the form or report and also members of the form's or [quoted text clipped - 7 lines] > I > haven't picked up on. I know it's weird but I swear it works! I've had other problems with dot and bang in the past - I wish I could remember where they were. In any case, I've had to use one or the other in the wrong way in order to make something happen. I can't imagine that I have a corrupted copy of Access because the "wrong" code works on any other computer I've tried.
> I'm glad to hear you got it working. I hope you checked out the link about > the use of Null. I was paraphrasing that information when I offered my > explanation. It's amazing how many things will fall into place once you > get > a handle on Null. I did check it out, thanks! Allen is a GREAT resource, too. I don't know that I have a handle on it but it's definitely a good reference.
jlute@marzetti.com - 13 Mar 2008 19:40 GMT Thanks again, Bruce! That's some good info! Allen Browne is certainly an amazing resource!
> If you have a text box or a field with a reserved word as its name you can > get unexepected results. If you used the bang or the dot in the "wrong" way [quoted text clipped - 50 lines] > I did check it out, thanks! Allen is a GREAT resource, too. I don't > know that I have a handle on it but it's definitely a good reference. BruceM - 13 Mar 2008 20:13 GMT Check out his Links link (right edge of the Tips page, toward the bottom). Quite a number of talented developers have made code, sample databases, tutorials, and so forth available to all.
Thanks again, Bruce! That's some good info! Allen Browne is certainly an amazing resource!
On Mar 11, 9:07 am, "BruceM" <bam...@yawhodotcalm.not> wrote:
> If you have a text box or a field with a reserved word as its name you can > get unexepected results. If you used the bang or the dot in the "wrong" [quoted text clipped - 57 lines] > I did check it out, thanks! Allen is a GREAT resource, too. I don't > know that I have a handle on it but it's definitely a good reference. Duane Hookom - 10 Mar 2008 14:40 GMT IsNull() won't work if the subreport doesn't return any records. You can use IIf([srptCtrlName].Report.HasData, [srptCtrlName].Report!ctrlFromSub, 0)
Also your expression is very confusing since it seems to want to add (+) either a Null or a zero-length-string, both of which make no sense.
 Signature Duane Hookom Microsoft Access MVP
> I've got a text box in a report that's not returning properly. Here's > its Control Source: [quoted text clipped - 11 lines] > > As always, thanks for you help! Al Campagna - 10 Mar 2008 14:40 GMT JLute, Make sure that the Name of this calculated field is not the same as any element in the calculation itself. If you called this field [SumWtg], that would cause an #Error. That's the usual culprit...
 Signature hth Al Campagna Microsoft Access MVP http://home.comcast.net/~cccsolutions/index.html
"Find a job that you love... and you'll never work a day in your life."
> I've got a text box in a report that's not returning properly. Here's > its Control Source: [quoted text clipped - 11 lines] > > As always, thanks for you help!
|
|
|