[AccessD] The Famous Bound/Unbound Debate

John Bartow john at winhaven.net
Mon Sep 13 23:17:00 CDT 2010


Jim,
You can copy and paste it into a post here and because we have a heads up
that it's coming, the moderators will let it through for you.

John

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Monday, September 13, 2010 3:01 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] The Famous Bound/Unbound Debate


  Great explanation Gary.  I would only add that part of the debate to is
that if you go the unbound route (and do all the work), then you have to ask
why bother using Access at all with all of its quirks (I'm talking about
install problems and references).  After all, you can't do a 3 tier design
with it and if your going the unbound route, your typically looking to do
some type of n-tier design or client/server setup. Might as well use
something else and get a whole heck of a lot more control, access to 3rd
party controls, standalone EXE, etc.

  As far as the PK's, well...I don't quite agree. And I'm not going to get
into it here as we've been over that ground many times.  In fact I wrote an
article for EE with my views on that subject.  So if anyone cares to read
it, it's here (I'm not 100% sure this will work though for non-members -
they've been making a lot of changes lately):

http://www.experts-exchange.com/viewArticle.jsp?aid=2041

Jim. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gary Kjos
Sent: Monday, September 13, 2010 3:32 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] The Famous Bound/Unbound Debate

Hi Brad,

Bound refers to using a record set, possibly a table or maybe a query as the
record source for an Access Form. This has the advantage of letting Access
take care of a lot of functionality.

Unbound refers to not having a record source for the form and then using
code behind the form to populate the various controls on the form. Doing
this requires some amount of work to populate those fields, detect changes
to them the user might make and then making the corresponding update to the
records in the data tables.

If you are using Access built in Jet Database as the data storage for the
application and you don't have that many rows in your tables, most would
agree that bound is the way to go. But maybe not ;-)  If you use another
database engine to store the data, perhaps SQL Server, it could be argued
that it's much better to only retrieve the individual records you are
wanting to display and or change and so doing that with code and then
populating the controls on the form might be a better way to go.

For many of us, it is a matter of preference in doing it one way or the
other. Sometimes it might be better to do it one way and sometimes it might
be better to do it the other way.

I think that is the gist of it. I'm sure I will be corrected if I have
miss-stated something or missed any key points.

Another heated past debate was over the use of Natural Keys verses Surrogate
Keys. A Surrogate key would be something like an Autonumber field, randomly
or sequentially assigned by the database engine. A Natural Key would be
something like a Social Security Number.  In my opinion Natural Keys are
similar to the use of GO TO in COBOL programs. There may be a place for them
occasionally but generally they should be avoided. In my opinion. A system
assigned unique key that identifies the record allows the field that would
have been used as the key to be changed in the event that something happens
to make that necessary. Perhaps a data entry error? Whatever. If you have
other tables joined to that record on that natural key you are STUCK without
doing some cascading update or something.

GK

On Mon, Sep 13, 2010 at 2:02 PM, Brad Marks <BradM at blackforestltd.com>
wrote:
> All,
>
> Compared to most of you, I am a relative newcomer to the world of 
> Access.
>
> Over the past few months, I have noticed a number of references to the 
> Bound/Unbound debate.  It sounds like this was a really hotly 
> contested issue at one time and that now people almost joke about it.
>
> For us newcomers, it would be nice if someone could explain this issue 
> at a high level and perhaps spell out the major pros and cons of each 
> side of the debate.
>
> It is not my intent to start a Web-war, I would just like to better 
> understand what is going on here.
>
> Thanks,
> Brad
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka
> Sent: Monday, September 13, 2010 1:53 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] SQL Server Express - true skinny
>
> Exactly.  Which is part of the premise of the bound/unbound debate.
> With unbound forms, where data is written in a split second chunk, the 
> stability of much higher user volume goes up tremendously!
>
> Drew
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
> Sent: Friday, September 10, 2010 2:46 PM
> To: 'Access Developers discussion and problem solving'
> Subject: Re: [AccessD] SQL Server Express - true skinny
>
> Dan,
>
>  That is more or less true, but the real bottle neck with a JET based 
> DB has never been .LDB file operations.
>
>  With JET, all processing is on the client side.  The server acts as 
> nothing more then a file share.
>
>  The trick with keeping a connection open to the BE avoids the 
> repeated closing/opening of the LDB and DB files and all the 
> associated overhead with removing/adding an active user under JET.  
> Some apps benefit from that, other not because they already maintain a 
> connection one way or another.
> The problem can be further compounded if the server has OPLOCKS on 
> (which allows client side caching of files).  JET doesn't need this as 
> the cache is already on the client side.  So it's simply a wasted 
> effort on the servers part.  And by default, OPLOCKs is enabled on 
> Windows servers.
>
>  The real restriction of JET is just one of stability.  With no server 
> side process to perform a rollback if a disconnect occurs, anytime 
> that happens in the middle of write operations your fair game for 
> corruption.   So by the time you get past 30 or 40 stations, it's just 
> hard to keep the environment stable.
>
>  To prove that point, you can easily run a read-only/reporting JET 
> based app with 200+ users without issues.
>
>  It's not an issue of performance, but one of stability.
>
> Jim.
> The information contained in this transmission is intended only for 
> the person or entity to which it is addressed and may contain II-VI 
> Proprietary and/or II-VI Business Sensitive material. If you are not 
> the intended recipient, please contact the sender immediately and 
> destroy the material in its entirety, whether electronic or hard copy.
> You are notified that any review, retransmission, copying, disclosure, 
> dissemination, or other use of, or taking of any action in reliance 
> upon this information by persons or entities other than the intended 
> recipient is prohibited.
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> This message has been scanned for viruses and dangerous content by 
> MailScanner, and is believed to be clean.
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



--
Gary Kjos
garykjos at gmail.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com





More information about the AccessD mailing list