Now *here's* an odd problem with dclerk

[GCC Consulting]

> -----Original Message-----
> From: filepro-list-
> bounces+gccconsulting=comcast.net at lists.celestial.com [mailto:filepro-
> list-bounces+gccconsulting=comcast.net at lists.celestial.com] On Behalf
> Of Jay R. Ashworth
> Sent: Monday, March 17, 2008 11:59 PM
> To: filepro-list at lists.celestial.com
> Subject: Re: Now *here's* an odd problem with dclerk
> 
> On Mon, Mar 17, 2008 at 11:06:50PM -0400, Kenneth Brody wrote:
> > Quoting Jay R. Ashworth (Mon, 17 Mar 2008 18:47:49 -0400):
> > >And indeed, that solved it.  Now to figure out *how* it's breaking
> it.
> > >
> > >Again: filePro being unhappy with internal stuff and bailing instead
> of
> > >giving useful error messages.
> >
> > Actually, if it's the code that's assigning to real fields in
> automatic
> > processing, as the symptoms seem to indicate, then it's filePro doing
> > exactly what it was told to do.
> 
> No, because the fields really *do* contain that data.
> 
> So if Short and Extended selection change their minds based on
> automatic assigning values, then maybe -- if the auto table does that.
> 
> But *my* assertion was that I think the table was stored non-ascii by
> 5.0.14, and then beamed back in time by xfer to a 5.0.13 install and
> that *that* is what's making it break.
> 
> Can't test that until he looks at the code.
> 
> Cheers,

An aside on auto process cycle.

If one uses @keyxx, each time an @key option is pressed, the auto process
table runs again.  So, it is possible for auto process to run more the 3
times on a record.

To count the cycles on any given record

If: rn(8,.0)= ne @rn	'initialize values for each record 
Then: ct="";rn=@rn;ct(2,.0)=ct+"1";end
If: rn=@rn			'count the iterations of auto process
Then:ct=ct+1";end


Richard Kreiss
GCC Consulting
rkreiss at gccconsulting.net