473,703 Members | 2,820 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Need better argument for using bound forms

I have a lot of respect for David Fenton and Allen Browne, but I don't
understand why people who know how to write code to completely replace
a front end do not write something that will automate the code that
implements managing unbound controls on forms given the superior
performance of unbound controls in a client/server environment. I can
easily understand a newbie using bound controls or someone with a
tight deadline. I guess I need to hear a better argument against
unbound forms than more coding is required. Note: I did Access before
doing any DB apps in VB so I'm not simply accustomed to old methods.
Of course, if you can get away with using bound forms it's simpler to
use them. I only reinvent the wheel when the new wheel is better :-).
I don't think that having the option to use bound forms is a bad idea.
It's just not a good enough idea for me to use indiscriminatel y. The
only reason I can see for using them is instant gratification for the
user (a good reason BTW).

James A. Fortune
Nov 13 '05 #1
19 4102
On 12 Aug 2004 12:38:19 -0700, ja******@oaklan d.edu (James Fortune)
wrote:

Most of my clients look at cost first, performance later.
Also, not many Access apps are written for the number of concurrent
users where client/server really makes a difference.

-Tom.

I have a lot of respect for David Fenton and Allen Browne, but I don't
understand why people who know how to write code to completely replace
a front end do not write something that will automate the code that
implements managing unbound controls on forms given the superior
performance of unbound controls in a client/server environment. I can
easily understand a newbie using bound controls or someone with a
tight deadline. I guess I need to hear a better argument against
unbound forms than more coding is required. Note: I did Access before
doing any DB apps in VB so I'm not simply accustomed to old methods.
Of course, if you can get away with using bound forms it's simpler to
use them. I only reinvent the wheel when the new wheel is better :-).
I don't think that having the option to use bound forms is a bad idea.
It's just not a good enough idea for me to use indiscriminatel y. The
only reason I can see for using them is instant gratification for the
user (a good reason BTW).

James A. Fortune


Nov 13 '05 #2
On 12 Aug 2004 12:38:19 -0700, ja******@oaklan d.edu (James Fortune)
wrote:
I have a lot of respect for David Fenton and Allen Browne, but I don't
understand why people who know how to write code to completely replace
a front end do not write something that will automate the code that
implements managing unbound controls on forms given the superior
performance of unbound controls in a client/server environment. I can
easily understand a newbie using bound controls or someone with a
tight deadline. I guess I need to hear a better argument against
unbound forms than more coding is required. Note: I did Access before
doing any DB apps in VB so I'm not simply accustomed to old methods.
Of course, if you can get away with using bound forms it's simpler to
use them. I only reinvent the wheel when the new wheel is better :-).
I don't think that having the option to use bound forms is a bad idea.
It's just not a good enough idea for me to use indiscriminatel y. The
only reason I can see for using them is instant gratification for the
user (a good reason BTW).

James A. Fortune


Hi James
A bound form doesn't need to be bound to more records than you
currently need to have on the client so there needn't be that much
inefficiency.

When I started programming we used to write our own input routines
with fancy buffering and that was more efficient too, it's a matter of
taste really. However using an unbound form is one way of allowing
"change now, confirm all changes later" though I would still do this
by binding to a local temporary table.
David Schofield

Nov 13 '05 #3
d.************* **@blueyonder.c o.uk (David Schofield) wrote in message news:<411c7b7a. 162485181@local host>...
Hi James
A bound form doesn't need to be bound to more records than you
currently need to have on the client so there needn't be that much
inefficiency.

When I started programming we used to write our own input routines
with fancy buffering and that was more efficient too, it's a matter of
taste really. However using an unbound form is one way of allowing
"change now, confirm all changes later" though I would still do this
by binding to a local temporary table.
David Schofield


Those are good points. I need to clarify what I meant by automating.
Suppose you use a naming convention where the textboxes, comboboxes,
etc. have the name of the field you want to use. By passing your
recordset to a function you can have each unbound form filled using
the same code. You would validate the data using AfterUpdate in a
fashion that is very similar to using BeforeUpdate on a bound form or
create a subroutine to do all the validation (I have some pretty
extreme validation situations). Another function can be used all the
time that submits the changes to the recordset. The "change now,
confirm all changes later" works well using the local temporary table
as you suggest, and I have done that before, but there is still that
extra click involved. I also have to bring up a prompt when users
change data and try to close the form without selecting whether to
save or discard changes. Sometimes when using bound subforms the
management insists on being able to edit the field in datasheet view.
In that case I lock down all the other fields on the subform and only
unlock the field for certain users. Plus I perform validation using
the subform code. Anyway, I'm glad Access gives me the ability to
choose whether to use bound or unbound data.

James A. Fortune
Nov 13 '05 #4
On 13 Aug 2004 15:18:58 -0700, ja******@oaklan d.edu (James Fortune)
wrote:
...... By passing your
recordset to a function you can have each unbound form filled using
the same code.


Yes, this is similar to how dynamic crosstabs can be managed.

Another approach is to generate the whole form from the table/query
definition (you can even do this dynamically - I still use
Access97/DAO to do this). Access is so easy to program in, much easier
than VB, the MS_SQL or db2 tools etc etc. and can be used via ODBC and
data definition queries to do a lot of the definition and reporting
from those ugly systems!

Nov 13 '05 #5
ja******@oaklan d.edu (James Fortune) wrote

. . . but I don't understand why people who
know how to write code to completely replace
a front end do not write something that will
automate the code that implements managing
unbound controls on forms given the superior
performance of unbound controls in a client/
server environment.
What "superior performance" would that be, James? The vast majority of
my paying Access work has been Access clients to server databases,
using MDB-Jet-ODBC-serverDB, with the vast majority of the forms
bound, and users perfectly happy with performance. My only observation
of "superior performance" has been reports of people who were pushing
the envelope on Access-Jet multiuser, not client-server. And, even so,
there seem to be equally many reports of satisfactory multiuser
performance with bound forms.

I can easily understand a newbie using
bound controls or someone with a
tight deadline.
Strange, the first is the same argument I use about unbound forms --
newbies who haven't invested the time and effort to learn how Access
works and to work _with_ it often have to resort to unbound forms and
code to accomplish what they want to do. The more experienced
developers know how to work with Access, and get the functionality
they need from bound forms for data handling. Of course, unbound forms
for splash screens, switchboards, and user selection of criteria for
reports and forms make sense.
I guess I need to hear a better argument
against unbound forms than more coding is
required.
I have not observed the performance improvement you describe, but the
consensus is that using unbound forms does take more time and effort
to implement. And, clearly, not only is "more coding required", but
you are reimplementing functionality that is included with bound
forms, has been proven/tested by millions of users for over ten years,
and is maintained by someone else (as part of the price of the Access
product). It's hard to get that kind of "test group" for your
re-invented code.
Of course, if you can get away with using
bound forms it's simpler to use them.
Of course, it's simpler to use them... there is rich data-event model
to make it so. That rich data-event model, contrasted with the less
data-oriented event model of classic VB (which does not nearly so well
lend itself to bound controls -- it has no bound _forms_) is why
people experienced in both tend to work in Access. They usually say
they see no less than a 3X greater time and effort to do the same app
in VB. But I don't see what you mean by "get away with"; as I said, in
the last 5 of my more than 10 years doing Access, the only unbound
forms I create are splash, switchboard, and selection.
I only reinvent the wheel when the new
wheel is better :-).
My clients don't want, and will not, pay for "reinventin g wheels",
even if some minimal/marginal performance improvement can be shown.
I don't think that having the option to
use bound forms is a bad idea. It's just
not a good enough idea for me to use
indiscriminatel y.
IMNSHO, you can replace "bound" with "unbound" and "indiscriminate ly"
with "for handling data" in the quoted paragraph.

The only reason I can see for using
them is instant gratification for the
user (a good reason BTW).


The only reason I can see for using unbound forms are for features
that do not require accessing data and, if the developer hasn't
invested the time and effort to work with bound forms and make them do
what he needs. Others whose opinions I respect differ with me on this
issue.

My clients have been very happy with the bound forms I use, the
efficient development and lower cost, and with the performance.
Depending on your grokking "the Access way", YMMV.

Larry Linson
Microsoft Access MVP
Nov 13 '05 #6
la**********@nt pcug.org (Larry Linson) wrote in message news:<fc******* *************** ****@posting.go ogle.com>...
ja******@oaklan d.edu (James Fortune) wrote

> . . . but I don't understand why people who
> know how to write code to completely replace
> a front end do not write something that will
> automate the code that implements managing
> unbound controls on forms given the superior
> performance of unbound controls in a client/
> server environment.
What "superior performance" would that be, James? The vast majority of
my paying Access work has been Access clients to server databases,
using MDB-Jet-ODBC-serverDB, with the vast majority of the forms
bound, and users perfectly happy with performance. My only observation
of "superior performance" has been reports of people who were pushing
the envelope on Access-Jet multiuser, not client-server. And, even so,
there seem to be equally many reports of satisfactory multiuser
performance with bound forms.


I used the words client-server to indicate Access-Jet multiuser, not
the ODBC situation you describe. And you are correct that even in
this situation most customers find bound forms adequate.

> I can easily understand a newbie using
> bound controls or someone with a
> tight deadline.
Strange, the first is the same argument I use about unbound forms --
newbies who haven't invested the time and effort to learn how Access
works and to work _with_ it often have to resort to unbound forms and
code to accomplish what they want to do. The more experienced
developers know how to work with Access, and get the functionality
they need from bound forms for data handling. Of course, unbound forms
for splash screens, switchboards, and user selection of criteria for
reports and forms make sense.


I see very little extra functionality in using bound forms over
unbound. There's just not that much difference.
> I guess I need to hear a better argument
> against unbound forms than more coding is
> required.
I have not observed the performance improvement you describe, but the
consensus is that using unbound forms does take more time and effort
to implement. And, clearly, not only is "more coding required", but
you are reimplementing functionality that is included with bound
forms, has been proven/tested by millions of users for over ten years,
and is maintained by someone else (as part of the price of the Access
product). It's hard to get that kind of "test group" for your
re-invented code.


The only reinvented code is putting the data on the form and saving
it. How hard is that? How big of a "test group" do I need to make
sure that works?
> Of course, if you can get away with using
> bound forms it's simpler to use them.
Of course, it's simpler to use them... there is rich data-event model
to make it so. That rich data-event model, contrasted with the less
data-oriented event model of classic VB (which does not nearly so well
lend itself to bound controls -- it has no bound _forms_) is why
people experienced in both tend to work in Access. They usually say
they see no less than a 3X greater time and effort to do the same app
in VB. But I don't see what you mean by "get away with"; as I said, in
the last 5 of my more than 10 years doing Access, the only unbound
forms I create are splash, switchboard, and selection.


Access IS about 3x faster than coding in VB. Bound forms are only a
small part of that number. The only bound forms I use are either
bound to local tables or recordsets for subforms that are tied to data
on the main form.
> I only reinvent the wheel when the new
> wheel is better :-).
My clients don't want, and will not, pay for "reinventin g wheels",
even if some minimal/marginal performance improvement can be shown.


If I were coding for them I would use bound forms :-).
> I don't think that having the option to
> use bound forms is a bad idea. It's just
> not a good enough idea for me to use
> indiscriminatel y.
IMNSHO, you can replace "bound" with "unbound" and "indiscriminate ly"
with "for handling data" in the quoted paragraph.


You should try it and compare your network traffic. My clients don't
want, and will not pay, for techniques that cause them to have to
spend unnecessary money on their (Jet accessed) network because it
keeps records locked too long and slows down the network.

> The only reason I can see for using
> them is instant gratification for the
> user (a good reason BTW).
The only reason I can see for using unbound forms are for features
that do not require accessing data and, if the developer hasn't
invested the time and effort to work with bound forms and make them do
what he needs. Others whose opinions I respect differ with me on this
issue.


I've used both and like unbound. Maybe you've used both and prefer
bound. I see nothing wrong with that. If you don't like unbound
forms you don't need to use them.

My clients have been very happy with the bound forms I use, the
efficient development and lower cost, and with the performance.
Depending on your grokking "the Access way", YMMV.
I've had good success with my "grokking." It takes very little extra
time and seems to keep clients happy, except for that extra click it
takes to submit the changes. Maybe if you enumerated exactly what is
really gained by using bound forms I would be more inclined to use
them. Keep in mind that unbound forms also take advantage of Access'
richness so be sure to not to include those.

Larry Linson
Microsoft Access MVP


James A. Fortune
Nov 13 '05 #7
rkc

"James Fortune" <ja******@oakla nd.edu> wrote in message
news:a6******** *************** ***@posting.goo gle.com...
I have a lot of respect for David Fenton and Allen Browne, but I don't
understand why people who know how to write code to completely replace
a front end do not write something that will automate the code that
implements managing unbound controls on forms given the superior
performance of unbound controls in a client/server environment. I can
easily understand a newbie using bound controls or someone with a
tight deadline. I guess I need to hear a better argument against
unbound forms than more coding is required. Note: I did Access before
doing any DB apps in VB so I'm not simply accustomed to old methods.
Of course, if you can get away with using bound forms it's simpler to
use them. I only reinvent the wheel when the new wheel is better :-).
I don't think that having the option to use bound forms is a bad idea.
It's just not a good enough idea for me to use indiscriminatel y. The
only reason I can see for using them is instant gratification for the
user (a good reason BTW).


I'd be interested in hearing your arguments for using unbound forms other
than maybe reduced network traffic depending on your implementation
methods. That can also be managed using bound forms.


Nov 13 '05 #8
la**********@nt pcug.org (Larry Linson) wrote in
news:fc******** *************** ***@posting.goo gle.com:
ja******@oaklan d.edu (James Fortune) wrote

. . . but I don't understand why people who
know how to write code to completely replace
a front end do not write something that will
automate the code that implements managing
unbound controls on forms given the superior
performance of unbound controls in a client/
server environment.
What "superior performance" would that be, James? The vast
majority of my paying Access work has been Access clients to
server databases, using MDB-Jet-ODBC-serverDB, . . .


All my work has been Access to Jet, with no actual client/server
projects for any of my clients.

Nonetheless, I agree with Larry when he says:
. . . with the vast
majority of the forms bound, and users perfectly happy with
performance. My only observation of "superior performance" has
been reports of people who were pushing the envelope on Access-Jet
multiuser, not client-server. And, even so, there seem to be
equally many reports of satisfactory multiuser performance with
bound forms.
If you create bound forms the way the Access examples and the
wizards encourage you, they'll be terrible in a client/server
environment.

But that's not what anyone who's been calling for the limited use of
unbound forms has suggested. Even with a Jet back end, using what
Larry and I have taking to sometimes calling "semi-bound" forms
(i.e., the form is unbound to a recordsource, but at runtime the
user chooses which record or small group of records to load, and the
recordsource is then assigned, with the controls bound to the fields
in the recordsource), performance and efficiency is vastly improved.
I can easily understand a newbie using
bound controls or someone with a
tight deadline.


Strange, the first is the same argument I use about unbound forms
-- newbies who haven't invested the time and effort to learn how
Access works and to work _with_ it often have to resort to unbound
forms and code to accomplish what they want to do. The more
experienced developers know how to work with Access, and get the
functionality they need from bound forms for data handling. Of
course, unbound forms for splash screens, switchboards, and user
selection of criteria for reports and forms make sense.


If you don't want bound controls, then don't use Access. Why?
Because there simply isn't any point in using Access if you aren't
going to use the one feature it has that makes it vastly easier to
use than all other development environments.

Furthermore, if bound controls were such a bad thing, why is it that
this is one of the main features VB developers have been calling for
over the last few years (and been partially delivered), such as
bound data grids and the like? If it were such a bad thing, then
those developers wouldn't need it and MS wouldn't be expending so
much effort incorporating it into their latest developer tools.
I guess I need to hear a better argument
against unbound forms than more coding is
required.


I have not observed the performance improvement you describe, but
the consensus is that using unbound forms does take more time and
effort to implement. And, clearly, not only is "more coding
required", but you are reimplementing functionality that is
included with bound forms, has been proven/tested by millions of
users for over ten years, and is maintained by someone else (as
part of the price of the Access product). It's hard to get that
kind of "test group" for your re-invented code.


It's easy to populate and save records in unbound forms.

It's harder to give up some of the events you get with bound founds,
though. No OnCurrent when you load the record, so you have to write
something to replace it. No Me.Dirty, so you have to check all the
fields against the original. No .Refresh or .Requery, just
re-running the same code you used to load the original record.

The lack of Me.Dirty is a real problem if, for instance, you are
editing a record in an unbound subform and you don't want focus to
be lost without a save. You've got to then use the subform control's
..Exit event to check if the unbound record has been dirtied and
needs to be saved. This means running code to check the current
values in the unbound form against the values you originally loaded
(.OldValue works only when a control has the focus, and won't help
if a value has been changed to something that a comparison of
control values and saved values won't see, such as changing "fenton"
to "Fenton" -- yes you can write code to compare case, but with
Me.Dirty, you don't need it).

Yes, I've written code that works around all of these problems, but
it's often quite specific to the particular application, and I've
not see it worth the enormous time it would take to generalize it
and debug it to make it work in any unbound form. Maybe if I had
that time and energy, I'd use unbound forms more often, but the
problems with bound forms are simply not enough to justify they use
of unbound forms in my applications except in the rarest of
circumstances (keep in mind that I'm only talking about unbound data
editing forms here -- I use tons of unbound forms for other
purposes).
Of course, if you can get away with using
bound forms it's simpler to use them.


Of course, it's simpler to use them... there is rich data-event
model to make it so. That rich data-event model, contrasted with
the less data-oriented event model of classic VB (which does not
nearly so well lend itself to bound controls -- it has no bound
_forms_) is why people experienced in both tend to work in Access.
They usually say they see no less than a 3X greater time and
effort to do the same app in VB. But I don't see what you mean by
"get away with"; as I said, in the last 5 of my more than 10 years
doing Access, the only unbound forms I create are splash,
switchboard, and selection.


It seems to me that the problems people have with bound forms in a
C/S environment come from mis-using the default Access behaviors
when you should be doing other things with your forms in that
environment.
I only reinvent the wheel when the new
wheel is better :-).


My clients don't want, and will not, pay for "reinventin g wheels",
even if some minimal/marginal performance improvement can be
shown.


And in my experience, the new wheel is *not* better, except for a
small number of cases where concurrency problems are very evident.
This means high volume of adds/edits on a small group of tables.
I don't think that having the option to
use bound forms is a bad idea. It's just
not a good enough idea for me to use
indiscriminatel y.


IMNSHO, you can replace "bound" with "unbound" and
"indiscriminate ly" with "for handling data" in the quoted
paragraph.


The problem with bound forms is not with the way they work, but with
users not understanding that they can't work magic and that
sometimes you have work round them. That has given them a bad
reputation in certain circles, so, instead of learning how to use
bound forms in a C/S environment, those advanced users throw the
baby out with the bathwater and make for themselves vastly more work
than is necessary.
The only reason I can see for using
them is instant gratification for the
user (a good reason BTW).


The only reason I can see for using unbound forms are for features
that do not require accessing data and, if the developer hasn't
invested the time and effort to work with bound forms and make
them do what he needs. Others whose opinions I respect differ with
me on this issue.


I use unbound forms for data editing in a small number of
circumstances where volume was such that concurrency problems
emerged. Using unbound forms to edit eliminated the problems.
My clients have been very happy with the bound forms I use, the
efficient development and lower cost, and with the performance.
Depending on your grokking "the Access way", YMMV.


If you don't want to do it the Access way, I wonder why you use
Access at all.

[in case anyone's wondering, my 3-week absence from the newsgroup
was due to a vacation in California]

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #9
ja******@oaklan d.edu (James Fortune) wrote in
news:a6******** *************** ***@posting.goo gle.com:
la**********@nt pcug.org (Larry Linson) wrote in message
news:<fc******* *************** ****@posting.go ogle.com>...
ja******@oaklan d.edu (James Fortune) wrote

> . . . but I don't understand why people who
> know how to write code to completely replace
> a front end do not write something that will
> automate the code that implements managing
> unbound controls on forms given the superior
> performance of unbound controls in a client/
> server environment.
What "superior performance" would that be, James? The vast
majority of my paying Access work has been Access clients to
server databases, using MDB-Jet-ODBC-serverDB, with the vast
majority of the forms bound, and users perfectly happy with
performance. My only observation of "superior performance" has
been reports of people who were pushing the envelope on
Access-Jet multiuser, not client-server. And, even so, there seem
to be equally many reports of satisfactory multiuser performance
with bound forms.


I used the words client-server to indicate Access-Jet multiuser,


Er, that's not client/server, by any accepted definition.
not the ODBC situation you describe. And you are correct that
even in this situation most customers find bound forms adequate.
Most people in *all* circumstances will find bound forms more than
adequate.
> I can easily understand a newbie using
> bound controls or someone with a
> tight deadline.


Strange, the first is the same argument I use about unbound forms
-- newbies who haven't invested the time and effort to learn how
Access works and to work _with_ it often have to resort to
unbound forms and code to accomplish what they want to do. The
more experienced developers know how to work with Access, and get
the functionality they need from bound forms for data handling.
Of course, unbound forms for splash screens, switchboards, and
user selection of criteria for reports and forms make sense.


I see very little extra functionality in using bound forms over
unbound. There's just not that much difference.


Then you really don't know much about one side of the equation.
Either you've never used bound forms for anything complex, or you've
never tried to do anything mildly complicated with an unbound form.
> I guess I need to hear a better argument
> against unbound forms than more coding is
> required.


I have not observed the performance improvement you describe, but
the consensus is that using unbound forms does take more time and
effort to implement. And, clearly, not only is "more coding
required", but you are reimplementing functionality that is
included with bound forms, has been proven/tested by millions of
users for over ten years, and is maintained by someone else (as
part of the price of the Access product). It's hard to get that
kind of "test group" for your re-invented code.


The only reinvented code is putting the data on the form and
saving it. . . .


Aha. You reveal your vast ignorance of unbound forms. You've
obviously never actually programmed one for use in an actual Access
application.
. . . How hard is that? How big of a "test group" do I need
to make sure that works?
That part is not hard at all. In fact, if you name the controls with
the names of the fields (easy enough to do by starting out with the
form bound to your intended recordsource, dropping the controls on
the form, then removing the recordsource and the controlsources for
the controls; then in your code to load the record, simply use a
FOR/EACH loop through the fields of the recordsource to populate the
fields), it's a piece of cake, and takes only few lines of code:

Dim db As DAO.Database
Dim strSQL As String
Dim rs As DAO.Recordset
Dim fld As Field

Set db = CurrentDB()
strSQL = [SQL for your recordsource, only the fields with controls]
Set rs = db.OpenRecordse t(strSQL)
If rs.RecordCount >0 Then
For Each fld In rs.Fields
Me(fld.Name) = fld.Value
Next fld
End If

To save, you do the same thing, but this time compare the values of
the controls to the fields, and if they've changed, update them.

Dim strField As String
Dim ysnUpdate As Boolean

If rs.RecordCount >0 Then
For Each fld In rs.Fields
strField = fld.Name
If Nz(Me(strField) .Value) <> Nz(fld.Value) Then
If Not ysnUpdate Then rs.Edit
fld = Me(strField)
End If
Next fld
If ysnUpdate Then rs.Update
End If

It's up to you whether or not you retrieve the record a second time
when you save, or maintain the original recordset in memory for
comparison at SAVE time. The difference is whether or not you want
to tell the end user if another user has changed the record or not.
If you re-retrieve the record, you can't tell if your current user
will be overwriting changes made to the record since it was
retrieved. So, you either ignore that and let the user silently
overwrite other users' changes, or you have to write still more code
to handle what the Access bound form handles by default.

Then, of course, there are all the events that come with bound
records, OnCurrent, Before/AfterUpdate, and so forth, as well as
important form properties like .Dirty that you don't have. I've
described in another post exactly when this last one is a problem
and how you work around it.

But now we're talking about a huge amount of code, to replace the
features provided by default by bound forms.

By reducing the problem to the mere issue of loading and saving data
(and even in the latter, skating over the huge problems involved
there), you're missing 99% of the work of creating unbound forms.

And that suggests to me that you simply have done much with unbound
forms.

Or, that you have a completely unprofessional attitude about what is
acceptable in an end-user application.

[]
> I don't think that having the option to
> use bound forms is a bad idea. It's just
> not a good enough idea for me to use
> indiscriminatel y.


IMNSHO, you can replace "bound" with "unbound" and
"indiscriminate ly" with "for handling data" in the quoted
paragraph.


You should try it and compare your network traffic. My clients
don't want, and will not pay, for techniques that cause them to
have to spend unnecessary money on their (Jet accessed) network
because it keeps records locked too long and slows down the
network.


Then you simply aren't using bound forms correctly.

So, not only are you really not very experienced with unbound forms,
you don't seem to have the experience to criticize bound forms,
because you obviously haven't used them enough top know how to use
them efficiently.
> The only reason I can see for using
> them is instant gratification for the
> user (a good reason BTW).


The only reason I can see for using unbound forms are for
features that do not require accessing data and, if the developer
hasn't invested the time and effort to work with bound forms and
make them do what he needs. Others whose opinions I respect
differ with me on this issue.


I've used both and like unbound. . . .


It doesn't sound to me like you've used either of them in any very
complex situations. Otherwise, you would have run into all the
problems one will necessarily encounter with unbound forms because
of the loss of the default record-level events and .Dirty (not to
mention the issue of reconciling changes from multiple users).
. . . Maybe you've used both and
prefer bound. I see nothing wrong with that. If you don't like
unbound forms you don't need to use them.


Your original scenario seems to me to assume that the only "hard
part" to using unbound forms is loading and saving the data. If
that's your take on it, then you simply aren't experienced enough to
understand the issues that lead Larry and me to use bound forms as
preferable to unbound.

Now, there's nothing wrong with that. There was a time once when I
though the default NotInList behavior of combo boxes was criminally
minimal. Experience has taught me that Microsoft made the right
choice, after all.

But at a certain level of knowledge and experience, it seemed
completely wrong to me.
My clients have been very happy with the bound forms I use, the
efficient development and lower cost, and with the performance.
Depending on your grokking "the Access way", YMMV.


I've had good success with my "grokking." It takes very little
extra time and seems to keep clients happy, except for that extra
click it takes to submit the changes. Maybe if you enumerated
exactly what is really gained by using bound forms I would be more
inclined to use them. Keep in mind that unbound forms also take
advantage of Access' richness so be sure to not to include those.


If your unbound forms "take very little extra time" then either
you're a genius or you're providing substandard applications to your
clients.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

220
19047
by: Brandon J. Van Every | last post by:
What's better about Ruby than Python? I'm sure there's something. What is it? This is not a troll. I'm language shopping and I want people's answers. I don't know beans about Ruby or have any preconceived ideas about it. I have noticed, however, that every programmer I talk to who's aware of Python is also talking about Ruby. So it seems that Ruby has the potential to compete with and displace Python. I'm curious on what basis it...
37
17069
by: Grzegorz Staniak | last post by:
Hello, I'm a newbie Python user, a systems administrator - I've been trying to switch from Perl to Python for administrative tasks - and one thing I cannot understand so far is why I need the special 'self' (or anything esle) argument in class method definitions. I might have missed an explanation in the docs, a quick Google search did not help. Is there somewhere on the web you could direct me to? Thanks,
4
3051
by: David W. Fenton | last post by:
I'm working on a subform where users put in 24-hour time. On their paper forms, they've been accustomed to referring to midnight as 24:00 (instead of as 0:00, which kind of makes sense from a human point of view, though it's still wrong, as it puts midnight as the end of the previous day instead of the beginning of the next, but it avoids the zero time problem). I have an input mask to put the : in the time, but when you input 24:00, it...
2
1994
by: CSDunn | last post by:
Hello, I need some assistance with error handling in an Access 2003 Project form. The project is has a data source connection to a SQL Server 2000 database. The main form is named ‘frmSelectByTest', and its subform's ‘Name' and ‘Source Object' properties are ‘frmSelectByTestSub'. The ‘Default View' on the main form is ‘Single Form', and on the sub form is ‘Continuous Forms'. The users select the name of a test (uniquely identified by a...
2
1824
by: Lyn | last post by:
Hi, I am struggling to display photographs in a list format. Any help will be greatly appreciated. Originally I had attempted to store photographs as embedded OLE Objects, but had lots of trouble. I eventually abandoned this on advice from this group that this format was not reliable, not to mention that it bloated the database. Since then I have successfully been able to manage individual photographs
0
3499
by: Dave | last post by:
Tried posting in the Winform Forum without much luck, so posting here... After inserting a new data row to a DataTable that is bound to a datagrid, I am unable to change data in a row that is after the newly added row without getting bizarre results. I have added the full code for the test below. Create a project drop in the code and run. There is nothing crazy about the code. I used the designer to add the dataset and to do the...
11
2016
by: vbgunz | last post by:
Hello all, I am just learning Python and have come across something I feel might be a bug. Please enlightenment me... The following code presents a challenge. How in the world do you provide an argument for *arg4? ## ============================================================ def argPrecedence(par1, par2=0, par3=0, *par4, **par5): print 'par1 =', par1, ' # positional argument' print 'par2 =', par2, ' # keyword argument'
6
1330
by: Beemer Biker | last post by:
I have a C# project VS2005, that uses GridView and Multiview. It is getting bigger then I originally anticipated and running slow and needs to be broken up into several pages (yes, I am a newbie and made it one page) It has been decided to use pintab instead of multiview. I downloaded pintab and it has more vb examples than c#. It is not too late to start over in VB if I wanted to. I googled around and found this discussion about...
7
3321
by: Dave | last post by:
Hello All, These one may be a bit tricky, and what I'd like to do may not even be possible. I would love to hear any ideas you guys have for solving this. Here is the situation: I have a form that displays the high-level data for a set of records in continuous forms mode. I have a simple command button that will open another form with the details of the selected record.
0
8759
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9251
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
8963
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
7872
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
6588
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5922
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4433
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
4687
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
2453
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.