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