[AccessD] Editing Records

Arthur Fuller artful at rogers.com
Thu Mar 6 16:38:01 CST 2003


On the assumption that both forms are almost identical, you're quite right.
However, my shifting opinion derives from a realization that viewing and
editing forms are often quite different, and insert forms different again. 
The use of a single form often requires the loading of combo boxes, list
boxes etc., some of which lists may be quite large. OTOH, a query could use
joins etc. to resolve all the FKs without populating any lists. You would
see read-only controls that display the columns of interest without
incurring any control-population overhead. Then when the user clicks the
Edit button, you populate the lists (taking into account various business
rules such as "you cannot change the customer on an existing order"...
leading to a significant increase in performance.
As I wrote originally, I'm still shifting. My current feelings are expressed
above. In a few recent experiments, I found a) much better performance; b)
better encapsulation of the logic (i.e. if it's a edit-customer issue, it's
obviously in the code behind frmCustomerEdit).

-----Original Message-----
From: accessd-admin at databaseadvisors.com
[mailto:accessd-admin at databaseadvisors.com] On Behalf Of Reische, Brenda L.
Sent: March 6, 2003 9:37 AM
To: 'accessd at databaseadvisors.com'
Subject: RE: [AccessD] Editing Records

Arthur:
I agree with your decade old opinion.

Why waste your time programming and MAINTAINING two or more separate forms
that have the same controls and similar functionalities?? If you add a field
to the table, you then have to remember to go add it to your insert form,
your edit form, your read only form, etc.  This is the position I am now in.
I have come into a job where the old developer created multiple forms for
every scenario.  It is a lot more work to maintain that system!


I feel this method that I use is MUCH cleaner and easier to maintain:

In my global code module (runs on autoexec) I have this variable declared:
	Public gintEditState As Integer         '1=Add, 2=Edit, 3=Read Only

Then the depending on the option clicked and/or the user's security, the
click event sets the global variable and executes the following:

	Case 1			'Add mode
		DoCmd.OpenForm stDocName, , , stLinkCriteria, acFormNew

	Case 2                  'Edit mode
                
           	DoCmd.OpenForm stDocName, , , stLinkCriteria, acFormEdit
            
      Case 3                  'Read-only mode
                
           	DoCmd.OpenForm stDocName, , , stLinkCriteria, acFormReadOnly
            

So the easy math would be:
One copy of the form + One set of code to maintain = cleaner application


Brenda Reische
Application Support Analyst
McDonough District Hospital

-----Original Message-----
From: Arthur Fuller [mailto:artful at rogers.com] 
Sent: Wednesday, March 05, 2003 3:29 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Editing Records

For about a decade I have worked on the principle that the same form can
handle displays, inserts and updates.
Lately I have been experimenting, and my tentative conclusions are that I
have been wrong for a decade; that a better approach is to have a reead-only
navigation form of some sort, containing an edit button, which does not flip
flags in the current form but rather loads an frmEditMyDataSource form
specifically designed for insert or edit. 

In this model, no single form contains the logic for multiple operations.
Rather, one designs forms for Insert and Edit separately. The behaviours are
radically different. Why complicate the logic of one form by injecting two
purposes?

I'm not throwing this out as a definitive conclusion, but merely one of my
regular queries (select * from projects where decision_certainty < .8).
I have coded innumerable dual/treble purpose forms, with logic distributed
among their controls, and in a few recent experiments have noticed that the
logic is a lot cleaner if I code something like this:

On DoubleClick
	If Me.NewRecord = True Then
		Open the Insert form
	Else
		Open the Edit form
	End If

Opinions? Diatribes? Scathing denunciations?

-----Original Message-----
From: accessd-admin at databaseadvisors.com
[mailto:accessd-admin at databaseadvisors.com] On Behalf Of Jim DeMarco
Sent: March 5, 2003 2:56 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Editing Records

In cases where a number of items (boolean variables in this case) must be
true for an event to occur I usually multiply the booleans by each other.
If I get a 0 result I know the event should not happen:

blnDoTheEvent = ((blnValidate1 * blnValidate2 * blnValidate3) <> 0)

If blnDoTheEvent Then
  'do it here
End If

HTH,

Jim DeMarco
Director of Product Development
HealthSource/Hudson Health Plan


-----Original Message-----
From: Bob Gajewski [mailto:bob at renaissancesiding.com]
Sent: Wednesday, March 05, 2003 2:50 PM
To: 'accessd at databaseadvisors.com'
Subject: RE: [AccessD] Editing Records


Andy

Just shooting from the hip, but couldn't that be done using a loop?

Seems like it might be a lot of coding, even for just 13 validations ... and
then it would handle more if they were added later.

Regards,
Bob Gajewski

On Wednesday, March 05, 2003 14:22 PM, Andy Lacey
[SMTP:andy at minstersystems.co.uk] wrote:
> Tim
> Just a suggestion 
>  
> Dim blnNeedsUpdate As Boolean
>  
> 
> blnNeedsUpdate =False
> 
> If validation1 = false then 
>         blnNeedsUpdate =True
> 
> End if 
> 
> If validation2 = false then 
>         blnNeedsUpdate =True
> 
> End if 
> 
> 
> etc
> 
> if blnNeedsUpdate = true
> 
> ..edit
> 
> change all fields
> 
> ..update
> 
>  
> 
> Andy Lacey
> http://www.minstersystems.co.uk <http://www.minstersystems.co.uk/> 
> 
> 
> 
> -----Original Message-----
> From: accessd-admin at databaseadvisors.com
> [mailto:accessd-admin at databaseadvisors.com] On Behalf Of Swisher,
> Timothy B 
> Sent: 05 March 2003 13:06
> To: accessd at databaseadvisors.com
> Subject: [AccessD] Editing Records
> 
> 
> 
> Hello group, I have a procedure (A2k) that opens a recordset (DAO) and
> cycles through the data validating/updating several fields for each
> record.  My question is, what is the best way to do this, 
> 
> Like this 
> 
> ..edit 
> If validation1 = false then 
>         change data 
> End if 
> 
> If validation2 = false then 
>         change data 
> End if 
> ..update 
> 
> Or  
> 
> If validation1 = false then 
>         .edit 
>         change data 
>         .update 
> End if 
> 
> If validation2 = false then 
>         .edit 
>         change data 
>         .update 
> End if 
> 
> I have about 13 validations that need to be done on about 90,000
> records.  Each validation goes to a SQL Server BE and check the validity
> of the data.  There is a huge difference in speed opening and closing
> the recordset so many times, but if that is the better way to go, then
> so be it.  All help is appreciated.  TIA 
> 
> Tim 
> 
>  << File: ATT00006.htm >> 

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


****************************************************************************
*******
"This electronic message is intended to be for the use only of the named
recipient, and may contain information from HealthSource/Hudson Health Plan
(HS/HHP) that is confidential or privileged.  If you are not the intended
recipient, you are hereby notified that any disclosure, copying,
distribution or use of the contents of this message is strictly prohibited.
If you have received this message in error or are not the named recipient,
please notify us immediately, either by contacting the sender at the
electronic mail address noted above or calling HS/HHP at (914) 631-1611. If
you are not the intended recipient, please do not forward this email to
anyone, and delete and destroy all copies of this message.  Thank You".
****************************************************************************
*******

_______________________________________________
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
_______________________________________________
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