[AccessD] The Famous Bound/Unbound Debate

Rocky Smolin rockysmolin at bchacc.com
Mon Sep 13 14:15:22 CDT 2010


At the same time there should be an explanation of Colbyizing  as a
consequence of using certain programming techniques.

R


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

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




More information about the AccessD mailing list