[AccessD] Redesign the problem to fit the solution

jwcolby jwcolby at colbyconsulting.com
Thu May 29 13:58:18 CDT 2008


Argumentative and does not provide any useful information.

Deleted.

John W. Colby
www.ColbyConsulting.com


Drew Wutka wrote:
> LOL.  Just can't let it go, eh?
> 
> It's not that you want to edit an existing field JC.  The problem you
> are presenting is one where you want multiple people to change multiple
> data points within a single field, in a single record.
> 
> So it's not that you want to knock birds out of the sky, you are trying
> to shoot satellites out of orbit with a BB gun, and you are asking how
> to get the BB gun to hit the satellites (and even when you hit the
> satellite, you aren't going to knock them out of orbit, at least not by
> much).
> 
> I have an application that does allow for data to be changed in an
> unbound format.  It's not that difficult, but it is based on the premise
> that a field within a record represents a single piece of information.
> That information may change (thus the reason for allowing changes), but
> it's not going to be set differently by two different people.
> 
> Drew
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Thursday, May 29, 2008 12:17 PM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] Redesign the problem to fit the solution
> 
> I found this entire discussion interesting on an 
> intellectual level.
> 
> Problem.  I need to knock birds out of the sky.
> 
> Solutions:
> 
> 1) Make sure the birds cannot fly, then you do not need to 
> knock them out of the sky.
> 
> 2) A shotgun
> 
> Problem.  Editing existing records in an unbound form.
> 
> Solutions:
> 
> 1) Never edit an existing record
> 2) ...
> 
> Notice that in both cases solution 1 does not fit the 
> problem, it redefines the requirement so that there is no 
> problem.
> 
> I tend to design to classes of problems, not specific 
> situations.  Given a choice I will design an unbound form 
> such that I can edit any record from any table.  The class 
> of problem is that I have an existing record (in some 
> undefined table) that I need to edit.  It may be a contact 
> record, or a claim record, or a Claim Type record or (insert 
> your own table here).
> 
> Now I have seen proposals (not in this thread) to save the 
> entire record and create a brand new record with all the 
> data from the old record, then edit as desired and save the 
> new record.  This does I suppose make sense as a change 
> trail but it is not what I am interested in (nor how I would 
> implement a change trail either).
> 
> I want to edit existing records, from ANY table that I care 
> to edit it from, in an unbound form.
> 
> Having stated the problem class as clearly as I am able, 
> does anyone out there do this, and if so how?  What issues 
> did you run into?  How did you resolve these issues?  Did 
> you end up with a solution to the problem class or did you 
> end up with a solution to one instance of the problem class, 
> but which unfortunately does not work for other instances of 
> the problem class?  Or did you redesign the problem?
> 
> I want a solution to the problem class, not one specific 
> instance of the problem.  And I do not want to redesign the 
> problem to fit a solution.  If it doesn't successfully edit 
> an existing record in an unbound form then it does not solve 
> the problem I am interested in solving.
> 
> If you feel that it is necessary to state your solution to 
> an entirely different problem, please feel free to do so by 
> creating a thread stating your problem and how you solved 
> it.  I will likely visit your thread to critique your 
> solution to your problem, and... I promise not to attempt to 
>   redesign the problem to fit my solution.
> 
> Thanks,



More information about the AccessD mailing list