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).
On 12 Aug 2004 12:38:19 -0700, jafor...@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.
>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 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.REMOVEschofi...@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.
On 13 Aug 2004 15:18:58 -0700, jafor...@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!
> . . . 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.
> > . . . 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.
> 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.
> > . . . 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]
>> > . . . 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.
> > jafor...@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.
On 12 Aug 2004 12:38:19 -0700, jafor...@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.
> > 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.
>> > jafor...@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.
>> > . . . 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.
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.
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.
> 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.
> > 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.
> > 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.
