>This applies to any kind of "calculated" fields, also text fields. Today I selected from a table with only two records, using a UDF which created a new string, like newstring = trim(string1) + ' ' + trim(string2). The record I searched for using the appropriate Where filter, came out as c(9) which would have been correct for the first record in the table. However, the record I searched was the second one, and for this record I got truncated data. I don't know if C(9) was chosen by VFP because of the data in the first record, or if it is some default field length. But the result puzzled me, I was not prepared for this behavior with such a small table.


Foxpro does grabs the first record of the returned resultset and uses the information to create the cursor, so the first record returned from your trim(string1) + ' ' + trim(string2) expression was C(9), so it was used to create the resulting cursor, this is either documented or very well known behaviour, cannot remember which :)


For example look at the code, you'll see that the resultset is (2, 3) when you would expect (1, 2), but for the function is called once to determine the type, that results in an extra increment of the variable

local lnStart

create cursor c_test (pk i autoinc)

append blank in c_test
append blank in c_test

lnStart = 0
select myFunc(@lnStart) as mySequence from c_test into cursor c_result
browse last normal nowait

function myFunc(tnValue)
	tnValue = tnValue + 1
	return tnValue
endfunc

[Update] I just realized that I said "it grabs the first record" but I should've said that it makes one extra call to the select to grab one record to use for determining the resultset structure.