Five SQL and name forms real applications write

[jefflroberts]

Five spellings a real Visual FoxPro application uses that the reference examples do not. All were found while importing a 60,000-line CodeMine application (Shutter Ace) into FoxDev, and none of them is rare there:

1. USE IN SELECT('alias') - a name with a bracket after it in an IN clause is a call whose answer is the work area. About 180 uses in the app.
2. ?name parameters in SELECT-SQL. Measured in VFP 9: accepted only by SELECT (INSERT, UPDATE and DELETE - SQL each refuse it with a syntax error), and read as an ordinary expression - a name that is both a field and a variable is the field, ?m.name asks for the variable.
3. INSERT INTO t [(fields)] SELECT ... - the query runs into a cursor of its own and each row goes by position to the fields named, or to the table's fields in order.
4. UNION [ALL] - each SELECT runs into its own cursor, later rows are appended under the first, and the whole is one final SELECT [DISTINCT] * carrying the union's ORDER BY and INTO. Columns are the first SELECT's; rows fold unless every UNION said ALL.
5. DO "path" and CREATE TABLE 'file.dbf' NAME x - a quoted name where the grammar took only a bare one. The NAME clause is read and dropped, since the container lists a table by its file stem.

Two VM faults came out on the way and are fixed here because the new forms could not be tested without them:

• A select list of nothing but * read blank rows from a freshly opened table: no field read had fetched the page. A SqlTouch instruction now reads each starred source before the row is made.
• INTO ARRAY put the program back in the last source's work area rather than its own, because the area was noted after the sources were opened.

Verification. crates/foxvm/tests/sql_forms.rs (15 tests) and the sql_forms golden, whose .expected was written by vfp9.exe. The full VM suite passes (311 tests). npm run argforms:check passes.

Recorded, not fixed (added to the parity plan under "Open, reported from the IDE"): a LOCAL shadows a field of the same name here where the product reads the field, and _TALLY is never set by any statement. Both belong to the resolver (system 3).

Effect on the application that prompted this: forms and class libraries compiling clean went from 26 of 47 to 36 of 47; parse issues across them from 463 to 229.

🤖 Generated with Claude Code

[jefflroberts]

Hi! I had Claude/Fable 5.1 try to help me get a fairly large project working, and this is what it did. No worries if you don't want it! I am also working on a Windows machine running under Parallels Desktop, so there may be some ARM64 improvements or specific configs. I've still got a few issues so I may follow up with another pull request or two. If you want me to stop making pull requests, just let me know. Neat project! Have a great day!

[RandomChirp]

@jefflroberts looks great, this was born out of experimentation so any help is greatly appreciated! If it works for you thats enough! Please keep them coming!

[jefflroberts]

Thanks so much, and thanks for the careful reviews on the rest of the batch! I'll work through the changes requested on #6 and #7 and rebase #8 once #6 is settled.