Bound Vs Unbound Form 1

[MelissaKT]

Hello, all! I have a question that may seem kind of stupid. I hope not but I'd really like some opinions on it. I'm developing an Assessor's database. I'm going to use a SQL backend and an Access front end. (it will actually be an access data project - hope I'm in the right forum!) Anyway, There are approximately 50,000 parcels in the tblPropertyInfo which handles all of the particulars of any given parcel. This will be a multi user database - probably have at least 30 users at any given time. Okay, I'm going to have one form with tabs on it. The question is:
How much slower is a bound form going to be versus an unbound form? Would it be enough of a performance hit that I should just stay with unbound? I was going to base the form on a view but I'm afraid that pulling that many records over the network would cause a marked slow down. Any Opinions? I'd really appreciate them!

Melissa

 

[TheAceMan1]

How are ya MelissaKT . . .

I believe the following will fill in most of the gap. It takes into account [blue]bound[/blue] as well as [blue]hybrid[/blue]:

Using Unbound Forms In Access

[blue]Your Thoughts? . . .[/blue]

See Ya! . . . . . .

 

[Remou]

MelissaKT

I think you will find this interesting:

Working with Access and Oracle/SQL Server
thread181-8354

 

[MelissaKT]

Boy, am I glad to hear from you guys! Ok, I've read both posts. I found several things interesting in both of them. If you'll bear with me, I'll explain a little further.

My original idea was to have an unbound form that loaded the first record (from a class) and have custom navigation buttons for the form. In fact, I already have the classes built. Since this is going to be such a HUGE database - lots of tables - lots of information. I'm not sure that this is the right way to go. I mentioned that there were going to be tabs? Each of these tabs will represent another table that is associated with tblPropertyInfo.

I guess my main question would be:
What would you do if you were building it?

 

[Remou]

I think I would be inclined to use linked tables and unbound forms, but I cannot say that I am speaking from experience with a set-up such as yours. I think that unbound forms would allow you to control more fully the way records are presented to users, locking etc. I think it would also be easier to keep the data clean with unbound forms.

 

[MelissaKT]

I want to say THANK YOU for your opinions. I really appreciate it. I'm still not sure whether I want to use unbound forms. I think it's going to depend on the kind of search functionality I end up implementing.

 

[TheAceMan1]

In the early days (Access 1.0, 2.0) I went thru the rigors of fully bound forms thinking they were more versatile. I wound up writing so much code I found myself not wanting to sit down and write anything! The problem here is you have to do everything access already does for you!

But my weight for bound wasn't that strong either. I finally got the answer I was looking for at a seminar Jun 1999. My question was:

[blue]As far as speed is concerned which is faster . . . a bound or unbound form?[/blue]

[blue]You have to look at what access was made for. [purple]Access was made to use the Jet and DAO. Since a bound form is based on DAO[/purple] it accesses the Jet more directly than written code in an unbound form which accesses more indirectly!

Although the difference in speed between the two are not readily preceived unbound places too much a demand on our time. If we become the programmers we expect unbound will become a special tool used once in a while.[/blue]

I've been using bound ever since other than special needs like search forms . . .

As of 2K we now have the addition of the [blue]Jet & ADO![/blue] In enough instances I've seen where ADO is faster than DAO but nothing I would brag about, however I am writing alot more code in ADO to accomplish the same as DAO.

[blue]Your Thoughts? . . .[/blue]

See Ya! . . . . . .

 

[TheAceMan1]

MelissaKT . . .

BTW: you'll never really know until you setup both bound/unbound and do some timing. Remember there are many variables involved with the network outside of access!

See Ya! . . . . . .

 

[JoeAtWork]

It doesn't so much a case of bound vs. unbound, but design. Is there any reason to open all 50000 records at once? Wouldn't it be better to have some sort of search so the user just fetches the record they need to work on?

If I'm not mistaken, in ADP's you can have forms bound to stored procedures that could return a few or just one record. Cuts down on network traffic immensely.

 

[MelissaKT]

First of all, I'm sorry that I haven't responded earlier! I hope everyone had a Happy New Year.

I've decided (thanks to AceMan) that I'm going to go with a bound form (probably based on a stored procedure). I'm going to do this mostly because the users WANT the automatic features of access - automatic saving, etc. And since it's just as fast, I think it'll be the right way to go. Thank you so much for all of your help!

 

[Remou]

MelissaKT
I am glad you have your solution.

Here is a note from Microsoft, for other readers of this thread.
[tt]Locking Shared Data by Using Recordset Objects in VBA
Although bound forms are one way to create a multiuser solution, they don't provide the flexibility that VBA procedures do. When you write your own locking procedures and run them from unbound forms, you can adapt your locking strategy to handle conflicts among users in a way that's most suitable for your situation — something that isn't possible with bound forms.[/tt]

From:

http://www.microsoft.com/technet/prodtechnol/office/office2000/solution/part3/ch16.mspx?mfr=true

 

[TheAceMan1]

Exactly! . . . [blue]a special case for unbound![/blue] . . .

See Ya! . . . . . .

 

[cehowski]

One of the big benefits (to End-Users) with bound forms, or any method of presenting "all of the data" as opposed to one (or a couple) records at at time, is the ability to scroll the data quickly. Peoples familiarity with browsable databases, and Window's use of scrollable grids makes single record databases seem "klunky". If the network can handle it, most people would rather deal with an initial delay in accessing the data, than needing to request records specifically.

 

[JoeAtWork]

50000 records seems like a lot to scroll through!
A common approach is to have a few controls at the top for entering filtering criteria, then some sort of "Fetch" button to load the list box below.

They still get the benefit of seeing multiple records, but at least it is cut down to a manageable size.