[AccessD] Suppress error message dialog

[jack drawbridge]

Ryan,

Along the line of thought Arthur posed, and I don't mean to be contrary, I
have learned that sometimes requirements are not necessarily what has been
documented and designed/developed against. Users, and familiarity with the
business and sometimes changing business processes, get reflected in how
systems are being used/abused. What may seem to be an abuse of the approved
design, may also be considered a change in process or a possible
optimization of an established process.

I have seen lots of reporting applications where the reports were spooled,
printed and delivered--until one day someone questioned the process. All we
need are the exceptions. Or, we put this pile of reports here and no one
has collected them for a month???
Just saying --the requirement and the implementation -- may not be a static
as the original requirement and plan.
Just saying --it may be appropriate to analyze what's really happening.
Good luck.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Apr 23, 2018 at 1:32 PM, Ryan W <wrwehler at gmail.com> wrote:

>  Arthur,
>   The TURDTs who are doing this is nearly everyone. It's being done to save
> time.  They aren't "future availability" dependencies though. They're
> dependencies we sometimes (or maybe all the time?) make in house, mark as
> "opened" so that they can be used in the work and then marked Consumed when
> they're done (they may last a day, or several days).  The copy and paste is
> laziness to avoid having to hand enter each of the codes into the datasheet
> along with some other items that get stored (units used, etc).
>
>    Leave it to the users to find ways to use what you've programmed in
> unintended ways, that's for sure.
>
>
> On Mon, Apr 23, 2018 at 11:40 AM, Arthur Fuller <fuller.artful at gmail.com>
> wrote:
>
> > I think Triggers are your best bet, shy of a managerial mandate
> forbidding
> > cut-and-paste. But as written above, there may exist sound reasons for
> > getting around the "now available" rule, such as "Will be available by
> the
> > time this order is processed." Just one example.
> >
> > It seems to me that a discussion involving management, users who
> regularly
> > do this, and yourself. The Users Who Regularly Do This (TURDT :) should
> be
> > first to explain their behaviour. Management should be second to the
> plate,
> > having heard TURDT's reasoning. Finally, you step up, having heard their
> > respective perspectives, and either figuring out how to satisfy both
> camps,
> > or to explain why both cannot be satisfied within the limits of Excel.
> > OTOH, perhaps both camps can be satisfied, insofar as their rules are
> > sufficiently and effectively explained, in detail, and with known
> > exceptions thoroughly described.
> >
> > It's also true that unknown exceptions cannot be described prior to their
> > occurrence; but that ought not stop us from thoroughly describing the
> known
> > exceptions, and unveiling the reasoning behind their existence.
> >
> > This, I am woefully too aware, is the most difficult aspect of
> > application-development. In this light, I shall relate a tale from my
> > thankfully distant past, involving an insurance company. Various reports
> > were required, about 87% of which reported accurate data while the
> > remaining 13% contained a few inaccurate result-rows. I slaved over my
> > logic and algorithms for about 6 weeks, of meetings with the stakeholders
> > and various persons higher up the food chain, when someone at a meeting,
> in
> > early December of that year, casually mentioned that the InsCo operated
> on
> > 360-day years, in essence forgiving the Holiday Season. Meanwhile I had
> > gone so far as to factor in leap years and consequent calculations, and
> > hence, depending upon the life-span of any given pension fund, my calcs
> and
> > theirs might differ. Nobody thought to mention this accounting fiction
> > until the project was six weeks late, and only then mentioned in passing,
> > as if this humble programmer ought to have known the shenanigans this
> > insurance company was pulling. That contract cost me a bundle -- well not
> > compared to what Trump considers a bundle, but in my local league, six
> > weeks of work wasted results in a bundle. To escape this IMHO lack of
> > specification, the principal stakeholder dismissed me with a simple,
> "This
> > is standard practice in our line of work. If you'd done your research,
> > you'd have known that. This is on you."
> >
> > Lacking the funds to pay a lawyer, I succumed and took the economic scar
> as
> > a badge of honour, much like German swordsmen wore their scars. The
> > difference is that scars from a sword imply honour, while scars on your
> > resumé follow you forever, and do not get you laid by a woman who likes
> > scarred women -- which means most women. But now I'm echoing too much
> > reading of Raymond Chandler, Dash Hammett and James McCain, so best I
> stop,
> > and return to the novel upon I'm currently at work, whose conscious
> > intention is to emulate those great crime writers, and to that esteemed
> > list I would add the late Philip Kerr, whose Bernie Gunther novels are
> > inimitable.
> >
> > Arthur
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>