> > I would report it as a bug to Microsoft, as well. VFP should

> > be smart enough to know that a 'number' with two decimals is

> > actually a string-- the data type matching code should be

> > easy enough to change to 'must be ONLY ONE decimal point'...

> This would mean VFP would have to parse the whole data set

> before determining the datatypes just in case the final

> record has two periods in one string. Bound to be a

> performance hit from that.

VFP already does this. Read the docs on XMLTOCURSOR(). How else does it figure out what datatype to make the new field? It obviously has to do content-inspection already, and for content length reasons, it must examine ALL of the content before transfering any of it...

> > If you were using an XSD schema, I believe this would have

> > worked as it should. I've never used an XSD schema with

> > XMLTOCURSOR(), but I believe it's possible... I really don't

> > use XMLTOCURSOR() that much, as I rarely have XML data that

> simple...

> Without a schema, how can VFP be expected to *know* what

> field types you require? It has to guess, and sometimes it

> will get it wrong. It's a simple matter to generate a schema

> (inline or external

> depending on requirements) and then you never need to worry

> about fieldtypes again.

A schema is always better, but the 'guessing' code can still be improved, it appears. Quite honestly, requiring a schema for an XML dataset that's already simple enough to work with XMLTOCURSOR() in the first place, is quite unreasonable, IMO...

--

Derek