>>
>>I think Jim B. hit it right on the head with both the purpose of the EXTERNAL ARRAY command and the difference between compile time errors and compile time warnings. I don't know if my practice of placing the statement as the first one immediately following the parameter list has anything at all to do with it. What I do know is that I don't seem to get this error (warning, actually), and when I have it was resolved by EXTERNAL ARRAY... It's not I like I don't use a lot of them (passing as parameters) because I do.
>>
>>George
>
>George, I just went back to my code and my EXTERNAL ARRAY command was indeed the line immediately after the Parameters line. However, I found that instead of watching for 0 errors I just watched for '6' errors - the number of arrays not found at compile time. Annoying, but livable.
>
>Oddly, the command worked in 2 other programs. Very strange.....
>
>Barbara

Barbara,

Don't you wish FoxPro made the distinction between compiler errors and warnings? I know I do.

There are two possible reasons for this, I think. Bear in mind these are guesses, and I haven't researched the matter. Guess number 1, runs like this: You pass an array to a procedure/function without the EXTERNAL ARRAY, and it passes it on to a second p/f with the EXTERNAL ARRAY business. It wouldn't surprise me in the least to see two "errors". What's more likely (guess 2) is that an SQL command or one of the functions like AFIELDS() creates the array, then passes it on. It seems logical that the compiler wouldn't see it. As I mentioned, I don't seem to get these errors. However, one thing that I always do is prior to issuing the SQL or function call is to DIMENSION the array. This is strictly a hangover from my Pascal days (always declaring my variables).

As you said, the current situation is "livable", but if you discover that either of the above are the cause, I, for one, would be interested in hearing about it.

Thanks much,

George