It seems to me that if the Calc is working in a test DB and not in the live DB, then one or more of the fields is not evaluating correctly in the live DB. Looking at your calc I see all the fields referenced are from the same table. Are you certain the Calc is being evaluated in the right context and not from the context of another TO of the same table?
There's no need to nest the case functions like this. You can simplify it by quite a bit.
If ( zz_RcntTransDate > (Get (CurrentDate) - 60) ;
Case ( zz_RcntTransAmt > 499.99 ; "1A" ;
zz_RcntTransAmt ≥ 250 ; "1B" ;
zz_RcntTransAmt ≥ 100 ; "1C" ;
zz_RcntTransAmt ≥ 50 ; "1D ";
zz_RcntTransAmt ≥ 25 ; "1E" ;
zz_RcntTransAmt ≥ 10 ; "1F" ;
One thing that would make your calcluation and my simpler version fail is if zz_rcntTransdate is not of type date.
"One thing that would make your calcluation and my simpler version fail is if zz_rcntTransdate is not of type date"
... and another is if the calculation is setted as stored ( most calculation using the Get( ) functions must be UNSTORED )
Thanks, all. The problem was the storage settings.
Since changing the setting to feep the field unstored, any layouts using the field have slowed to a crawl.
How could I make it so this calc feild updates in the back ground without burdening the entire DB and searchable in find mode?
How often does the data change? It's beyond my experience level, but perhaps you can run a daily update script. On the other hand, I don't see why this relatively simply calculation would slow things to a crawl. Perhaps you need to provide more detail about the situation?
Over large record sets, unstored fields such as, if referenced in a sort or find will perform much more slowly than a stored/indexed field.
There are several options for speeding up such operations, but much depends on your system design.