To Bound or Not to Bound, That is the Question

[Guest]

I have always used unbound forms in Access. It is the way I was taught. I
use a parameter query to retrieve the record I want and code to add or update
the record. There are some performance and locking problem advantages, but
there are some challanges.

I will consider changing to bound forms is someone can convince me it is the
better way.

The question is, that with unbound forms, I have never found a way to cycle
through the records (first, previous, next, last). Does anyone have a good
trick for this.

Is it possible I am the only person in the world using unbound forms?

 

[Ken Snell [MVP]]

Notes inline....

--

Ken Snell
<MS ACCESS MVP>

I have always used unbound forms in Access. It is the way I was taught.

Not sure why that would be a preferred method to teach someone, as bound
forms allow the use of numerous, built-in features that ACCESS does for you.
There are some things that can be "vexing" when using bound forms, but ...
eschewing them always? Seems very drastic.

I
use a parameter query to retrieve the record I want and code to add or
update
the record. There are some performance and locking problem advantages,
but
there are some challanges.

I will consider changing to bound forms is someone can convince me it is
the
better way.

I don't think we are going to try to convince you that you need to change.
That is your choice.

The question is, that with unbound forms, I have never found a way to
cycle
through the records (first, previous, next, last). Does anyone have a
good
trick for this.

One way to combine the benefits of both approaches is to bind the form and
have invisible controls bound to the fields on the form. Then also have
visible controls on the form that are unbound. When the form loads, or you
use code to move to a different record in the bound form's recordset, just
copy the values from the invisible controls into the visible controls. When
you want to save the edited data, your code copies the data from the visible
controls to the invisible controls.

Is it possible I am the only person in the world using unbound forms?

No.

 

[Guest]

Thanks, Ken I might give your invisible control concept a try. I am aware
of the things Access does for you with bound forms, but I am also aware of
things it does to you. Some I don't like:

You get a record displayed when you open the form.
It doesn't handle cross field validation very well..l ie if fld01 = x then
fld02 must be blank and fld03 must be > 10)

 

[Rick Brandt]

Thanks, Ken I might give your invisible control concept a try. I am
aware of the things Access does for you with bound forms, but I am
also aware of things it does to you. Some I don't like:

You get a record displayed when you open the form.

Open in Data Entry mode or with WHERE 1= 0

It doesn't handle cross field validation very well..l ie if fld01 = x
then fld02 must be blank and fld03 must be > 10)

The BeforeUpdate event of a bound form can easily deal with any validation that
you want.

 

[Guest]

Yes, in a normal world, that is correct. If you have unresolved errors, you
can cancel and not update or add the records. In this instance, however, I
have to be able to save a record marked as "INCOMPLETE" and allow users to
correct the errors at a later time. This means I have to allow adds or
updates with records that cannot pass the validation checks in the form's
controls. I NEVER put validation rules for a field in the table itself.

 

[Rick Brandt]

Yes, in a normal world, that is correct. If you have unresolved
errors, you can cancel and not update or add the records. In this
instance, however, I have to be able to save a record marked as
"INCOMPLETE" and allow users to correct the errors at a later time.
This means I have to allow adds or updates with records that cannot
pass the validation checks in the form's controls. I NEVER put
validation rules for a field in the table itself.

My point was that "whatever" you are doing now with an unbound form you can
do exactly the same thing with a bound one by using the BeforeUpdate event.