jafortun@oakland.edu (James Fortune) wrote in
news:a6ed3ce7.0408151929.24c2c20b@posting.google.c om:
[color=blue]
> "David W. Fenton" <dXXXfenton@bway.net.invalid> wrote in message
> news:<Xns9546C13C25D48dfentonbwaynetinvali@24.168. 128.74>...[color=green]
>>
larry.linson@ntpcug.org (Larry Linson) wrote in
>> news:fcc4f276.0408141450.68ff9a22@posting.google.c om:
>>[color=darkred]
>> >
jafortun@oakland.edu (James Fortune) wrote[/color]
>> If you create bound forms the way the Access examples and the
>> wizards encourage you, they'll be terrible in a client/server
>> environment.[/color]
>
> 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.[/color]
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.
[color=blue][color=green]
>> 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.[/color]
>
> This is the case I was referring to. I do it that way sometimes.[/color]
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.
[color=blue][color=green]
>> 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.[/color]
>
> 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?[/color]
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.
[color=blue][color=green]
>> 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.[/color]
>
> I didn't say bound controls were a bad thing. . . .[/color]
Then why do you avoid them?
[color=blue]
> . . . I didn't say
> unbound forms were the only thing. Bound data grids would be
> great. . . .[/color]
Access has always had them. Which was why Access was so much easier
to do things quickly in.
[color=blue]
> . . . 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.[/color]
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.
[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]
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.
[color=blue][color=green]
>> 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).[/color]
>
> What's wrong with calling the save routine and saving what's there
> whether it changed or not?[/color]
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.
[color=blue][color=green]
>> 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).[/color]
>
> I accept that. You weighed the choices and made a decision.[/color]
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.
[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]
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.
[color=blue][color=green]
>> 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.[/color]
>
> I think the developer should decide if she thinks concurrency will
> be an issue and program accordingly.[/color]
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.
[color=blue][color=green]
>> 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.[/color]
>
> I'd like to think that I understand how bound forms work and that
> I am capable of deciding when to use them.[/color]
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.
[color=blue][color=green]
>> 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.[/color]
>
> Then our opinions are not very different.[/color]
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 
