allyn44@cox.net wrote in
news:tsdv81t1g1p0i435o078fdqojudakgge2h@4ax.com:
[color=blue]
>
> Thanks David--MY RESPONSES IN CAPS BELOW[color=green]
>> I would like to avoid making a second set of forms for editing if[color=darkred]
>>> I can avoid it[/color][/color]
> On Sat, 21 May 2005 22:13:03 GMT, "David W. Fenton"
><dXXXfenton@bway.net.invalid> wrote:[color=green]
>>
>>That's precisely why I tend to use a different form for adding
>>records than for editing, because you can end up with massive
>>convolution trying to handle two often contradictory sets of
>>requirements in one form.
>>
>>The key is this;
>>
>>Your New Record form need not be identical. All it needs to have
>>is the minimal set of fields required to create a valid record.
>>Once those are populated on the New Record form (which should be
>>unbound, so that it's easy to cancel the addition without needing
>>to undo an insert), insert the record in code using a recordset
>>with the argument dbAppendOnly (Set rsAdd =
>>db.OpenRecordset(strSQL, , dbAppendOnly), then add the values from
>>the unbound form to the fields of the recordset, and record the
>>new record's primary key value (I'm assuming an AutoNumber PK).
>>Use that PK value to open the new record in your regular data
>>editing form so the user can complete any additional data entry.[/color]
>
> I HAVE THIS SETUP IN ANOTHER PROJECT I AM WORKING ON--FOR THIS ONE
> THOUGH, ALL FIELDS ARE NEcCESARY AS THE DATA CHaNGES FOR EACH
> RECORD (WITH THE EXCEPTION OF THE ID FOR EACH SUBJECT ON SOME
> CONTINOUS FORMS)[/color]
I have never encountered a table that required a form of any
complexity that had so few fields that all of them are required --
that's the type of thing I'd expect for small tables with a handful
of fields (3, 4, maybe even 5), but never for any table with any
moderate number of attributes.
[color=blue][color=green]
>>Years ago I struggled with trying to do what you're attempting, as
>>well as trying to maintain identical appearing forms, one for add
>>and one for edit. I ran into just the kind of problem you're
>>encountering, plus the annoyance of having to delete a record (and
>>losing PK values in AutoNumber fields) when the Add was cancelled
>>by the user.[/color]
>
> DO NOT ALLOW THIS--HAVE AN ERROR REPORT FORM THAT LOGS THESE
> SITUATIONS--THEN I TAKE CARE OF THESE MISTAKES[/color]
Do not allow what? Deletion of records? Cancelling of an Add
operation? I take it, then, that you are trapping for the ESCAPE key
when in DataEntry mode?
[color=blue][color=green]
>>Of course, the hardest part may be deciding which fields really
>>are the required fields, i.e., the ones that you have to populate
>>in order to create a valid new record. But in a properly-designed
>>data schema, that should already be part of the design of the
>>table. If it's not, then your schema is incomplete.[/color]
>
> EASY ON SOME OF MY PROJECTS--NOT SO ON OTHERS :([/color]
I suspect you have an overly pessimistic definition of "required
fields." All that should be necessary to create a new record are the
fields required to be able to distinguish one record from another.
The other details can be left until later.
[color=blue][color=green]
>>The other advantage to this approach is that you can put any
>>duplicate checking code behind this form, instead of relying on
>>mere index collisions to catch dupes.[/color]
>
> I AGREE AND MANY ARE THE EVENTS THAT I MENTIONED THAT FIRE WHEN
> CREATING A NEW RECORD--BUT SOME ARE NOT WANTED IN EDIT MODE--AND
> VISA VERSA
>
> IE--I HAVE AN AUDIT TRAIL MODULE THAT IS CONNECTE TO FORMS SO I
> CAN KEEP PEOPLE OUT OF THE TABLES--BUT I ONLY NEED IT FOR EDITING
> RECORD. WHEN PEOPLE CREATE NEW RECS I OPEN THE FORMS IN DATA ENTRY
> MODE SO EXISTING RECS DON'T SHOW.[/color]
Well, having two different forms for this seems to me to be a very
easy way to accomplish this.
On the other hand I'm having some difficulty understanding why
checking for the .NewRecord or .DataEntry properties for conditional
execution of your code. If it's designed properly, it should be
easy:
If Not (Me.NewRecord Or Me.DataEntry) Then Call AuditCode(Me)
For clarity's sake, I just passed a form reference to the outside
audit subroutine, since you'd probably be passing a bunch of
parameters to write your audit record. If I were doing this, I'd
probably have a subroutine in each form that made the call to the
outside subrouting and included all the parameters, and then call
that without an arguments from all the subs within the form. This
would make the code a lot cleaner and simpler; if you need the value
of a control that has the focus, you could pass a control reference
to your local subroutine.
Of course, if you've written a subroutine local to the form to call
the audit code, then you could have the conditional test there,
instead of each time you call the local audit function.
So, I think that if you structure your code well, it shouldn't be
that hard to have conditional calling of your audit routines.
[color=blue]
> So your opinion is it would be best to keep the forms separate?
> for this project there are only about 10 forms--so it is not a big
> deal--but as I work on larger projects--I am afraid this may
> becomse impractical.[/color]
Well, as I said, if there is a natural subset of required fields,
then it makes sense to use a separate, lightweight form for the Add
process. If you can't do that, then you need to do conditional
execution of code, and that is made easiest by structuring your code
in a fashion that minimizes code duplication.
--
David W. Fenton
http://www.bway.net/~dfenton
dfenton at bway dot net
http://www.bway.net/~dfassoc 
