Quote:
Originally Posted by Scott Price
Me.[FieldName] is the method of referring to a control on a form, not a field in a table. So when you renamed the control to txtRollDate1, there no longer exists a control named RollDate1 on your form, and therefore the db cannot find that Data Member.
As for the larger picture, I'm not sure how your reasoning is actually going to work for what you state as the objective. In any case, data validation is better handled in the BeforeUpdate event of the form, where the update can be canceled before the incorrect data is written to the table. Also, if you simply refer a control to itself, the data will still be saved with an 'accidental' closure of the form (I'm not sure if that situation is all that common, either?! )
Regards,
Scott
I'm a little confused. In the many other instances where I have use Me.[FieldName] to refer to a field in a table, it works the way I want it to. The problem lies in that the text field in the form was originally the same name as the field in the table (thank the wizard for that). I also just noticed that the Properties/Methods list doesn't show the
new fields that I put in the table. FYI, the Properties/Methods list shows every field in my table (minus the new fields) along with every field in the form.
A bit more explanation on my reasoning - If the form fields are bound to the table and an user puts in a wrong value then closes the form, that wrong value is stored in that field in the table. And depending on which value they enter, it may prevent that record from being accessible by that form again (due to queries being run on opening, etc). So by making the form fields unbound, the only way that information gets to the table is via the code that I am trying to get to run via them hitting the OK button.
If that still does not make sense, let me know and I will try to explain further.
(BTW, I am using Access 2003 and VB 6.5)