Lokup problem

[John Esak]

Have you checked all the obvious conflicts... For example if it's a big
table, is it possible you have a label of "slaes" somewhere that you aren't
using anymore.  I don't think having a real field named "sales" would cause
this kind of problem, but you may be finding some new bug.  Is there any
selection set called "sales"?   Not that any of these are dead conflicts,
but you may have uncovered something.  How about a qualifier called
"sales"... Etc., etc., etc.  Then, if you do find it, maybe we can see some
reason.  

You have seen the error where if you do something like:

  aa=mid(14,k,d) 

And it syntax bombs... Why?  Because somewhere in the map you have an
associated field "d) debits"   :-)  By the way, I don't know if mid() really
does this, but some constructions with a single letter and closing paren
cause a syntax error. You can usually fix it by adding a space... Like

  aa=mid("14",k,d )

Which, too, is odd.  I wish I could rmember exactly where this is so I'm not
making a bad guy out of mid when it isn't.  :-)

Of course I wish I knew why I threw this completely unrelated junk into this
thread in the first place.  :-)

John
 

> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com 
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
> m] On Behalf Of Richard Kreiss
> Sent: Monday, August 09, 2010 9:25 AM
> To: filepro-list at lists.celestial.com
> Subject: Re: Lokup problem
> 
> John Esak suggested I try adding PFLBSIZ=8192 and see if this helps.
> 
>  
> 
> After removing the writes I had put in the auto process 
> table, per John's
> instructions, I reset the alias from salesj to sales in the 
> input processing
> table.  The problem returned, input processing gives error from my NOT
> "Record Not found"  but it still works in input processing.
> 
>  
> 
> I changed all of the alias's to salesj from sales and now I 
> have no problem.
> Easy fix, but why should sales as an alias cause a problem 
> when I have used
> it extensively throughout this application without a problem? 
> 
>  
> 
> Richard Kreiss
> 
> GCC Consulting
> 
>  
> 
>  
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://mailman.celestial.com/pipermail/filepro-list/attachment
> s/20100809/6e6f6790/attachment.html 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>