[AccessD] Redesign the problem to fit the solution

Can't see the forest through the trees, eh?

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Thursday, May 29, 2008 1:58 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Redesign the problem to fit the solution

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,
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI Business Sensitive material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.