Still struggling with Bound Forms (1 Viewer)
- Thread starter Shep
- Start date
In my case, I got no dialog at all; when I clicked to move to next record, the test was re-highlighted. Thus I assumed that it was working.
boblarson
Smeghead
- Local time
- Today, 07:39
- Joined
- Jan 12, 2001
- Messages
- 32,059
And in most cases it is. I've not run into problems very many times when doing it and I do it almost exclusively. So, it just had to happen that when you went to go do something you don't normally do, you ran into a snag.And I really thought going bound was going to be quicker
To pbaldy: Nope, no validation rule anywhere, other than the field being Required (in the db). The quick and dirty sample I posted has none either, but it pops up the validation error.
I dunno Bob...doesn't seem to me that validating a required field on a form should be a big deal or even rise to the level of a 'snag'. Why should something as basic and fundamental as this cause a snag?
The procedure I posted is quite basic.
What I'm actually doing in my project in that textbox is as follows:
The Form is a modal popup whose purpose is adding new Customers.
1. Trim and remove double spaces from an entered customer name and check the resultant string against the underlying recordset to see if it exists already and is an active customer, or not, by calling a Function which returns an integer. A Select Case statement tests for the next steps.
2. If exist and active are true, ask user if they want to continue creating the Job using this customer, undo the form, close it, return to the calling form.
3. If exist true and active false, ask user if they want to set customer active and continue creating the Job using this customer, do this if yes, close form, return to the calling form.
4. If exist false, allow user to continue entering details for the new customer.
Now, all this is pretty standard stuff in my applications.
In my view, you can bind the form or not. Either way, you've got just about the same amount of code to write.
In the interest of rapid development and a desire to try to understand why the 'bound formers' get so rabid on the issue, I have attempted to bind all forms in this project, other than forms which are not related to any data in the database.
Towards this goal, I have a bound form in this instance, set up as follows:
Allow Edits True
Allow Deletions True
Allow Additions True
Data Entry True
With Data Entry set to True, the underlying recordset is empty. Therefore, I cannot check the customer name against the recordset to see if it exists.
With Data Entry set to False, and forcing the form open to a New record, the user can still navigate backwards in the recordset, a big no-no. I do NOT want an existing record showing when a form for adding a record opens, nor do I want the user to be able to navigate to one.
To allow these things is lazy and cheap programming, in my opinion.
I could prevent the navigation I describe, but it's just more code, thereby eroding further any rationale used to defend always binding.
My question to the bound forms advocates here -
Given that the field is required, how would you set up a bound form which allows for validation as described above?
If someone can show me a neat, clean way to do this on a bound form, I'll be more than happy to use it. Hell, I might even put on a brown shirt for ya.
I dunno Bob...doesn't seem to me that validating a required field on a form should be a big deal or even rise to the level of a 'snag'. Why should something as basic and fundamental as this cause a snag?
The procedure I posted is quite basic.
What I'm actually doing in my project in that textbox is as follows:
The Form is a modal popup whose purpose is adding new Customers.
1. Trim and remove double spaces from an entered customer name and check the resultant string against the underlying recordset to see if it exists already and is an active customer, or not, by calling a Function which returns an integer. A Select Case statement tests for the next steps.
2. If exist and active are true, ask user if they want to continue creating the Job using this customer, undo the form, close it, return to the calling form.
3. If exist true and active false, ask user if they want to set customer active and continue creating the Job using this customer, do this if yes, close form, return to the calling form.
4. If exist false, allow user to continue entering details for the new customer.
Now, all this is pretty standard stuff in my applications.
In my view, you can bind the form or not. Either way, you've got just about the same amount of code to write.
In the interest of rapid development and a desire to try to understand why the 'bound formers' get so rabid on the issue, I have attempted to bind all forms in this project, other than forms which are not related to any data in the database.
Towards this goal, I have a bound form in this instance, set up as follows:
Allow Edits True
Allow Deletions True
Allow Additions True
Data Entry True
With Data Entry set to True, the underlying recordset is empty. Therefore, I cannot check the customer name against the recordset to see if it exists.
With Data Entry set to False, and forcing the form open to a New record, the user can still navigate backwards in the recordset, a big no-no. I do NOT want an existing record showing when a form for adding a record opens, nor do I want the user to be able to navigate to one.
To allow these things is lazy and cheap programming, in my opinion.
I could prevent the navigation I describe, but it's just more code, thereby eroding further any rationale used to defend always binding.
My question to the bound forms advocates here -
Given that the field is required, how would you set up a bound form which allows for validation as described above?
If someone can show me a neat, clean way to do this on a bound form, I'll be more than happy to use it. Hell, I might even put on a brown shirt for ya.
Last edited:
- Local time
- Today, 15:39
- Joined
- Sep 12, 2006
- Messages
- 15,710
ive not looked at this whole thread
but if you stil lhave the issue
if you are entering a new record, then i suspect the first event is the before insert
maybe the before insery is failing for some other reason eg duplicate key error before the before update fails
why not try a form error module, or put a break point in the text field before update, to see where the code is dropping out
--------
btw i always try to use access constants ie vbcancel etc, rather than a numeric value - you never know ms may change it sometime, and anyway, you may as well hide gory details like worrying about the true value
i bet no-one ever looks up the values of the runcommand constants
but if you stil lhave the issue
if you are entering a new record, then i suspect the first event is the before insert
maybe the before insery is failing for some other reason eg duplicate key error before the before update fails
why not try a form error module, or put a break point in the text field before update, to see where the code is dropping out
--------
btw i always try to use access constants ie vbcancel etc, rather than a numeric value - you never know ms may change it sometime, and anyway, you may as well hide gory details like worrying about the true value
i bet no-one ever looks up the values of the runcommand constants
gemma,
Not sure how applicable the form BeforeInsert would be here...I want to validate the text in the field first, to ensure the user isn't adding a duplicate customer.
I have managed to do what I intended in the AfterUpdate Event. This works with the form bound or unbound.
The only drawback is that I cannot unto the textbox, no matter what I do. I have settled for undoing the whole form, which is fine...it doesn't materially affect the design/intended functionality.
Anyway, thanks very much. Your reply got me on the right track.
I happen to have left the form bound. However, to get the intuitiveness I demand, the amount of code would have been the same were it unbound.
As I learn more how to upsize Access data to SQL (or SQL Express), the notion of starting with an unbound form in the front end, something I've been doing for years already, is becoming increasingly important.
Bind your forms, but use a "WHERE 1=0", then interactively construct a new WHERE clause based on the user's data calls. I have an hour long webcast on the subject if you're interested.
Not sure how applicable the form BeforeInsert would be here...I want to validate the text in the field first, to ensure the user isn't adding a duplicate customer.
I have managed to do what I intended in the AfterUpdate Event. This works with the form bound or unbound.
The only drawback is that I cannot unto the textbox, no matter what I do. I have settled for undoing the whole form, which is fine...it doesn't materially affect the design/intended functionality.
Anyway, thanks very much. Your reply got me on the right track.
I happen to have left the form bound. However, to get the intuitiveness I demand, the amount of code would have been the same were it unbound.
As I learn more how to upsize Access data to SQL (or SQL Express), the notion of starting with an unbound form in the front end, something I've been doing for years already, is becoming increasingly important.
Bind your forms, but use a "WHERE 1=0", then interactively construct a new WHERE clause based on the user's data calls. I have an hour long webcast on the subject if you're interested.
Last edited: