Fabio,

I totally agree with you that it is a bug, but, If this behaviour is by design as others said, then I think it is not only a bug, but a serious one, because then the design is bugged.

As you said, if, by design, you can not pass fields by reference (and I think we all agree and understand why foxpro shouldn't allow it), then foxpro has no business checking the existance of fields when you pass it by reference, because my code explicitly, following foxpro rules, tells foxpro to use the parameter by reference, and this automatically rules out the possibility of using fields.

Imagine I write this (I am not claiming that what I will describe really happens, is just an example):

* TEST.TEST is a table disguised for some wicked reason
USE TEST.TEST

Now, somewhere along the path, foxpro finds TEST.DBF, and because DBF is the default extension used by USE, then it merrily opens it, aren't we going to say that this is a bug? Yes by design DBF takes precedence when no extension is given, but ignores it when any extension is given. The same should apply here, because in the code when I tell foxpro that the parameter is passed by reference (like when I give an extension) I am overriding foxpro's defaults.

Well, I hope it made sense, just my 2 cents.