Thanks for your thoughts, Agnes. I don't want to make changes yet in my applications, because it's not obvious for me, how we should proceed with this problem - on application per application basis or in our general Error Handler...

I've written a message to all our developers, but, as usual, got 0 response so far... :(


>Hi Nadya,
>>Right, I thought about it too. Another idea from George: add check for all possible numerical types, e.g. I, B, F, Y.
>>
>>Anyway, this is just an idea. Now I'm thinking: should we include it into our main Error Handler or should I go right ahead and add it to my particular application. The later solution looks like more flexible, since I would have an ability to count for number of such errors per file and if it would rich a critical point, I would stop the process...
>
>I, personnaly, would prefer to check things before I add them to my 'living' data. Lets say I create a cursor similar to the real table. In a specialized method or procedure (so I can trap method in errorhandler), I would do the following:
>

>PROCEDURE AppendForCheck
> LOCAL;
>  lnCount
>* Fill TestCursor FROM Source
> CALCULATE COUNT(nField) FOR TRANSFORM(nField)=='*' TO lnCount
> IF lnCount>0 THEN
>  *Start protokoll, set fields to reasonable default (BLANK?!) or ask user for further action
> ENDIF
>ENDPROC &&AppendForCheck
>
>PROCEDURE Error
> LPARAMETERS;
>  nError,;
>  cMethod,;
>  nLine,;
>
> IF LOWER(cMethod)='appendforcheck' THEN && and nLine=? and nError=?
>  RETURN
> ENDIF &&LOWER(cMethod)='appendforcheck'
>ENDPROC &&Error
>

>
>I have my doubts on putting to much code in error methods, because an error in error is very difficult to handle. (Error handler could not be nested)
>
>Agnes