#Error

[JohnLute]

I'm re-designing my reports to be a little more clean. I'm using the trick
Duane Hookom suggested: convert labels to text boxes and use the control
source to make them visible or invisible depending if they have a value or
not. So far it's working as expected, however, I came upon a glitch. I have
"-" and "+" tolerance values for many reported attributes. When applying the
control source code the report returns a "#Error" that appears on the report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!

 

[Marshall Barton]

I'm re-designing my reports to be a little more clean. I'm using the trick
Duane Hookom suggested: convert labels to text boxes and use the control
source to make them visible or invisible depending if they have a value or
not. So far it's working as expected, however, I came upon a glitch. I have
"-" and "+" tolerance values for many reported attributes. When applying the
control source code the report returns a "#Error" that appears on the report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue with:
="+ "+[CaliperThickness+TOL]

The only reason I can think of for that si that the text box
name is the same as the name of a field in the expression.
If so, change the name of the text box to something else
such as txtCaliperThickness+TOL

 

[Duane Hookom]

What do you get if you change the name of the field/column in the query to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might allow an
occasional underscore but certainly not "#$%-+*". Looks like I am cursing...

 

[JohnLute]

Thanks, Duane.

I reviewed yours and Marshall's replies. I changed the name of the
field/column to "MIN" and the field in the table to "CaliperThicknessMinTOL"

I still get the #Error!!!

What the #$%-+* is going on???

Any ideas?

--
www.Marzetti.com

What do you get if you change the name of the field/column in the query to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might allow an
occasional underscore but certainly not "#$%-+*". Looks like I am cursing...

--
Duane Hookom
MS Access MVP
--

I'm re-designing my reports to be a little more clean. I'm using the trick
Duane Hookom suggested: convert labels to text boxes and use the control
source to make them visible or invisible depending if they have a value or
not. So far it's working as expected, however, I came upon a glitch. I
have
"-" and "+" tolerance values for many reported attributes. When applying
the
control source code the report returns a "#Error" that appears on the
report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!

 

[Duane Hookom]

"MIN" isn't a good name since it is an aggregate function. If you take the
time to name a control on a report, consider using a prefix like "txt".
Sometimes #Error is a result of another calculation in the report section.

--
Duane Hookom
MS Access MVP
--

Thanks, Duane.

I reviewed yours and Marshall's replies. I changed the name of the
field/column to "MIN" and the field in the table to
"CaliperThicknessMinTOL"

I still get the #Error!!!

What the #$%-+* is going on???

Any ideas?

--
www.Marzetti.com

What do you get if you change the name of the field/column in the query
to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might allow an
occasional underscore but certainly not "#$%-+*". Looks like I am
cursing...

--
Duane Hookom
MS Access MVP
--

I'm re-designing my reports to be a little more clean. I'm using the
trick
Duane Hookom suggested: convert labels to text boxes and use the
control
source to make them visible or invisible depending if they have a value
or
not. So far it's working as expected, however, I came upon a glitch. I
have
"-" and "+" tolerance values for many reported attributes. When
applying
the
control source code the report returns a "#Error" that appears on the
report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!

 

[JohnLute]

Please see my first response below. I went tinkering around and wondered if
the CaliperThicknessMinTOL

It's data type is number with the field size set to double and the format
fixed to 4 decimal places.

Are these settings maybe fouling up things? Being a number data type is the
only difference I see between what is and isn't working.

--
www.Marzetti.com

What do you get if you change the name of the field/column in the query to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might allow an
occasional underscore but certainly not "#$%-+*". Looks like I am cursing...

--
Duane Hookom
MS Access MVP
--

I'm re-designing my reports to be a little more clean. I'm using the trick
Duane Hookom suggested: convert labels to text boxes and use the control
source to make them visible or invisible depending if they have a value or
not. So far it's working as expected, however, I came upon a glitch. I
have
"-" and "+" tolerance values for many reported attributes. When applying
the
control source code the report returns a "#Error" that appears on the
report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!

 

[JohnLute]

I changed the table field name to "CaliperThicknessMITOL"

The #Error persists!

I'm not having this issue with any other field data types. I'm starting to
conclude that it's due to the number data type of the field.

--
www.Marzetti.com

"MIN" isn't a good name since it is an aggregate function. If you take the
time to name a control on a report, consider using a prefix like "txt".
Sometimes #Error is a result of another calculation in the report section.

--
Duane Hookom
MS Access MVP
--

Thanks, Duane.

I reviewed yours and Marshall's replies. I changed the name of the
field/column to "MIN" and the field in the table to
"CaliperThicknessMinTOL"

I still get the #Error!!!

What the #$%-+* is going on???

Any ideas?

--
www.Marzetti.com

What do you get if you change the name of the field/column in the query
to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might allow an
occasional underscore but certainly not "#$%-+*". Looks like I am
cursing...

--
Duane Hookom
MS Access MVP
--

I'm re-designing my reports to be a little more clean. I'm using the
trick
Duane Hookom suggested: convert labels to text boxes and use the
control
source to make them visible or invisible depending if they have a value
or
not. So far it's working as expected, however, I came upon a glitch. I
have
"-" and "+" tolerance values for many reported attributes. When
applying
the
control source code the report returns a "#Error" that appears on the
report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!

 

[JohnLute]

I just confirmed that the error is due to the datat type of the field. I
changed it from number to text and the error went away.
--
www.Marzetti.com

"MIN" isn't a good name since it is an aggregate function. If you take the
time to name a control on a report, consider using a prefix like "txt".
Sometimes #Error is a result of another calculation in the report section.

--
Duane Hookom
MS Access MVP
--

Thanks, Duane.

I reviewed yours and Marshall's replies. I changed the name of the
field/column to "MIN" and the field in the table to
"CaliperThicknessMinTOL"

I still get the #Error!!!

What the #$%-+* is going on???

Any ideas?

--
www.Marzetti.com

What do you get if you change the name of the field/column in the query
to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might allow an
occasional underscore but certainly not "#$%-+*". Looks like I am
cursing...

--
Duane Hookom
MS Access MVP
--

I'm re-designing my reports to be a little more clean. I'm using the
trick
Duane Hookom suggested: convert labels to text boxes and use the
control
source to make them visible or invisible depending if they have a value
or
not. So far it's working as expected, however, I came upon a glitch. I
have
"-" and "+" tolerance values for many reported attributes. When
applying
the
control source code the report returns a "#Error" that appears on the
report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!

 

[JohnLute]

Sorry for the spasmodic posts.

So it looks like this doesn't work with fields of the number data type. Have
you ever experienced thi before? Any ways around it? I'd hate to change the
data types because I want to be able to fix all numerical values to 4 decimal
points.

Thanks!

--
www.Marzetti.com

"MIN" isn't a good name since it is an aggregate function. If you take the
time to name a control on a report, consider using a prefix like "txt".
Sometimes #Error is a result of another calculation in the report section.

--
Duane Hookom
MS Access MVP
--

Thanks, Duane.

I reviewed yours and Marshall's replies. I changed the name of the
field/column to "MIN" and the field in the table to
"CaliperThicknessMinTOL"

I still get the #Error!!!

What the #$%-+* is going on???

Any ideas?

--
www.Marzetti.com

What do you get if you change the name of the field/column in the query
to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might allow an
occasional underscore but certainly not "#$%-+*". Looks like I am
cursing...

--
Duane Hookom
MS Access MVP
--

I'm re-designing my reports to be a little more clean. I'm using the
trick
Duane Hookom suggested: convert labels to text boxes and use the
control
source to make them visible or invisible depending if they have a value
or
not. So far it's working as expected, however, I came upon a glitch. I
have
"-" and "+" tolerance values for many reported attributes. When
applying
the
control source code the report returns a "#Error" that appears on the
report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!

 

[Duane Hookom]

I wouldn't change the data type in the field. Try
="This is the Caption: " + IIf(IsNull([numericfield]), Null, "")

--
Duane Hookom
MS Access MVP
--

Sorry for the spasmodic posts.

So it looks like this doesn't work with fields of the number data type.
Have
you ever experienced thi before? Any ways around it? I'd hate to change
the
data types because I want to be able to fix all numerical values to 4
decimal
points.

Thanks!

--
www.Marzetti.com

"MIN" isn't a good name since it is an aggregate function. If you take
the
time to name a control on a report, consider using a prefix like "txt".
Sometimes #Error is a result of another calculation in the report
section.

--
Duane Hookom
MS Access MVP
--

Thanks, Duane.

I reviewed yours and Marshall's replies. I changed the name of the
field/column to "MIN" and the field in the table to
"CaliperThicknessMinTOL"

I still get the #Error!!!

What the #$%-+* is going on???

Any ideas?

--
www.Marzetti.com


:

What do you get if you change the name of the field/column in the
query
to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might allow an
occasional underscore but certainly not "#$%-+*". Looks like I am
cursing...

--
Duane Hookom
MS Access MVP
--

I'm re-designing my reports to be a little more clean. I'm using the
trick
Duane Hookom suggested: convert labels to text boxes and use the
control
source to make them visible or invisible depending if they have a
value
or
not. So far it's working as expected, however, I came upon a glitch.
I
have
"-" and "+" tolerance values for many reported attributes. When
applying
the
control source code the report returns a "#Error" that appears on
the
report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!

 

[JohnLute]

Fantastic! Another challenge resolved! Thanks, Duane - I never would've
gotten that on my own!

--
www.Marzetti.com

I wouldn't change the data type in the field. Try
="This is the Caption: " + IIf(IsNull([numericfield]), Null, "")

--
Duane Hookom
MS Access MVP
--

Sorry for the spasmodic posts.

So it looks like this doesn't work with fields of the number data type.
Have
you ever experienced thi before? Any ways around it? I'd hate to change
the
data types because I want to be able to fix all numerical values to 4
decimal
points.

Thanks!

--
www.Marzetti.com

"MIN" isn't a good name since it is an aggregate function. If you take
the
time to name a control on a report, consider using a prefix like "txt".
Sometimes #Error is a result of another calculation in the report
section.

--
Duane Hookom
MS Access MVP
--

Thanks, Duane.

I reviewed yours and Marshall's replies. I changed the name of the
field/column to "MIN" and the field in the table to
"CaliperThicknessMinTOL"

I still get the #Error!!!

What the #$%-+* is going on???

Any ideas?

--
www.Marzetti.com


:

What do you get if you change the name of the field/column in the
query
to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might allow an
occasional underscore but certainly not "#$%-+*". Looks like I am
cursing...

--
Duane Hookom
MS Access MVP
--

I'm re-designing my reports to be a little more clean. I'm using the
trick
Duane Hookom suggested: convert labels to text boxes and use the
control
source to make them visible or invisible depending if they have a
value
or
not. So far it's working as expected, however, I came upon a glitch.
I
have
"-" and "+" tolerance values for many reported attributes. When
applying
the
control source code the report returns a "#Error" that appears on
the
report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!

 

[JohnLute]

DRAT!

I've come across another challenge. I have "Comments" fields. For example,
the attribute "Unit Type" has a value, unit of measure, tolerance, and
comments fields. The technique we've been discussing works fine except for
when Unit Type has no value but only a comment. This results in the comment
field appearing in the report but without a label to distinguish that it's
for Unit Type.

Anyt thoughts?

--
www.Marzetti.com

I wouldn't change the data type in the field. Try
="This is the Caption: " + IIf(IsNull([numericfield]), Null, "")

--
Duane Hookom
MS Access MVP
--

Sorry for the spasmodic posts.

So it looks like this doesn't work with fields of the number data type.
Have
you ever experienced thi before? Any ways around it? I'd hate to change
the
data types because I want to be able to fix all numerical values to 4
decimal
points.

Thanks!

--
www.Marzetti.com

"MIN" isn't a good name since it is an aggregate function. If you take
the
time to name a control on a report, consider using a prefix like "txt".
Sometimes #Error is a result of another calculation in the report
section.

--
Duane Hookom
MS Access MVP
--

Thanks, Duane.

I reviewed yours and Marshall's replies. I changed the name of the
field/column to "MIN" and the field in the table to
"CaliperThicknessMinTOL"

I still get the #Error!!!

What the #$%-+* is going on???

Any ideas?

--
www.Marzetti.com


:

What do you get if you change the name of the field/column in the
query
to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might allow an
occasional underscore but certainly not "#$%-+*". Looks like I am
cursing...

--
Duane Hookom
MS Access MVP
--

I'm re-designing my reports to be a little more clean. I'm using the
trick
Duane Hookom suggested: convert labels to text boxes and use the
control
source to make them visible or invisible depending if they have a
value
or
not. So far it's working as expected, however, I came upon a glitch.
I
have
"-" and "+" tolerance values for many reported attributes. When
applying
the
control source code the report returns a "#Error" that appears on
the
report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!

 

[Duane Hookom]

Yes, I have thoughts. I hope you have learned something from the expressions
about how to use them. You should be able to combine them as I have to get
your results using IsNull() etc.

Keep in mind that if you use "+" to concatenate two strings, if one is Null,
they result becomes Null. If you use "&" to concatenate, a Null value in one
field will not Null the other.

--
Duane Hookom
MS Access MVP

DRAT!

I've come across another challenge. I have "Comments" fields. For example,
the attribute "Unit Type" has a value, unit of measure, tolerance, and
comments fields. The technique we've been discussing works fine except for
when Unit Type has no value but only a comment. This results in the
comment
field appearing in the report but without a label to distinguish that it's
for Unit Type.

Anyt thoughts?

--
www.Marzetti.com

I wouldn't change the data type in the field. Try
="This is the Caption: " + IIf(IsNull([numericfield]), Null, "")

--
Duane Hookom
MS Access MVP
--

Sorry for the spasmodic posts.

So it looks like this doesn't work with fields of the number data type.
Have
you ever experienced thi before? Any ways around it? I'd hate to change
the
data types because I want to be able to fix all numerical values to 4
decimal
points.

Thanks!

--
www.Marzetti.com


:

"MIN" isn't a good name since it is an aggregate function. If you take
the
time to name a control on a report, consider using a prefix like
"txt".
Sometimes #Error is a result of another calculation in the report
section.

--
Duane Hookom
MS Access MVP
--

Thanks, Duane.

I reviewed yours and Marshall's replies. I changed the name of the
field/column to "MIN" and the field in the table to
"CaliperThicknessMinTOL"

I still get the #Error!!!

What the #$%-+* is going on???

Any ideas?

--
www.Marzetti.com


:

What do you get if you change the name of the field/column in the
query
to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might allow
an
occasional underscore but certainly not "#$%-+*". Looks like I am
cursing...

--
Duane Hookom
MS Access MVP
--

I'm re-designing my reports to be a little more clean. I'm using
the
trick
Duane Hookom suggested: convert labels to text boxes and use the
control
source to make them visible or invisible depending if they have a
value
or
not. So far it's working as expected, however, I came upon a
glitch.
I
have
"-" and "+" tolerance values for many reported attributes. When
applying
the
control source code the report returns a "#Error" that appears on
the
report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!

 

[JohnLute]

Duane,

Thanks! I didn't realize I could concatenate two strings. I'll go back and
do that. One more question: what about unbound controls that have
mathematical strings for control sources? For example, I have one with
=[UnitCount]*[Units] as the control source. How do I manage these? Do I use
the control's name?

Thanks again!

--
www.Marzetti.com

Yes, I have thoughts. I hope you have learned something from the expressions
about how to use them. You should be able to combine them as I have to get
your results using IsNull() etc.

Keep in mind that if you use "+" to concatenate two strings, if one is Null,
they result becomes Null. If you use "&" to concatenate, a Null value in one
field will not Null the other.

--
Duane Hookom
MS Access MVP

DRAT!

I've come across another challenge. I have "Comments" fields. For example,
the attribute "Unit Type" has a value, unit of measure, tolerance, and
comments fields. The technique we've been discussing works fine except for
when Unit Type has no value but only a comment. This results in the
comment
field appearing in the report but without a label to distinguish that it's
for Unit Type.

Anyt thoughts?

--
www.Marzetti.com

I wouldn't change the data type in the field. Try
="This is the Caption: " + IIf(IsNull([numericfield]), Null, "")

--
Duane Hookom
MS Access MVP
--

Sorry for the spasmodic posts.

So it looks like this doesn't work with fields of the number data type.
Have
you ever experienced thi before? Any ways around it? I'd hate to change
the
data types because I want to be able to fix all numerical values to 4
decimal
points.

Thanks!

--
www.Marzetti.com


:

"MIN" isn't a good name since it is an aggregate function. If you take
the
time to name a control on a report, consider using a prefix like
"txt".
Sometimes #Error is a result of another calculation in the report
section.

--
Duane Hookom
MS Access MVP
--

Thanks, Duane.

I reviewed yours and Marshall's replies. I changed the name of the
field/column to "MIN" and the field in the table to
"CaliperThicknessMinTOL"

I still get the #Error!!!

What the #$%-+* is going on???

Any ideas?

--
www.Marzetti.com


:

What do you get if you change the name of the field/column in the
query
to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might allow
an
occasional underscore but certainly not "#$%-+*". Looks like I am
cursing...

--
Duane Hookom
MS Access MVP
--

I'm re-designing my reports to be a little more clean. I'm using
the
trick
Duane Hookom suggested: convert labels to text boxes and use the
control
source to make them visible or invisible depending if they have a
value
or
not. So far it's working as expected, however, I came upon a
glitch.
I
have
"-" and "+" tolerance values for many reported attributes. When
applying
the
control source code the report returns a "#Error" that appears on
the
report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!

 

[Duane Hookom]

Use the fields.

--
Duane Hookom
MS Access MVP

Duane,

Thanks! I didn't realize I could concatenate two strings. I'll go back and
do that. One more question: what about unbound controls that have
mathematical strings for control sources? For example, I have one with
=[UnitCount]*[Units] as the control source. How do I manage these? Do I
use
the control's name?

Thanks again!

--
www.Marzetti.com

Yes, I have thoughts. I hope you have learned something from the
expressions
about how to use them. You should be able to combine them as I have to
get
your results using IsNull() etc.

Keep in mind that if you use "+" to concatenate two strings, if one is
Null,
they result becomes Null. If you use "&" to concatenate, a Null value in
one
field will not Null the other.

--
Duane Hookom
MS Access MVP

DRAT!

I've come across another challenge. I have "Comments" fields. For
example,
the attribute "Unit Type" has a value, unit of measure, tolerance, and
comments fields. The technique we've been discussing works fine except
for
when Unit Type has no value but only a comment. This results in the
comment
field appearing in the report but without a label to distinguish that
it's
for Unit Type.

Anyt thoughts?

--
www.Marzetti.com


:

I wouldn't change the data type in the field. Try
="This is the Caption: " + IIf(IsNull([numericfield]), Null, "")

--
Duane Hookom
MS Access MVP
--

Sorry for the spasmodic posts.

So it looks like this doesn't work with fields of the number data
type.
Have
you ever experienced thi before? Any ways around it? I'd hate to
change
the
data types because I want to be able to fix all numerical values to
4
decimal
points.

Thanks!

--
www.Marzetti.com


:

"MIN" isn't a good name since it is an aggregate function. If you
take
the
time to name a control on a report, consider using a prefix like
"txt".
Sometimes #Error is a result of another calculation in the report
section.

--
Duane Hookom
MS Access MVP
--

Thanks, Duane.

I reviewed yours and Marshall's replies. I changed the name of
the
field/column to "MIN" and the field in the table to
"CaliperThicknessMinTOL"

I still get the #Error!!!

What the #$%-+* is going on???

Any ideas?

--
www.Marzetti.com


:

What do you get if you change the name of the field/column in
the
query
to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might
allow
an
occasional underscore but certainly not "#$%-+*". Looks like I
am
cursing...

--
Duane Hookom
MS Access MVP
--

I'm re-designing my reports to be a little more clean. I'm
using
the
trick
Duane Hookom suggested: convert labels to text boxes and use
the
control
source to make them visible or invisible depending if they
have a
value
or
not. So far it's working as expected, however, I came upon a
glitch.
I
have
"-" and "+" tolerance values for many reported attributes.
When
applying
the
control source code the report returns a "#Error" that appears
on
the
report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue
with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!

 

[JohnLute]

Thanks for all your time and support, Duane!

This is going to make a tremendous difference to my database.

--
www.Marzetti.com

Use the fields.

--
Duane Hookom
MS Access MVP

Duane,

Thanks! I didn't realize I could concatenate two strings. I'll go back and
do that. One more question: what about unbound controls that have
mathematical strings for control sources? For example, I have one with
=[UnitCount]*[Units] as the control source. How do I manage these? Do I
use
the control's name?

Thanks again!

--
www.Marzetti.com

Yes, I have thoughts. I hope you have learned something from the
expressions
about how to use them. You should be able to combine them as I have to
get
your results using IsNull() etc.

Keep in mind that if you use "+" to concatenate two strings, if one is
Null,
they result becomes Null. If you use "&" to concatenate, a Null value in
one
field will not Null the other.

--
Duane Hookom
MS Access MVP


DRAT!

I've come across another challenge. I have "Comments" fields. For
example,
the attribute "Unit Type" has a value, unit of measure, tolerance, and
comments fields. The technique we've been discussing works fine except
for
when Unit Type has no value but only a comment. This results in the
comment
field appearing in the report but without a label to distinguish that
it's
for Unit Type.

Anyt thoughts?

--
www.Marzetti.com


:

I wouldn't change the data type in the field. Try
="This is the Caption: " + IIf(IsNull([numericfield]), Null, "")

--
Duane Hookom
MS Access MVP
--

Sorry for the spasmodic posts.

So it looks like this doesn't work with fields of the number data
type.
Have
you ever experienced thi before? Any ways around it? I'd hate to
change
the
data types because I want to be able to fix all numerical values to
4
decimal
points.

Thanks!

--
www.Marzetti.com


:

"MIN" isn't a good name since it is an aggregate function. If you
take
the
time to name a control on a report, consider using a prefix like
"txt".
Sometimes #Error is a result of another calculation in the report
section.

--
Duane Hookom
MS Access MVP
--

Thanks, Duane.

I reviewed yours and Marshall's replies. I changed the name of
the
field/column to "MIN" and the field in the table to
"CaliperThicknessMinTOL"

I still get the #Error!!!

What the #$%-+* is going on???

Any ideas?

--
www.Marzetti.com


:

What do you get if you change the name of the field/column in
the
query
to
something like:

CalThickMinusTOL: [CaliperThickness-TOL]

I detest using any type of symbols in object names. I might
allow
an
occasional underscore but certainly not "#$%-+*". Looks like I
am
cursing...

--
Duane Hookom
MS Access MVP
--

I'm re-designing my reports to be a little more clean. I'm
using
the
trick
Duane Hookom suggested: convert labels to text boxes and use
the
control
source to make them visible or invisible depending if they
have a
value
or
not. So far it's working as expected, however, I came upon a
glitch.
I
have
"-" and "+" tolerance values for many reported attributes.
When
applying
the
control source code the report returns a "#Error" that appears
on
the
report
for that control. Here's the control source:
="- "+[CaliperThickness-TOL]

I'm assuming the "-" is causing fits. I have the same issue
with:
="+ "+[CaliperThickness+TOL]

Any way around this?

Thanks in advance!