Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / Database Design / December 2004

Tip: Looking for answers? Try searching our database.

GUI principals - design forms for add new record, modify record

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
S?RINGER Zolt?n - 18 Dec 2004 17:54 GMT
Hello,

When you want to create/modify master-detail records, what are the most
practical ways? (For example: having partners, and each partner has some
sites, contacts, discount prices.. etc)

I know two methods, please complete the variatons of yours:

1) press "new": read and edit all data, related data in the memory. When
press "save", begin transaction, save master table, and save the details
table. Problem is to check what records were added/modified/deleted in
master tables, but seems simple for the user (one press save...) Also, it
takes long time to refresh all the detail tables.. mostly via internet..

2) press "new": first of all, a little window asks for basic data, such as
"name". Then creates it in the master table, and open the form as "modify"
view. Each detail table has bound to database directly, user can
delete/insert/modify the records directly. "Save" button saves only the
chages of master table.

...and tell me, what solution do you suggest, the point of views are:
- work fast via internet, (minimalize the roundtrips)
- convinient to the user
- easy to code and maintain

thank you!
David Portas - 18 Dec 2004 17:55 GMT
Use stored procedures to handle the modifications rather than trying to
update the tables directly.

Signature

David Portas
SQL Server MVP
--

John Bell - 18 Dec 2004 18:24 GMT
Hi

You should present the two designs to your users and let them decide! It may
be that they do not have all the details at hand when the initially enter
the master information, therefore option 2 may fit their work patern better.
If option one fits their work pattern better then it should be the most
efficient way for them to input the data, but if you implement option 2 when
this is the case, then you may end up making them less productive and they
will cuss the system you have written!

> - work fast via internet, (minimalize the roundtrips)
Whatever system you implement the use stored procedures should minimise
round trips and it should help you avoid SQL injection if you use strict
typing.

> - convinient to the user
This is more to do with layout, putting fields in the logical order,
(possibly) give them templates or defaults, avoid excessive mouse
intervention, make sure that your form can be accessible by persons with
different abilities, make your process "intuative" and the workflow flows.
Make sure that information is logically grouped and you avoid information
overload and clutter.

> - easy to code and maintain
Use of stored procedure should help this, use of templates so forms have a
common structure, use of  meaningful comments and good documention.

John

> Hello,
>
[quoted text clipped - 22 lines]
>
> thank you!
Ralph - 19 Dec 2004 02:39 GMT
> Hi
>
[quoted text clipped - 24 lines]
>
> John

LOL

Never present TWO designs to a user. You will walk out of the meeting 5
hours later with FIVE.

Other than that, John's advice is sound. <g>

-ralph
John Bell - 19 Dec 2004 08:10 GMT
> LOL
>
> Never present TWO designs to a user. You will walk out of the meeting 5
> hours later with FIVE.

I can't believe I put that...

> Other than that, John's advice is sound. <g>

That's nice to know!

> -ralph

John
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.