TOPIC:

I noticed an interesting thing going on with aCountInfo and SqlExec. Normally, I would have code like this:

But when I run this in XSharp the aCountInfo array is changed by the SqlExec function from a one-dimensional array of [2] to a 2-dimensional array of [1,2]. So, now the original code gives an out of range error on aCountInfo[2] and has to be changed to:

Matt
According to the Vfp docs this is how it works.
However vfp’s weird array implementation allows you to access elements in a 2 dimensional array with a single index .

In most other languages aInfo[2] is the second row of the multi dimensional array and not the 2nd element of row 1.

Robert

Robert - you addressed your reply to "Matt", but the message came from Kevin Clark, not me.

Kevin,

did you verify in vfp with disp memo like aCountInfo ?

regards
Thomas

Kevin Clark wrote: I noticed an interesting thing going on with aCountInfo and SqlExec. Normally, I would have code like this:

local aCountInfo[2]
if sqlexec(connhandle,"select statement","dbfname",aCountInfo)>0 then
	if aCountInfo[2]>0 then
		//if I reach here then I have retrieved at least one record
	endif
endif 

But when I run this in XSharp the aCountInfo array is changed by the SqlExec function from a one-dimensional array of [2] to a 2-dimensional array of [1,2]. So, now the original code gives an out of range error on aCountInfo[2] and has to be changed to:

if aCountInfo[1][2]>0 then
	//if I reach here then I have retrieved at least one record
endif

Thomas,

I did verify this during development and VFP also has a 2 dimensional array.
It lists the elements as (1,1) (cursorname) and (1,2) (# of records)

Robert

robert wrote: I did verify this during development and VFP also has a 2 dimensional array.
It lists the elements as (1,1) (cursorname) and (1,2) (# of records)

Hi Robert,

Guessed you had - we both know the reason, as SQLExec can return more than 1 cursor, one row is intended fr each returned cursor although I don't remember any real code place where code returned multiple cursors. In theory such an option makes sense if you reuse server side stage table(s) to filter/generate return cursors based on particular set of data, in practice building/debugging single statements gives better dev speed

My comment was meant as a nudge to verify own assumptions plus a reminder (or hint for those testing fox first time) how easy fox max such things even if you do not work in developer edition with debugger - the runtime often is enough.

Seems I was tooooo subtle

regards
thomas