Gene, If I'm reading this right, you are running a query without specifying an "INTO" clause? When you do this, VFP will call its result cursor QUERY which describes the behavior you are seeing. (SQL passthrough will call its result cursor SQLRESULT if you don't specify an alias.) Closing the browse window will not close the cursor. You can put USE IN SELECT([query]) after your browse command to clean up.
-- rk -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Gene Wirchenko Sent: Monday, April 20, 2015 2:41 PM To: [email protected] Subject: VFP 9: Peculiar Query Behaviour Dear Vixens and Reynards: I am digging into the guts of a somewhat complex report. As I tend to do with things like this, I add some debugging code to check that the right things are going on. I am running into some weird behaviour with one debugging query and am wondering what I have run into or overlooked. I am querying from a cursor. I have not specified a destination so I get just a query browse. This is fine. I run the program, and when this code is enabled, the query executes and displays just fine. I look at the results and then close the browse. The problem is when the program ends. I have check code to catch tables left open. My check code insists that the query is still open; the table supposedly open is called "Query". I have never had this happen on other such code. The behaviour is consistent (happens every time), and when the particular query code is not enabled, the check code does not report a problem. What is going on? The query is: SQLSEL clcode,woccode,count(*) as thecount; from (alg2); group by clcode,woccode; having count(*)>1; order by clcode,woccode (SQLSEL is #defined to be select. I use this so my search program can distinguish between SQL-SELECT and work area SELECT use.) Sincerely, Gene Wirchenko [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/sn1pr10mb0462a20288a6318c710ae7d4d2...@sn1pr10mb0462.namprd10.prod.outlook.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
