[AccessD] VBA Unbound data entry / update form

William Hindman wdhindman at dejpolsystems.com
Sat Jun 14 21:37:26 CDT 2008


...wow! ...I go away for a few days and AccessD turns into OT on steroids!

...JC ...you were once a respected leader here ...but this post is so far 
out of bounds it doesn't even compute.

...nothing Drew has posted exceeds the limits of what you yourself posted on 
many a pk or unbound thread in the past
 ...what got your ass so far out of kilter I don't know, but its certainly 
not anything posted in this thread.

...imnsho, you owe a public apology ...a big one.

...besides which, you can't even spell horseshit right.

William

--------------------------------------------------
From: "jwcolby" <jwcolby at colbyconsulting.com>
Sent: Tuesday, June 10, 2008 3:18 PM
To: "Access Developers discussion and problem solving" 
<accessd at databaseadvisors.com>
Subject: Re: [AccessD] VBA Unbound data entry / update form

> > #1. You should NEVER have two users trying to edit the
> same field in the same record at the same time, where BOTH
> values being entered are correct.  (ie, there should only be
> one right 'Last Name' for a person, yes, it may change, but
> there is only one correct value for it)
>
> HORSHESHIT!  Hmmm... not enough emphasis there.
>
> !!!HORSHESHIT!!!!HORSHESHIT!!!!HORSHESHIT!!!!HORSHESHIT!!!!
>
> I have NO IDEA what world YOU live in but in my world people
> can change whatever they want whenever they want.  Person A
> writes the name in the last name field from a hastily
> scribbled form filled out by hand by a person who has a
> sixth grade education.  Person B is reading a form with the
> information for that SAME person typed in by a doctor
> office, the last name is different.  They can change it if
> they wish.  Person C is on the phone with the mother of that
> person.  They are verifying the information and mom says "no
> the name is spelled XXXXX.  That person can change it.  It
> is NOT MY JOB to tell any of these people that they cannot
> change the information in the database.
>
> !!!!THEY MIGHT BE DOING THESE THINGS AT THE SAME INSTANT!!!!!
>
> !!!!I MAY NEED TO DO THAT IN AN UNBOUND FORM!!!!
>
> NOW, DREW, THAT IS LEGAL.  I AM !!!NOT!!! GOING TO DESIGNING
> A TRANSACTION SYSTEM TO SAVE EVERY CHANGE EVER ENTERED BY
> ANYONE IN A BRAND NEW RECORD AS A CONTINUOUS HISTORY.  MY
> CLIENT DID NOT ASK FOR THAT, WILL NOT PAY ME FOR THAT AND IT
> AIN'T GONNA HAPPEN.
>
> !!!!I HAVE TO DEAL WITH THAT!!!!
>
> !!!YOU!!! ARE AN ARROGANT ASS IF YOU THINK ONLY YOU KNOWS
> WHAT IS LEGAL OR POSSIBLE IN THIS WORLD.
>
> Go away.  FAR FAR AWAY.  JOIN THE FOREIGN LEGIONS AND TRY TO
> CONVERT SOMEONE ELSE TO YOUR INSOLENT IDEAS.  Quite
> obviously I do not need, nor WANT your responses.
>
> Please do NOT respond to this thread EVER AGAIN.  In case
> you do not YET understand.....
>
> !!!HORSHESHIT!!!!HORSHESHIT!!!!HORSHESHIT!!!!HORSHESHIT!!!!
>
> ......to your silly ideas.
>
> Hmmmm.... I fear that I STILL was not speaking plainly enough...
>
> !!!HORSHESHIT!!!!HORSHESHIT!!!!HORSHESHIT!!!!HORSHESHIT!!!!
>
> ......to your silly ideas.
>
> Hmmmm.... I fear that I STILL was not speaking plainly enough...
>
> If you want to post solutions for questions I did not ask,
> please feel free to do so, in some other thread.  Hmmm... I
> COULD SWEAR THAT I MADE THAT REQUEST BEFORE...
>
> John W. Colby
> www.ColbyConsulting.com
>
>
> Drew Wutka wrote:
>> "What I have never done is build a coherent strategy for testing edited
>> data against the current data in the same record being edited and
>> handling edit collisions in a responsible manner, without the use of
>> locks."
>>
>> JC, I explained this before.  In quite lengthy terms.  Let me try to
>> summarize.
>>
>> #1. You should NEVER have two users trying to edit the same field in the
>> same record at the same time, where BOTH values being entered are
>> correct.  (ie, there should only be one right 'Last Name' for a person,
>> yes, it may change, but there is only one correct value for it)
>>
>> #2. You MAY have two people changing different fields in the same
>> record.  Not ideal, but granted, some systems may require this ability.
>>
>> To handle #2 is not very difficult.  Especially if you have a few tools
>> that help you build your data class/collection class modules.
>>
>> Build a Field Class that lets you put a field name, a current value and
>> a new value.  Then when you build your data class, create a field
>> collection in it, populated with a FieldClass object for each datafield.
>> On the Property Let statements, set the Data Class's internal variable's
>> value, and the NewValue of your FieldClass object (for that field). (Set
>> a 'ValueHasChanged' property in the FieldClass (returning true if
>> newvalue isn't blank).  Whalla, when you go to save the data for your
>> collection class, just loop through your field collection, and if
>> 'ValueHasChanged', THEN update that field, otherwise, leave it alone.
>>
>> Problem solved.
>>
>> Drew
>
> -- 
> 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