Bound or Unbound form. What do you think?

[Aerin]

ineuw (MIS) Aug 9, 2004 wrote:
Unbound forms give greater flexibility for the programmer and the user. In both cases, it's easier to evaluate the data before saving it. I can branch off to numerous public functions to evaluate and calculate prior to saving, without blocking other users' access to the record. With bound forms, I end up doing all data evaluation in the form's BeforeUpdate event and sometimes, that makes for a very long procedure to manage. Unbound also give much greater flexibility in form design and I use pop up forms everywhere except where the number of fields requires a full screen.

----------------------------------------------------

If it is difficult to manage BeforeUpdate event, what about Load and unload events with unbound forms? Also what is faster to load? bound or unbound form? What about going to the next or previous record? delete record? update record? Unbound forms require to code each step, how it impacts the database productivity?

Sometimes blocking is not bad feature, it is helping to manage user's access to the same data.

It will be interesting to know the opinion of different programmers about this question.

Thanks in advance to all responders!

Just remark: our company collected customers (software users) feedback about popup forms. Most of them (about 80%) don't like any pop ups and prefer to have all necessary information on the one screen, pop up warnings is ok.

Best Regards,
Iryna

 

[TheAceMan1]

How are ya Aerin . . . . .

[blue]Unbound forms give [blue]greater [/blue] for the programmer and the user. [/blue]

Unbound forms have their place Access. Usually criteria for search, query, and filter operations. And note: this is a function of unbound forms! Since the advent of any database is the displaying of data from tables in a workable, acceptable, easy to decipher view, I fail to see the [blue]flexibility[/blue] here. Surely no professional in their right mind would use an unbound form to display table data. If they did, they would have to go thru all the rigors of coding data display, navigation, saving, deleting and so on. A very formidable task even for one form, and not to mention the great many hours to achieve what Access already does for you, and in a highly respected manner. So . . . . [blue]I certainly challange this flexibility[/blue], as it has not been proven to me and I doubt it ever will.

[blue]In both cases, [purple]it's easier to evaluate the data[/purple] before saving it.[/blue]

Nonsense! . . . . when we do data evaluation, its does'nt matter if the form is bound/unbound, it still has to be done. Give me any evaluation code and I can set it up in both (and more than likely have to use the same event to trigger)! So whats easier!

[blue]I can branch off to numerous public functions to evaluate and calculate prior to saving, [purple]without blocking other users' access to the record[/purple].[/blue]

This is a plus thats heavily out weighed by the huge amount of programming & time necessary to code the unbound forms. I knew a guy who used unbound because he thought he could get around errors simply by programming everything in VBA. After an approximate six months he had so much code he could'nt tell where one routine started and another ended. If he had a problem . . . . most of the time it took a few days, and thats with the debugger!

[blue]Unbound also give much greater flexibility in form design[/blue]

Nonsense again . . . . I see no greater flexibility in designing a bound form as unbound. I'd like to hear the explanation for this . . . . . I'll bet it full of holes.

[blue]If it is difficult to manage BeforeUpdate event,[/blue]

For a skilled professional, its not difficult to manage any event!

[blue]Also what is faster to load? bound or unbound form?[/blue]

Unbound forms have no RecordSource to load, so they obviously load faster.

All in all, you'll find any skilled professional rarely uses unbound. Again . . . . unbound has its place but its usually infrequent . . . . .

[blue]Cheers![/blue]

See Ya! . . . . . .

 

[Lightning]

The major advantage of an unbound form is that you can use Transactions with an unbound form, which you cannot do with a bound form.

This is a major advantage when you need a process to wholly succeed or wholly fail (for instance, financial entries in a double-entry accounting system). That is, if it succeeds, add everything to the tables. If it fails, discard every change and leave the Db in the same state it was before the process started. See BeginTrans, CommitTrans, Rollback Methods in the on-line help for more info on Transactions and Rollback.

If you don't need this functionality with your forms, in general you should stay with Bound forms rather than use Unbound forms.

The above is, of course, just my opinion.

HTH
Lightning

 

[Aerin]

Hurray I am not along

The reason for this thread was that it is not the first time in my practice, when I see unbound forms solution from programmers with many years of experience. It was strange and I thought probably something exists that I cannot see

"Difficult to manage BeforeUpdate event" was not my quote. I just was comparing that with unbound form the programmer should manage much more than BeforeUpdate event.

By the way, how to separate quotes?

"Unbound forms have no RecordSource to load, so they obviously load faster." Yes, it is for filters, query criteria, transactions but if the form is in use to display tables’ data, the recordset should be opened, the record should be found and all fields should be connected to proper places. It takes time for loading as well. I received for support this type of solution from previous programmer and each table modification was a nightmare, checking all forms and code for modification. We re-build the system from scratch.

So I cannot see the flexibility in the unbound forms as well, and it will be very interesting to hear where the flexibility is...???

I agree that unbound forms have own place in programming.

 

[MichaelRed]

For the display of recordsSETs, bound forms are easily to use. On the otherside, single record forms seem, to me at least, to be somewhat easier. On the other side, single record forms (data entry & editing in particular) seem to be somewhat easier as UNbound forms. I generally use class modules to facilliate the transaction process or the unbound forms, and it is )again for me at least) somewhat less troublesome. I furhter have the belief that most people are -and remain- more comfortable with the 'approach' which they learn first in most endeavors, including programming. For me, this was an assembly language where (obviously?) the distinction of bound vs. unbound "forms" or screens was a much more flexible concept, provided by (and through) the individual programmer. Thus, perhaps, my slant toward the ubnbound forms as at least a reasonable and viable approach.





MichaelRed
mlred@verizon.net