I would appreciate a general opinion of this newsgroup regarding design and
implementation of an application.
1.    When multiple users are logged on and only viewing records (not
editing or adding) does performance slow down, and if so should it be a
valid consideration to take into account at development.
2.    My current application is solely driven by code.   I do not use any
bound forms.   All forms are populated with data via generic functions.
This was done simply because I could validate, filter and find a lot easier.
Other than the obvious, yes more time required in development as I'm not
using bound forms & controls are there any drawbacks to this approach.
3.    My current application requires that if a user is satisfied with an
editing session then the user must click the 'Save' button.   At this point,
after validation of course, the record is saved (via code within a
transaction).   Does this approach alleviate any problems that may occur
within a multi-user environment.  (I have incorporated error handlers for
record locking)
I suppose the main thrust of this post is 'What approach do professional
developers take as regards the above'.   Any suggestions would be
appreciated.   (BTW I'm using Access 2.0)
--
Steven Taylor
Melbourne, Australia.

--
Steven Taylor
Melbourne, Australia.

First, your biggest performance hit will be because you are using Access 2.0
Also, Access 2.0 .mdb files are more fragile than the later versions,
particularly Access 97.  In a larger multiuser environment, be prepared to
experience file corruption and "Lockout" which is what I call it when, for
no apparent reason, users can't get at your security file (.mda file) for
secured databases.  (This is solvable only by deleting the .ldb file for the
security file.)
Now...
1.  No.  Multiple users only viewing data, especially when that data is
retrieved and populated onto forms in code rather than by binding, will not
effect performance.   Be aware that locking can cause a form to be unable to
populate, depending on the locking type and number of users.
2. I am impressed.  This is difficult enough to achieve in most
circumstances and extremely hard in Access 2.0  However, you will find a
penalty in performance as your code executes on the forms opening, etc.  One
possible solution is to open the forms hidden and make them visible as
needed.  This will keep compile time down.
3. The save methodology is well and good.  It will significantly reduce
lockouts from records.  However, before you save the record you should check
to ensure that the data in the record is the same as what you retrieved for
the editing user.  If another user changed it while your editing user was
looking it over, he will overwrite the other users changes and no error will
be fired.  Its all about timing.  Maintain the data in memory in some form
and compare it before saving an edited record over it, so that you can warn
a user that the data has changed since they retrieved it and let them decide
whether it should be overwritten or not.

I would appreciate a general opinion of this
newsgroup regarding design and
implementation of an application.

1.    When multiple users are logged on and only
viewing records (not
editing or adding) does performance slow down, and
if so should it be a
valid consideration to take into account at
development.

Opening a database in "shared" mode results in
less performance than opening a database in
"exclusive" mode.
Once in multiuser mode, the only time you should
experience any degradation in performance is when
page locking has to take place. Everything comes
down to reducing the occurence of page locking
when it is not necessary.

2.    My current application is solely driven by
code.   I do not use any
bound forms.   All forms are populated with data
via generic functions.
This was done simply because I could validate,
filter and find a lot easier.
Other than the obvious, yes more time required in
development as I'm not
using bound forms & controls are there any
drawbacks to this approach.

Overhead, ie, the size of the overall program. Not
a whole lot though, but it is still increased.

Queries that are stored (saved querydefs) run
faster than queries that are dynamically
contructed and executed or run. For large
recordset operations this can be significant.

Revisions, updates, and ongoing maintenance to the
application will require reading, tracing
branches, and understanding the code. This may
require more time than usual for implementing what
otherwise would have been a simple change. For
example, adding field to a table. The existing
rst.Update will not pick up the new control's
value and update the new field. You will need to
always need to add the line rst![NewFieldName] =
me![NewControl] with the section of code that does
the record updating.

3.    My current application requires that if a
user is satisfied with an
editing session then the user must click the
'Save' button.   At this point,
after validation of course, the record is saved
(via code within a
transaction).   Does this approach alleviate any
problems that may occur
within a multi-user environment.  (I have
incorporated error handlers for
record locking)

If implemented correctly it reduces the amount of
time that the records within the page(s) will be
locked. This will generally provide for a
friendlier multi-user environment.
This creates a pseudo-optimistic page locking
scheme. In effect, pessimistic locking can be
utilized more effectively by pushing the locking
back to when the record actually needs to be
updated.

The validation rules can also take place in more
user efficient manner. Instead of waiting until
the record is being added or updated like the
table based validation rule property does, the
validation rule can be applied right then and
there. To me there is nothing more annoying than
getting to the end of a large record and being
pushed back to a field 20 tab stops prior becuase
something is incorrect. If the rule is not
dependent on information alsewhere on the form it
should be validated OnExit. It should always be
validated
as soon as possible and then backed up by the
yable level validation rule.

Making the user confirm there actions "update,
save, add ..." is a good idea, avoids the
situation of inadvertently tabbing through a
record, and makes the user more accountable for
what they are doing. You can also use an unbound
control that is the last tab stop, validated with
"Y" or "N" and defaulted to "N" to control the
updating of  the records.

Bill McKnight
PCS

On Tue, 30 Dec 1997 02:13:08 +1100, "Steven Taylor"

Brady Kelly

Brady Kelly