>>>Fabio,
>>>
>>>Doug is not talking about table structure, he's talking about variables.
>>>
>>
>>Doug, in its message writes word DBF, I think that DBF was a table,
>> but now I discover that it is one variable.
>>
>>This Thread don't speak of variables.
>
>Fabio,
>
>Is this any different than TYPE() returning N for integer, numeric, double, and float? If not, do you consider that a bug also?
>
>Personally, I think this is more of a poor design choice than a bug.
>
>Regards,

Hi Jim,
sure, but when one sees poor a design ( and VFPT see it sure ),
and it continues to use poor a design then for me it becomes a bug.

I do not distinguish a lot between a bug for distraction,
bug for algorithm error, bug for design error or any other thing.
For me only the consequence is important,
the reason of the issue genesis this is insignificant because
I would not want to enter in the VFP black box, this is a job of the VFPT.

A bug is an error of thought of some developer, analyst or other,
that it creates computation errors, incoherence or useless complications.
This is my definition, if it does not appeal to I cannot makes us null.

I uses this logic because the genesis of many bugs happens before the writing of the program,
the bug is conceived when an analyst decides which behaviors wishes to realize and the way to realize them;
if this choice is happy then little bugs could be born,
otherwise during the evolution of the application it must generate a logical tangle that generates one swarm of bugs.

Sure many problems of VFP are born from its origins,
but it is not written from no part that the new behaviours must follow logic of the old ones; of the rest very many functions of FoxPro 2.X have been only left for compatibility, and practically they are not usable in new VFP9.

In the specific one:

Numeric, Float, Double, or Integer => N
This can have a justification why a espression it is N,
 but it can be discussed for Integer,
inasmuch as VFPT' s Aleksey say that integer use to INT32 format, then i cannot known
when a variable is stored like a integer or a IEEE float.

But, now, found a logic for this:
<PRE>
CLEAR
CREATE CURSOR T (fc C,fm M,fv V, fQ Q,fW W)
SCATTER MEMVAR MEMO
? "TABLE"
? TYPE("T.fc"),TYPE("T.fM"),TYPE("T.FV"),TYPE("T.fQ"),TYPE("T.fW")
? "ENGINE EXPRESSION TABLE"
? TYPE("SUBSTR(T.fc,1)"),TYPE("SUBSTR(T.fM,1)"),TYPE("SUBSTR(T.FV,1)");
  ,TYPE("SUBSTR(T.fQ,1)"),TYPE("SUBSTR(T.fW,1)")
? "ENGINE TABLE CASTING"
? TYPE("CAST(T.fc AS C)"),TYPE("CAST(T.fM AS M)"),TYPE("CAST(T.FV AS V)");
,TYPE("CAST(T.fQ AS Q)"),TYPE("CAST(T.fW AS W)")

? "MEMORY"
? TYPE("M.fc"),TYPE("M.fM"),TYPE("M.FV"),TYPE("M.fQ"),TYPE("M.fW")
? "ENGINE EXPRESSION MEMORY"
? TYPE("SUBSTR(M.fc,1)"),TYPE("SUBSTR(M.fM,1)"),TYPE("SUBSTR(M.FV,1)");
,TYPE("SUBSTR(M.fQ,1)"),TYPE("SUBSTR(M.fW,1)")

? "ENGINE MEMORY CASTING"
? TYPE("CAST(M.fc AS C)"),TYPE("CAST(M.fM AS M)"),TYPE("CAST(M.FV AS V)");
,TYPE("CAST(M.fQ AS Q)"),TYPE("CAST(M.fW AS W)")

On the example you see :
- a help bug for Blob, it return W fortunately ( I expected this )
- when a Memo or a Blob go into the memory, they lose this datatype correctly
because a variable have not a bound size attribute ( really a variable is a Memo or a Blob !)
- BUT, print C in the first three lines does not have justification.

An other important point is the fact that an index with within a varchar has very many limitations,
and can create troubles and search errors if it has not been understood well like work.

A simple example:
a VARCHAR "=" comparison, with SET ANSI OFF or SET EXACT OFF is not optimizable.

Then known if a field is or is not a VarChar is very important,
and to use a AFIELD() for found this info is absurd.

Fabio