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 indiscriminately. The
only reason I can see for using them is instant gratification for the
user (a good reason BTW).
James A. Fortune
19  3977 
On 12 Aug 2004 12:38:19 -0700, ja******@oakland.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 indiscriminately. The
only reason I can see for using them is instant gratification for the
user (a good reason BTW).
James A. Fortune
On 12 Aug 2004 12:38:19 -0700, ja******@oakland.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 indiscriminately. 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 d.***************@blueyonder.co.uk (David Schofield) wrote in message news:<411c7b7a.162485181@localhost>... 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
On 13 Aug 2004 15:18:58 -0700, ja******@oakland.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! ja******@oakland.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 "reinventing 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
indiscriminately.
IMNSHO, you can replace "bound" with "unbound" and "indiscriminately"
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 la**********@ntpcug.org (Larry Linson) wrote in message news:<fc**************************@posting.google. com>... ja******@oakland.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 "reinventing 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
> indiscriminately.
IMNSHO, you can replace "bound" with "unbound" and "indiscriminately"
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
"James Fortune" <ja******@oakland.edu> wrote in message
news:a6**************************@posting.google.c om... 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 indiscriminately. 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. la**********@ntpcug.org (Larry Linson) wrote in
news:fc**************************@posting.google.c om: ja******@oakland.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 "reinventing 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
indiscriminately.
IMNSHO, you can replace "bound" with "unbound" and
"indiscriminately" 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 ja******@oakland.edu (James Fortune) wrote in
news:a6**************************@posting.google.c om: la**********@ntpcug.org (Larry Linson) wrote in message
news:<fc**************************@posting.google. com>... ja******@oakland.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.OpenRecordset(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
> indiscriminately.
IMNSHO, you can replace "bound" with "unbound" and
"indiscriminately" 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
"David W. Fenton" <dX********@bway.net.invalid> wrote in message news:<Xn**********************************@24.168. 128.74>... la**********@ntpcug.org (Larry Linson) wrote in
news:fc**************************@posting.google.c om:
ja******@oakland.edu (James Fortune) wrote If you create bound forms the way the Access examples and the
wizards encourage you, they'll be terrible in a client/server
environment.
As most of you have seen by now, I'm not very likely to do something
the way the wizards suggest. I was not even considering this case.
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.
This is the case I was referring to. I do it that way sometimes.
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.
I think Access has a lot more going for it than bound controls. Do
you really think I should abandon Access because it has this extra
feature?
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 didn't say bound controls were a bad thing. I didn't say unbound
forms were the only thing. Bound data grids would be great. I had to
pay a third party for one in my last commercial app. If developers
are calling for them then MS should certainly put more effort into
incorporating them. I realize that it took MS a lot of work to create
bound form capability. I appreciate having that capability, but not
as much as many other developers.
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.
This is the first decent reason someone has given for using bound
forms. I've never had to use OnCurrent on a main form, but I use it
often on subforms. Of course if you are using an unbound form for a
multi-record situation the user has to click your arrows to move to
the previous or next record and you'll know when the equivalent of
OnCurrent happens.
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).
What's wrong with calling the save routine and saving what's there
whether it changed or not?
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).
I accept that. You weighed the choices and made a decision.
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.
Perhaps. Since using a lot of unbound forms the problems I've
encountered have been almost non-existant. But even the problems
encountered using bound forms weren't serious.
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 think the developer should decide if she thinks concurrency will be
an issue and program accordingly.
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.
I'd like to think that I understand how bound forms work and that I am
capable of deciding when to use them.
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.
Then our opinions are not very different.
If you don't want to do it the Access way, I wonder why you use
Access at all.
It's because Access is the best RAD tool available by far, even if it
didn't have bound form capability.
James A. Fortune
Just to add my 2 cents...
On 12 Aug 2004 12:38:19 -0700, ja******@oakland.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
Well, partly because, as others have pointed out, there is no real performance
advantage to unbound forms in most cases. Also, Access was designed with
bound forms as a central feature and works best with them. You cannot have,
for instance, an unbound continuous form. I for one, find Access continuous
forms to be a very nice feature, and I use them a lot.
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 indiscriminately. The
only reason I can see for using them is instant gratification for the
user (a good reason BTW).
The reason I don't like bound forms is not for the reasons you suggest, but
because they tighly couple the UI to the data structures. This can handcuff
the developer during the UI design process, and it means there's no where to
put a business rule except in the database rules (which are fairly limited) or
in the forms themselves (which are often duplicated. If you need a business
logic layer (and most larger apps start to need them), then Access bound forms
can definitely start to get in the way.
Fortunately, except for the continuous subforms (and of course, I feel that's
a big exception), it's pretty easy to switch a from from bound to unbound at
the time the need arises, and not have to worry about it prior to that time.
Pragmatic laziness is a good thing.
"David W. Fenton" <dX********@bway.net.invalid> wrote in message news:<Xn**********************************@24.168. 128.78>... ja******@oakland.edu (James Fortune) wrote in
news:a6**************************@posting.google.c om:
la**********@ntpcug.org (Larry Linson) wrote in message
news:<fc**************************@posting.google. com>... ja******@oakland.edu (James Fortune) wrote Er, that's not client/server, by any accepted definition.
My fault here. It was a bad choice of words.
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.
Most people don't consider getting an error lock message a problem.
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.
Maybe I've never done anything complex in Access. I'll give you that
one :-).
Aha. You reveal your vast ignorance of unbound forms. You've
obviously never actually programmed one for use in an actual Access
application.
I don't see your point yet.
. . . 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:
I think that was my point. The other situations are pretty easy also.
Perhaps I am overlooking something.
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.
O.K., I see what you're getting at. I have to have code that lets a
user know if the record is occupied or roll my own synchronization
scheme. I don't let two users edit the same record at the same time.
If two users need to edit the same record at the exact same time then
bound forms would be a much easier way to go unless you are running a
version of Access that locks the record anyway.
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.
Before/AfterUpdate events are available on unbound forms also.
But now we're talking about a huge amount of code, to replace the
features provided by default by bound forms.
I'm not trying to reproduce all the functionality of bound forms. I
think this discussion is good for pointing out the issues though.
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.
Yes. I don't use all the features that bound forms have. That would
be too much work.
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.
Neither, I hope.
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.
At the moment I don't feel like diving into the synchronization code
scenario. So if you mean handling multiple users on the same record
as using bound forms efficiently then bound forms are definitely a
winner there. I did read the whitepaper on replicated databases. Any
synchronization method will cause problems.
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).
Those are complex situations. But I have even rolled my own
synchronization methods in the past and it wasn't fun. It's not that
I haven't done it.
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.
I understand the issues better now.
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.
I appreciate bound forms better now, but I reserve the right to use
unbound forms for my not-as-complex multiuser situations. I feel a
little slighted here, though.
If your unbound forms "take very little extra time" then either
you're a genius or you're providing substandard applications to your
clients.
They're only substandard if two people need to edit the record at the
same time :-). Take it easy. I listen to reason. I'm starting to
understand your devotion to bound forms. Let that blood pressure
fall.
James A. Fortune ja******@oakland.edu (James Fortune) wrote in
news:a6**************************@posting.google.c om: "David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:<Xn**********************************@24.168. 128.74>... la**********@ntpcug.org (Larry Linson) wrote in
news:fc**************************@posting.google.c om:
> ja******@oakland.edu (James Fortune) wrote If you create bound forms the way the Access examples and the
wizards encourage you, they'll be terrible in a client/server
environment.
As most of you have seen by now, I'm not very likely to do
something the way the wizards suggest. I was not even considering
this case.
My point is that many people derive their understanding of how
Access should be used by looking at the sample databases and the way
the wizards do things. This is very misleading as those often
represent less than best practices, especially for multiuser
circumstances, and even moreso for client/server environments.
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.
This is the case I was referring to. I do it that way sometimes.
I don't see why this shouldn't be everyone's default approach.
Loading an entire table really makes no sense from either an
end-user point of view (no one can really deal with 1,000s of
records at one time, so why load them?) or from a performance point
of view.
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.
I think Access has a lot more going for it than bound controls.
Do you really think I should abandon Access because it has this
extra feature?
Other than the report writer (which I actually think has more flaws
than we usually acknowledge, but it's one of those case where those
flaws are not even close to being as bad as those of competition), I
don't see how Access is really superior as a RAD tool if you tend to
avoid using bound forms. If you're writing all your own data
retrieval and saving routines, then you might as well choose a
development environment that has less baggage attached to it in
other areas.
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 didn't say bound controls were a bad thing. . . .
Then why do you avoid them?
. . . I didn't say
unbound forms were the only thing. Bound data grids would be
great. . . .
Access has always had them. Which was why Access was so much easier
to do things quickly in.
. . . I had to pay a third party for one in my last commercial
app. If developers are calling for them then MS should certainly
put more effort into incorporating them. I realize that it took
MS a lot of work to create bound form capability. I appreciate
having that capability, but not as much as many other developers.
Well, since in Access, there's no such thing as an unbound
continuous form, it's kind of a moot point.
But, nonetheless, I think the whole point of Access is the close
coordination between its forms and the data bound to them. The event
model for the forms and controls are all built around the assumption
that the form and controls are bound, and when you unbind them, you
lose a great deal of the power of the Access event model.
And it's that event model that makes Access superior as a RAD tool.
If you can't use 2/3s of it, there's not much point, in my opinion. 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.
This is the first decent reason someone has given for using bound
forms. I've never had to use OnCurrent on a main form, but I use
it often on subforms. Of course if you are using an unbound form
for a multi-record situation the user has to click your arrows to
move to the previous or next record and you'll know when the
equivalent of OnCurrent happens.
Well, there are lots more data events than that, some of which can
be replicated with code behind navigation buttons, but not all of
it. 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).
What's wrong with calling the save routine and saving what's there
whether it changed or not?
Because that requires a hit on the back end.
This can result in unnecessary write conflicts with other users.
In replicated Jet back ends, it can also cause problems because Jet
replication uses the "most often changed" record/field as the
winner. Jet doesn't know the difference between a save that is
identical and one that is not, so you could end up with a case where
an older record beats a newer one in a conflict situation.
Last of all, I'm philosophically opposed to saving a record when it
doesn't need to be saved. One of the key reasons for using unbound
forms is to avoid just such problems (it's sometimes complicated to
control when records get saved/written in bound forms). Always
writing the data is subverting one of the chief advantages of using
an unbound form.
And it also can lead to user confusion. If a user thinks that just
leaving the record without hitting the SAVE button will cause it to
be abandoned, but you just save it by default, they could end up
with records they don't intend.
So, in my opinion, you'd need a confirmation message, in any event.
And for that to not be computer-stupid (i.e., if the user really
hasn't made any changes, the computer shouldn't ask if the user
wants to save changes), you'd have to check the data, anyway.
Short of applying an AfterUpdate event to every control on the form
that sets a flag to replace Me.Dirty (you could certainly create a
custom form property for that purpose if you wanted to), you would
still need to check the data in the unbound form against some
version of the original record (and as I've written elsewhere, you
have to choose which version you use, the original or the current
one; choosing the latter could lead to data loss and user confusion,
too).
Ignoring all these issues would indicate to me that the designer of
the application has no appreciation for data integrity and UI
design. Forcing a save without a confirm could be a terrible choice
from a data integrity point of view (what if the user doesn't intend
the change to be saved). Confirming without knowing if there's been
a change from original values could lead to confirmations that don't
represent reality from the point of view of the user.
Me.Dirty avoids all of those issues except the simple one of
changing a value to something equivalent to the original value.
Not having Me.Dirty available in unbound forms means you have to
write a whole lot of code and make a lot of decisions about how the
app should behave given a number of different choices. 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).
I accept that. You weighed the choices and made a decision.
Well, you don't seem to accept my overall conclusion, that the cases
in which unbound forms are justified are actually relatively few.
Keep in mind that this assertion applies only for data editing. For
adding new records, I almost always use an unbound form that
collects only the required fields, and then load the new record into
a bound form for completion. I also use tons of unbound forms as
dialog forms. 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.
Perhaps. Since using a lot of unbound forms the problems I've
encountered have been almost non-existant. But even the problems
encountered using bound forms weren't serious.
It seems to me, though, that you are ignoring a whole host of issues
that arise from using unbound forms, and it's only because of this
oversight on your part that you can conclude that unbound forms
should be more popular than they are. 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 think the developer should decide if she thinks concurrency will
be an issue and program accordingly.
Well, one would assume that concurrency will not be, and unbind when
it is a problem. Unbinding a form on the assumption that it will be
a problem is foolish, in my opinion, as you end up doing a lot of
work that may ultimately not have been necessary.
Actually, there's one other case in which I've used a form of
unbound forms for editing. That's when I had an app with a number of
tables with many columns that were only very seldom going to be
edited after they were created. The record creation forms were
completely unbound (the app was going to have a significant number
of simultaneous users; the client actually abandoned it before it
was finished because of a change of management), and did not include
all the tables in the full record (half the data was imported from
an external source), so they weren't candidates for repurposing as
data editing forms. So, I mapped out the table structures in some
metadata tables, and used those to populate a listbox from a
function, with each row of the listbox representing a field of a
table. Then I allowed that data to be edited in controls at the top
of the listbox. This was complex to set up, but actually allowed for
a large number of fields and tables to be edited in a single UI --
the hard part was actually creating the metadata to make the listbox
user-friendly (i.e., supplying user-friendly field names since I had
no labels). To create the forms for this would have been a huge
task, so I was happy with the unbound result. 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.
I'd like to think that I understand how bound forms work and that
I am capable of deciding when to use them.
It seems to me that you have not thought through a whole host of
issues that one should be encountering immediately upon first using
an unbound form for data editing, which suggests to me that your
experience either with unbound forms or with database applications
is rather slight. 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.
Then our opinions are not very different.
I've done that about 4 times since starting programming in Access in
early 1996. I've got 20 or 30 major applications under my belt
during that time period.
I think our opinions *do* differ. You seem to think unbinding a form
is as simply as loading and saving the data. It's not. I've
delineated a long list of issues that make unbound forms vastly more
complex to program and maintain that bound forms. And that extra
work is only worth it when the benefit of being unbound (in terms of
raising the concurrency ceiling) can only be acquired through going
unbound. In the vast majority of cases, the problems can be avoided
simply by loading the minimum number of records (one or a small
group of records).
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc ja******@oakland.edu (James Fortune) wrote in
news:a6*************************@posting.google.co m: "David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:<Xn**********************************@24.168. 128.78>... ja******@oakland.edu (James Fortune) wrote in
news:a6**************************@posting.google.c om:
> la**********@ntpcug.org (Larry Linson) wrote in message
> news:<fc**************************@posting.google. com>...
>> ja******@oakland.edu (James Fortune) wrote
[]
> . . . 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:
I think that was my point. The other situations are pretty easy
also.
Perhaps I am overlooking something.
I think you vastly underrate the importance of "everything else,"
outside of loading and saving.
And from what you've written, it seems clear to me that you haven't
even really considered the full complexity of the process of saving
a record in the first place.
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.
O.K., I see what you're getting at. I have to have code that lets
a user know if the record is occupied or roll my own
synchronization scheme. I don't let two users edit the same
record at the same time. If two users need to edit the same record
at the exact same time then bound forms would be a much easier way
to go unless you are running a version of Access that locks the
record anyway.
How do you accomplish this? By having a LOCKED flag? That means more
hits on the back end, which means you're increasing the number of
hits on the back end to write the flag field, and potentially ending
up with records marked LOCKED that really shouldn't be marked that
way.
Either that or you're using pessimistic locking of some sort (not
sure if you can lock a record when retrieving it in a recordset?),
and then you're lowering your concurrency ceiling even more.
Why worry about all of these things?
Simply bind your forms and deal with edit collisions as they arise
(using the form's OnError event).
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.
Before/AfterUpdate events are available on unbound forms also.
In controls, yes. At the form level, no. There are also the
Before/AfterInsert events, for instance, among others.
But now we're talking about a huge amount of code, to replace the
features provided by default by bound forms.
I'm not trying to reproduce all the functionality of bound forms.
I think this discussion is good for pointing out the issues
though.
If you need the functionality, then you've got to replicate it if
you go unbound.
I have found that in nearly every case that I've gone unbound I
definitely needed to re-invent several wheels to get a small
fraction of the functionality provided by default in 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.
Yes. I don't use all the features that bound forms have. That
would be too much work.
I don't understand how you can object at the beginning of this
message to getting error lock messages and then apparently see my
discussion of checking the state of the record at save time as a new
issue.
This subject is absolutely fundamental to all database applications.
Bound forms provide an interface for dealing with them (optimistic
locking takes care of most of it -- I discovered early on that my
assumption that pessimistic locking was safer was a huge mistake),
however confusing that UI may be (and you can replace it in the
Form's OnError event, if you like). If you unbind your forms, you've
got to replicate that functionality somehow, or your users will be
overwriting data that might be important.
That you seem not to have considered these issues suggests to me
that you are a rather casual database application developer.
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.
Neither, I hope.
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.
At the moment I don't feel like diving into the synchronization
code scenario. So if you mean handling multiple users on the same
record as using bound forms efficiently then bound forms are
definitely a winner there. I did read the whitepaper on
replicated databases. Any synchronization method will cause
problems.
Eh? I wasn't speaking of replication above (I have addressed that in
my reply to your other message).
Writing unbound forms and blithely saving all the user's changes
without knowing whether or not the record has been updated by
another user is bad design.
If you're truly locking the records somehow (a LOCKED flag?), then
you're causing more locks on the database by either applying a lock
of some kind or by updating the record in some way to indicate that
it is locked.
Again, you're creating whole subsystems (unreliable ones, BTW) to
replicate functionality that you get by default with a bound form.
And you seem to me from what you've said to be doing it in ways that
are substantially inferior to the default bound behaviors, since
you've sacrificed a whole lot of areas of user control or you're
causing far more hits on the back end. Either way, you're rather
subverting your purpose -- to increase the reliability and speed of
your application.
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).
Those are complex situations. But I have even rolled my own
synchronization methods in the past and it wasn't fun. It's not
that I haven't done it.
Then you obviously don't consider it important.
Which is a pretty damning admission right there, in my opinion.
[]
If your unbound forms "take very little extra time" then either
you're a genius or you're providing substandard applications to
your clients.
They're only substandard if two people need to edit the record at
the same time :-). . . .
If this happens even one time, you're data is hosed -- not because
the data may be jumbled, but because you can't really know for sure
if the intended updates were made in the correct order or not. You
can no longer rely on the data as it is stored in your data tables
as representing the intentions of the people who edited that data.
That's one definition of data corruption, in my book.
. . . Take it easy. I listen to reason. I'm
starting to understand your devotion to bound forms. Let that
blood pressure fall.
I'm not excited. I'm simply pointing out that you don't seem to me
to know as much as you think, and that the adamant nature of your
original challenge was not really justified.
And this isn't the first time in this forum that I've gone through
these issues regarding unbound forms.
Perhaps it all needed restating, so I hope my comments have been
helpful.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"David W. Fenton" <dX********@bway.net.invalid> wrote in message news:<Xn**********************************@24.168. 128.74>... ja******@oakland.edu (James Fortune) wrote in
news:a6*************************@posting.google.co m:
I admit that I'm not as hard-core as you. Few people are.
Syncronization is the issue with unbound forms. What I did basically
eliminated concurrency. You were correct to object to that. So I
guess professionals do more reinventing when using unbound forms.
I'll follow up this post with more about your objections later. I
have only been following this NG for several months and probably
missed the details of your reasoning. I also admit I'm not always
smart enough to come to the conclusions MS has made so convenient to
reach. Anyway, I appreciate your insight and am learning to be less
casual.
James A. Fortune
"David W. Fenton" <dX********@bway.net.invalid> wrote in message news:<Xn**********************************@24.168. 128.74>... ja******@oakland.edu (James Fortune) wrote in
news:a6*************************@posting.google.co m:
What we've discovered so far is that for accessing data using Jet the
key issue is synchronization. You've proven that for cases where no
synchronization is needed such as when only one person is editing a
table at a time that it's not hard to program an unbound form to keep
Access from holding the table open. I've agreed that for situations
where intensive synchronization in needed that MS has done just about
as good as can be done with this difficult problem and that bound
forms should be used. We're getting ready to look at situations that
fall between these two extremes. It may turn out that bound forms
will be the best answer to those cases, but that's what we're about to
look at. If this is not the situation as you see it then let me know.
James A. Fortune
Steve Jorgensen <no****@nospam.nospam> wrote The reason I don't like bound forms is not
for the reasons you suggest, but because
they tighly couple the UI to the data structures.
This can handcuff the developer during the UI
design process, and it means there's no where to
put a business rule except in the database rules
(which are fairly limited) or in the forms
themselves (which are often duplicated. If you
need a business logic layer (and most larger
apps start to need them), then Access bound forms
can definitely start to get in the way.
Access is an excellent front-end and development tool for two-tier
applications, which is what most individual, multiuser, and straight
client-server applications, in fact, are (and should be). I've worked
on some fairly large straight client-server applications that didn't
suffer for the lack of a business rules layer.
If you are aiming for an enterprise, distributed, intergalactic
application, integrated with all/most other applications in the
enterprise, then a business rules layer, or maybe business rule
processing by web server, would be appropriate. If so, you probably
should not be considering Access, anyway.
"Appropriate technology", you know, is the watchword.
In my view, if you feel forced to unbind more than a tiny fraction of
your data-handling forms, that's probably an indication you either are
missing something or that you've gotten past the limits for the kind
of application that is appropriate for Access.
Larry Linson
Microsoft Access MVP
On 18 Aug 2004 17:37:16 -0700, la**********@ntpcug.org (Larry Linson) wrote: Steve Jorgensen <no****@nospam.nospam> wrote
The reason I don't like bound forms is not
for the reasons you suggest, but because
they tighly couple the UI to the data structures.
This can handcuff the developer during the UI
design process, and it means there's no where to
put a business rule except in the database rules
(which are fairly limited) or in the forms
themselves (which are often duplicated. If you
need a business logic layer (and most larger
apps start to need them), then Access bound forms
can definitely start to get in the way.
Access is an excellent front-end and development tool for two-tier
applications, which is what most individual, multiuser, and straight
client-server applications, in fact, are (and should be). I've worked
on some fairly large straight client-server applications that didn't
suffer for the lack of a business rules layer.
If you are aiming for an enterprise, distributed, intergalactic
application, integrated with all/most other applications in the
enterprise, then a business rules layer, or maybe business rule
processing by web server, would be appropriate. If so, you probably
should not be considering Access, anyway.
"Appropriate technology", you know, is the watchword.
In my view, if you feel forced to unbind more than a tiny fraction of
your data-handling forms, that's probably an indication you either are
missing something or that you've gotten past the limits for the kind
of application that is appropriate for Access.
I agree with that. In most of my apps, a tiny fraction is what actually needs
a separate business logic layer, but it may also be that some other parts of
the application are designed in a more roundabaout way or some desired
fetaures were left out because of the lack of an easy way to implement such a
layer. Although that's annoying, it's true that everything's a trade-off, and
in this case, the up-sides, among other things, are continuous subforms, great
reports, and a nicely integrated system for concurrrent design of database,
GUI, and code.
On 18 Aug 2004 17:37:16 -0700, la**********@ntpcug.org (Larry Linson) wrote: Steve Jorgensen <no****@nospam.nospam> wrote
The reason I don't like bound forms is not
for the reasons you suggest, but because
they tighly couple the UI to the data structures.
This can handcuff the developer during the UI
design process, and it means there's no where to
put a business rule except in the database rules
(which are fairly limited) or in the forms
themselves (which are often duplicated. If you
need a business logic layer (and most larger
apps start to need them), then Access bound forms
can definitely start to get in the way.
Access is an excellent front-end and development tool for two-tier
applications, which is what most individual, multiuser, and straight
client-server applications, in fact, are (and should be). I've worked
on some fairly large straight client-server applications that didn't
suffer for the lack of a business rules layer.
If you are aiming for an enterprise, distributed, intergalactic
application, integrated with all/most other applications in the
enterprise, then a business rules layer, or maybe business rule
processing by web server, would be appropriate. If so, you probably
should not be considering Access, anyway.
"Appropriate technology", you know, is the watchword.
In my view, if you feel forced to unbind more than a tiny fraction of
your data-handling forms, that's probably an indication you either are
missing something or that you've gotten past the limits for the kind
of application that is appropriate for Access.
I guess a succinct way to state my response is - yes, all that, but I still
wish I could have my cake and eat it too.
It would be great if Access were the wonderful 2-tier tool it is, but had
better static checking, and the ability to scale up to a solid 3-tier model
without losing all the cool stuff Access provides. I believe such a beast is
possible, if Microsoft or someone else gets around to creating it. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 2 August 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: erikbower65 |
last post by:
Using CodiumAI's pr-agent is simple and powerful. Follow these steps:
1. Install CodiumAI CLI: Ensure Node.js is installed, then run 'npm install -g codiumai' in the terminal.
2. Connect to...
|
by: linyimin |
last post by:
Spring Startup Analyzer generates an interactive Spring application startup report that lets you understand what contributes to the application startup time and helps to optimize it. Support for...
|
by: kcodez |
last post by:
As a H5 game development enthusiast, I recently wrote a very interesting little game - Toy Claw ((http://claw.kjeek.com/))。Here I will summarize and share the development experience here, and hope it...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Sept 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: Rina0 |
last post by:
I am looking for a Python code to find the longest common subsequence of two strings. I found this blog post that describes the length of longest common subsequence problem and provides a solution in...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: Mushico |
last post by:
How to calculate date of retirement from date of birth
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
| |
