Type mismatch error

[G]

I have a mortgage application that has been working fine for 2 weeks, but now
is coming up with "type mismatch error" when I try to change the rate in a
combo box.
This combo box is based on a table and the data is numerical. It has event
that goes to a macro.

mcoPmt
condition = True: [cboL1Rate] Is Not Null And [optIOonly1a]=False
action = SetValue
arguments = [txtMoPIpmt1],
Pmt(([cboL1Rate].[Column](1)*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

Could someone look at this and perhaps see something that I'm not seeing?
And why would it work for weeks, then not work?

 

[G. Vaught]

Mismatch errors usually appear when you try to put a value that is not
accepted by the datatype defined for the field. Since rates are expressed as
floating point values, your datafield type needs to support floats. Try
setting the datatype to Double.

 

[G]

I can't the error to repeat itself, but I went ahead and changed the type to
"double"
I can't figure out for the life of me, why this is an inconsistent error. I
have been playing with the database for 3 weeks, and no error. Then, it
errors. After closing the db, and re-opening it, I can't get it to error out.
Hmmmm....any suggestions on this?

Mismatch errors usually appear when you try to put a value that is not
accepted by the datatype defined for the field. Since rates are expressed as
floating point values, your datafield type needs to support floats. Try
setting the datatype to Double.

I have a mortgage application that has been working fine for 2 weeks, but
now
is coming up with "type mismatch error" when I try to change the rate in a
combo box.
This combo box is based on a table and the data is numerical. It has event
that goes to a macro.

mcoPmt
condition = True: [cboL1Rate] Is Not Null And [optIOonly1a]=False
action = SetValue
arguments = [txtMoPIpmt1],
Pmt(([cboL1Rate].[Column](1)*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

Could someone look at this and perhaps see something that I'm not seeing?
And why would it work for weeks, then not work?

 

[G]

That did not work. I still get the error. I have to have this working by
Monday.
Any other suggestions?

I can't the error to repeat itself, but I went ahead and changed the type to
"double"
I can't figure out for the life of me, why this is an inconsistent error. I
have been playing with the database for 3 weeks, and no error. Then, it
errors. After closing the db, and re-opening it, I can't get it to error out.
Hmmmm....any suggestions on this?

Mismatch errors usually appear when you try to put a value that is not
accepted by the datatype defined for the field. Since rates are expressed as
floating point values, your datafield type needs to support floats. Try
setting the datatype to Double.

I have a mortgage application that has been working fine for 2 weeks, but
now
is coming up with "type mismatch error" when I try to change the rate in a
combo box.
This combo box is based on a table and the data is numerical. It has event
that goes to a macro.

mcoPmt
condition = True: [cboL1Rate] Is Not Null And [optIOonly1a]=False
action = SetValue
arguments = [txtMoPIpmt1],
Pmt(([cboL1Rate].[Column](1)*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

Could someone look at this and perhaps see something that I'm not seeing?
And why would it work for weeks, then not work?

 

[G]

Don't know if my reply went through.
Still getting the error....any other suggestions?
I have to have this working by monday.

I can't the error to repeat itself, but I went ahead and changed the type to
"double"
I can't figure out for the life of me, why this is an inconsistent error. I
have been playing with the database for 3 weeks, and no error. Then, it
errors. After closing the db, and re-opening it, I can't get it to error out.
Hmmmm....any suggestions on this?

Mismatch errors usually appear when you try to put a value that is not
accepted by the datatype defined for the field. Since rates are expressed as
floating point values, your datafield type needs to support floats. Try
setting the datatype to Double.

I have a mortgage application that has been working fine for 2 weeks, but
now
is coming up with "type mismatch error" when I try to change the rate in a
combo box.
This combo box is based on a table and the data is numerical. It has event
that goes to a macro.

mcoPmt
condition = True: [cboL1Rate] Is Not Null And [optIOonly1a]=False
action = SetValue
arguments = [txtMoPIpmt1],
Pmt(([cboL1Rate].[Column](1)*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

Could someone look at this and perhaps see something that I'm not seeing?
And why would it work for weeks, then not work?

 

[Ken Snell [MVP]]

When you read a value from a column of a combo box, that value usually is a
string, regardless of what you have set for it in the Row Source query for
the combo box. I'm guessing that you need to cast the combo box's column 1
value as a number:

arguments = [txtMoPIpmt1],
Pmt((CDbl([cboL1Rate].[Column](1))*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

 

[G]

Thanks Ken!
That makes sense. I can do that.
Upon further testing, trying to make it error out, I also determined that
sometimes the [txtNumMonths1] has not been filled in. That would make the
value null, correct? And cause the calculation to error out. Would this be an
additional cause?
Besides resetting the tab order, what would be the best way to force the
user fill in the number of months before they get to the rate box?

When you read a value from a column of a combo box, that value usually is a
string, regardless of what you have set for it in the Row Source query for
the combo box. I'm guessing that you need to cast the combo box's column 1
value as a number:

arguments = [txtMoPIpmt1],
Pmt((CDbl([cboL1Rate].[Column](1))*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

--

Ken Snell
<MS ACCESS MVP>

I have a mortgage application that has been working fine for 2 weeks, but
now
is coming up with "type mismatch error" when I try to change the rate in a
combo box.
This combo box is based on a table and the data is numerical. It has event
that goes to a macro.

mcoPmt
condition = True: [cboL1Rate] Is Not Null And [optIOonly1a]=False
action = SetValue
arguments = [txtMoPIpmt1],
Pmt(([cboL1Rate].[Column](1)*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

Could someone look at this and perhaps see something that I'm not seeing?
And why would it work for weeks, then not work?

 

[Ken Snell [MVP]]

I've not used the function that you're using, but it's possible that a Null
value could cause a problem.

Use the form's BeforeUpdate event to test if the value in the txtNumMonths
control is empty, and require the user to enter a value; you'd do that by
canceling the event and putting focus on that textbox with a popup message
to inform the user.

--

Ken Snell
<MS ACCESS MVP>

Thanks Ken!
That makes sense. I can do that.
Upon further testing, trying to make it error out, I also determined that
sometimes the [txtNumMonths1] has not been filled in. That would make the
value null, correct? And cause the calculation to error out. Would this be
an
additional cause?
Besides resetting the tab order, what would be the best way to force the
user fill in the number of months before they get to the rate box?

When you read a value from a column of a combo box, that value usually is
a
string, regardless of what you have set for it in the Row Source query
for
the combo box. I'm guessing that you need to cast the combo box's column
1
value as a number:

arguments = [txtMoPIpmt1],
Pmt((CDbl([cboL1Rate].[Column](1))*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

--

Ken Snell
<MS ACCESS MVP>

I have a mortgage application that has been working fine for 2 weeks,
but
now
is coming up with "type mismatch error" when I try to change the rate
in a
combo box.
This combo box is based on a table and the data is numerical. It has
event
that goes to a macro.

mcoPmt
condition = True: [cboL1Rate] Is Not Null And [optIOonly1a]=False
action = SetValue
arguments = [txtMoPIpmt1],
Pmt(([cboL1Rate].[Column](1)*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

Could someone look at this and perhaps see something that I'm not
seeing?
And why would it work for weeks, then not work?

 

[G]

Thank you Ken. Your help is greatly appreciated.
I'll respond as soon as I make the changes and see if it all works.
G

I've not used the function that you're using, but it's possible that a Null
value could cause a problem.

Use the form's BeforeUpdate event to test if the value in the txtNumMonths
control is empty, and require the user to enter a value; you'd do that by
canceling the event and putting focus on that textbox with a popup message
to inform the user.

--

Ken Snell
<MS ACCESS MVP>

Thanks Ken!
That makes sense. I can do that.
Upon further testing, trying to make it error out, I also determined that
sometimes the [txtNumMonths1] has not been filled in. That would make the
value null, correct? And cause the calculation to error out. Would this be
an
additional cause?
Besides resetting the tab order, what would be the best way to force the
user fill in the number of months before they get to the rate box?

When you read a value from a column of a combo box, that value usually is
a
string, regardless of what you have set for it in the Row Source query
for
the combo box. I'm guessing that you need to cast the combo box's column
1
value as a number:

arguments = [txtMoPIpmt1],
Pmt((CDbl([cboL1Rate].[Column](1))*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

--

Ken Snell
<MS ACCESS MVP>


I have a mortgage application that has been working fine for 2 weeks,
but
now
is coming up with "type mismatch error" when I try to change the rate
in a
combo box.
This combo box is based on a table and the data is numerical. It has
event
that goes to a macro.

mcoPmt
condition = True: [cboL1Rate] Is Not Null And [optIOonly1a]=False
action = SetValue
arguments = [txtMoPIpmt1],
Pmt(([cboL1Rate].[Column](1)*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

Could someone look at this and perhaps see something that I'm not
seeing?
And why would it work for weeks, then not work?

 

[G]

Can you explain why would I use the form's BeforeUpdate event instead of the
field's beforeupdate event? I have 8 of these controls that must be checked
for null first.

I am getting the following error message:
You must save the field before you execute the GoToControl action, the
GoToControl method, or the SetFocus method.
You tried to move the focus to another control using the SetFocus method,
GoToControl action, or the GoTo Control method.
Set the macro or method to the AfterUpdate property instead of the
BeforeUpdate property so it saves the field before changing the focus.

I've not used the function that you're using, but it's possible that a Null
value could cause a problem.

Use the form's BeforeUpdate event to test if the value in the txtNumMonths
control is empty, and require the user to enter a value; you'd do that by
canceling the event and putting focus on that textbox with a popup message
to inform the user.

--

Ken Snell
<MS ACCESS MVP>

Thanks Ken!
That makes sense. I can do that.
Upon further testing, trying to make it error out, I also determined that
sometimes the [txtNumMonths1] has not been filled in. That would make the
value null, correct? And cause the calculation to error out. Would this be
an
additional cause?
Besides resetting the tab order, what would be the best way to force the
user fill in the number of months before they get to the rate box?

When you read a value from a column of a combo box, that value usually is
a
string, regardless of what you have set for it in the Row Source query
for
the combo box. I'm guessing that you need to cast the combo box's column
1
value as a number:

arguments = [txtMoPIpmt1],
Pmt((CDbl([cboL1Rate].[Column](1))*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

--

Ken Snell
<MS ACCESS MVP>


I have a mortgage application that has been working fine for 2 weeks,
but
now
is coming up with "type mismatch error" when I try to change the rate
in a
combo box.
This combo box is based on a table and the data is numerical. It has
event
that goes to a macro.

mcoPmt
condition = True: [cboL1Rate] Is Not Null And [optIOonly1a]=False
action = SetValue
arguments = [txtMoPIpmt1],
Pmt(([cboL1Rate].[Column](1)*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

Could someone look at this and perhaps see something that I'm not
seeing?
And why would it work for weeks, then not work?

 

[Ken Snell [MVP]]

The reason I suggest the form's BeforeUpdate event is because the control's
BeforeUpdate event will not occur if the user never goes into that control
and edits/enters data. Thus, if the user ignores the control or just tabs
through it, then your validation code will not run. The form's BeforeUpdate
event will occur just before the data are committed to the underlying
recordsource's table(s).

--

Ken Snell
<MS ACCESS MVP>

Can you explain why would I use the form's BeforeUpdate event instead of
the
field's beforeupdate event? I have 8 of these controls that must be
checked
for null first.

I am getting the following error message:
You must save the field before you execute the GoToControl action, the
GoToControl method, or the SetFocus method.
You tried to move the focus to another control using the SetFocus method,
GoToControl action, or the GoTo Control method.
Set the macro or method to the AfterUpdate property instead of the
BeforeUpdate property so it saves the field before changing the focus.

I've not used the function that you're using, but it's possible that a
Null
value could cause a problem.

Use the form's BeforeUpdate event to test if the value in the
txtNumMonths
control is empty, and require the user to enter a value; you'd do that by
canceling the event and putting focus on that textbox with a popup
message
to inform the user.

--

Ken Snell
<MS ACCESS MVP>

Thanks Ken!
That makes sense. I can do that.
Upon further testing, trying to make it error out, I also determined
that
sometimes the [txtNumMonths1] has not been filled in. That would make
the
value null, correct? And cause the calculation to error out. Would this
be
an
additional cause?
Besides resetting the tab order, what would be the best way to force
the
user fill in the number of months before they get to the rate box?

:

When you read a value from a column of a combo box, that value usually
is
a
string, regardless of what you have set for it in the Row Source query
for
the combo box. I'm guessing that you need to cast the combo box's
column
1
value as a number:

arguments = [txtMoPIpmt1],
Pmt((CDbl([cboL1Rate].[Column](1))*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

--

Ken Snell
<MS ACCESS MVP>


I have a mortgage application that has been working fine for 2 weeks,
but
now
is coming up with "type mismatch error" when I try to change the
rate
in a
combo box.
This combo box is based on a table and the data is numerical. It has
event
that goes to a macro.

mcoPmt
condition = True: [cboL1Rate] Is Not Null And [optIOonly1a]=False
action = SetValue
arguments = [txtMoPIpmt1],
Pmt(([cboL1Rate].[Column](1)*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

Could someone look at this and perhaps see something that I'm not
seeing?
And why would it work for weeks, then not work?

 

[G]

Once again, thank you Ken

The reason I suggest the form's BeforeUpdate event is because the control's
BeforeUpdate event will not occur if the user never goes into that control
and edits/enters data. Thus, if the user ignores the control or just tabs
through it, then your validation code will not run. The form's BeforeUpdate
event will occur just before the data are committed to the underlying
recordsource's table(s).

--

Ken Snell
<MS ACCESS MVP>

Can you explain why would I use the form's BeforeUpdate event instead of
the
field's beforeupdate event? I have 8 of these controls that must be
checked
for null first.

I am getting the following error message:
You must save the field before you execute the GoToControl action, the
GoToControl method, or the SetFocus method.
You tried to move the focus to another control using the SetFocus method,
GoToControl action, or the GoTo Control method.
Set the macro or method to the AfterUpdate property instead of the
BeforeUpdate property so it saves the field before changing the focus.

I've not used the function that you're using, but it's possible that a
Null
value could cause a problem.

Use the form's BeforeUpdate event to test if the value in the
txtNumMonths
control is empty, and require the user to enter a value; you'd do that by
canceling the event and putting focus on that textbox with a popup
message
to inform the user.

--

Ken Snell
<MS ACCESS MVP>


Thanks Ken!
That makes sense. I can do that.
Upon further testing, trying to make it error out, I also determined
that
sometimes the [txtNumMonths1] has not been filled in. That would make
the
value null, correct? And cause the calculation to error out. Would this
be
an
additional cause?
Besides resetting the tab order, what would be the best way to force
the
user fill in the number of months before they get to the rate box?

:

When you read a value from a column of a combo box, that value usually
is
a
string, regardless of what you have set for it in the Row Source query
for
the combo box. I'm guessing that you need to cast the combo box's
column
1
value as a number:

arguments = [txtMoPIpmt1],
Pmt((CDbl([cboL1Rate].[Column](1))*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

--

Ken Snell
<MS ACCESS MVP>


I have a mortgage application that has been working fine for 2 weeks,
but
now
is coming up with "type mismatch error" when I try to change the
rate
in a
combo box.
This combo box is based on a table and the data is numerical. It has
event
that goes to a macro.

mcoPmt
condition = True: [cboL1Rate] Is Not Null And [optIOonly1a]=False
action = SetValue
arguments = [txtMoPIpmt1],
Pmt(([cboL1Rate].[Column](1)*0.01)/12,[Forms]![frmBuildFlyer]![txtNumMonths1],[txtLA1]*-1)

Could someone look at this and perhaps see something that I'm not
seeing?
And why would it work for weeks, then not work?