Hi:
I have worked around this problem, but I'm curious why it happens. This is in VFP 7.
When this code is run, there are 46 work areas used in the form's datasession.
The result is area 47 is now the table mytable with the alias myCursor.
Running the statement from the command window generates the expected results, a temp table with the alias myCursor.
Workaround:
The nofilter clause was added into vfp 5. vfp 3 had a bug (just one??!!??) that the SELECT INTO CURSOR statement would not generate a temp table unless a constant, logical field was added, e.g. "SELECT var1, .F. FROM myTable INTO CUROSOR myCursor" worked but SELECT var1 FROM myTable INTO CUROSOR myCursor" would throw an error.
Anyhow - does anyone have experience with this situation? Why does vfp not want to create a temp table unless forced to in this situation?
TIA,
Dan
Dan Walter
Daniel.Walter@uvm.edu
try { succeed(); } catch(E) { tryAgain(); } finally { rtfm(); }
I have worked around this problem, but I'm curious why it happens. This is in VFP 7.
When this code is run, there are 46 work areas used in the form's datasession.
Code:
SELECT var1, var2 FROM mytable INTO CURSOR myCursor
The result is area 47 is now the table mytable with the alias myCursor.
Running the statement from the command window generates the expected results, a temp table with the alias myCursor.
Workaround:
Code:
SELECT var1, var2 FROM mytable INTO CURSOR myCursor NOFILTER
The nofilter clause was added into vfp 5. vfp 3 had a bug (just one??!!??) that the SELECT INTO CURSOR statement would not generate a temp table unless a constant, logical field was added, e.g. "SELECT var1, .F. FROM myTable INTO CUROSOR myCursor" worked but SELECT var1 FROM myTable INTO CUROSOR myCursor" would throw an error.
Anyhow - does anyone have experience with this situation? Why does vfp not want to create a temp table unless forced to in this situation?
TIA,
Dan
Dan Walter
Daniel.Walter@uvm.edu
try { succeed(); } catch(E) { tryAgain(); } finally { rtfm(); }