>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

Fabio,

I agree there are many situations where you need to know the field type but AFIELDS() seems reasonable to me.

In any event, congratulations - you make us all think a bit.

Regards,