prevent deletion working erratically

[Boaz Bezborodko]

> Date: Tue, 17 Dec 2013 14:57:39 -0500
> From: Doug Luurs<doug at borisch.com>
> Subject: RE: prevent deletion working erratically
> To: "Jean-Pierre A. Radley"<appl at jpr.com>,	FilePro Mailing
> 	List<filepro-list at lists.celestial.com>
> Message-ID:
> 	<84C0D64135A0A74E9D64675AB7BF6A9D47D1117675 at bmc0003.borisch.local>
> Content-Type: text/plain; charset="us-ascii"
>
> I thought this was a forum to help find crazy little
> Things like that .. I personally don't think it was a
> waste of anyone's time.  But that's just me.
>
> -----Original Message-----
> From:filepro-list-bounces+doug.luurs=gmail.com at lists.celestial.com  [mailto:filepro-list-bounces+doug.luurs=gmail.com at lists.celestial.com] On Behalf Of Jean-Pierre A. Radley
> Sent: Tuesday, December 17, 2013 2:35 PM
> To: FilePro Mailing List
> Subject: Re: prevent deletion working erratically
>
> I don't know why this was failing both at the customer's and here, since I do recall seeing the same dates/filesizes on prc.input/tok.input at my customer's and here.
>
> When I told Doug that there was no @keyd label, I was wrong -- I must have looked at prc.input in a totally different database.
>
> To answer my own question: @keyd processing takes precedence over the Y/N setting in a screen.  The @keyd processing was designed to forbid the deletion of two particular special customer records, but procedding to "DELETE" any other record.
>
> Richard is right: @keyd is a lot more flexible, so now in addition to @keyd preventing deletion of two particular records, I'll add a check for @sn.
>
> I ruefully and abjectly apologize for wasting everybody's time.
>
> --
> Yours Truly,
> The Ironic Answerer
> JP

I can't imagine how many times I've asked a question here about a 
problem only to give a "Doh!  Why didn't I notice that?!?" once I got a 
response.


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com