Unbound forms

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have heard of some people not setting the record source for a form and
reading and writing the data all through code. One of the benefits that I
can see is flexibility, but are there any others? What is the performance
difference? Is it really worth all the extra coding? Is there a good primer
out there that explains this a little more? Thanks in advance.
 
hi,
programmers who know what they are doing don't use bound
forms. in the long run bound forms will work against you.
flexibility is one aspect. extreamly large tables is
another. I have tables with a million + records. bound
forms are NOT an option. the larger the table, the longer
it takes to load and the more memory it uses.
I started with Access 97 programming for dummies(IDG books)
and spent a lot of time in newsgroups. a friend has Access
97 secrets(also IDG Books)
but any VB book is a plus. except for some keyword it's
all VB.
good luck
 
hi,
programmers who know what they are doing don't use bound
forms. in the long run bound forms will work against you.
flexibility is one aspect. extreamly large tables is
another. I have tables with a million + records. bound
forms are NOT an option. the larger the table, the longer
it takes to load and the more memory it uses. [snip]
Click to expand...

Looking...looking... nope, not a single accurate statement in there.

The fact that a table contains lots of records does NOT mean that a bound
form has to load them. While there are legitimate situations where an
unbound form is the better way to go suggesting that "programmers who know
what they're doing..." never use them or that they are only suited to small
apps is just plain wrong.
 
i made the statements and i stand by them. you are right,
i have never used bound forms. when i first started with
access, i was told not to use them. In the long run, they
will redo them all.
-----Original Message-----
hi,
programmers who know what they are doing don't use bound
forms. in the long run bound forms will work against you.
flexibility is one aspect. extreamly large tables is
another. I have tables with a million + records. bound
forms are NOT an option. the larger the table, the longer
it takes to load and the more memory it uses. [snip]
Click to expand...

Looking...looking... nope, not a single accurate statement in there.

The fact that a table contains lots of records does NOT mean that a bound
form has to load them. While there are legitimate situations where an
unbound form is the better way to go suggesting that "programmers who know
what they're doing..." never use them or that they are only suited to small
apps is just plain wrong.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com




.
Click to expand...
 
i made the statements and i stand by them. you are right,
i have never used bound forms. when i first started with
access, i was told not to use them. In the long run, they
will redo them all.
Click to expand...

Oh well, if you've never used them then you must know what you're talking
about.
 
The fact that a table contains lots of records does NOT mean that a bound
form has to load them. While there are legitimate situations where an
unbound form is the better way to go suggesting that "programmers who know
what they're doing..." never use them or that they are only suited to small
apps is just plain wrong.
Click to expand...

Well said, Rick. I was going to say something like that, but you beat me to
the punch and probably said it better. I use bound forms for about 99% of my
programming in Access and I have never encountered a performance hit that
was caused by the form being bound to a recordsource.
 
Hi,


Access is not VB. While it may be preferable, in VB, to use unbound
form, in Access, the reversed hold: use "bound" form in Access. Access'
forms are built in view of being "bound" to a query/table, with light
controls (no handle) while VB's forms are at the opposite (with hwnd,
without "form" recordset ). Having no form' recordset, in VB, it becomes
natural to open one, through code, that will be commonly share between the
controls in the form. Access simply does that job for you, automatically,
with expertise, no code to maintain, no user code to "run", same end result
(but more efficient). So, unless you think that writing your code in machine
assembler code is an advantage, better taking advantages of the SPECIALIZED
tool you have in your hand, no? Use bound forms, with Access.

As for versatility, do you mean you have a control that may correspond,
or not, to a field, or not, and that the decision can only be took at
runtime, or the fact known is only available then? That is not quite
typical, but still, some provision can be made in the Open event subroutine.


Hoping it may help,
Vanderghast, Access MVP
 
Back
Top