SQLCursor Close 2

[mccartmd]

Hi:
Question regarding use of SQL cursor. . .
have a "MainData.dbf" and "Products.dbf" both in "Contact.dbc".
have a ProdFrm.frm with a grid on it of active "Products.dbf" with a column btn on it called "GO" which is a click event for the record choosen.
The "GO" Btn builds the SQL Cursor called "CurChoice" which is "ReadWrite" and which picks the serveral thousand records
of the "MainData.dbf" requested (Browses correctly). The Go btn opens the next form "ActiveProduct.frm" as modal and gives the results requested correctly. Upon Exiting the "ActiveProduct.frm" back to the "ProdFrm", would like to "dismiss" or close out or release the "SQL cursor" and chose next record and open the new SQL.
My question is: How do I start with a "clean" SQL cursor with each record choice of my "ProdFrm"?
(. . .each click of "Go btn" stacks up the cursor and becomes "very slow". . .even tho correct with each. . )
Any feedback would be deeply apprecited.
THX
Mike

 

[Mike Lewis]

A "SQL cursor" behaves almost exactly like any ordinary table (that is, a DBF). To get rid of it, you simply close it, using normal FoxPro commands. The simplest way is:

USE IN CurChoice

where CurChoice is the name of the cursor.

The act of closing the cursor also deletes it. So that's all you have to do.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Also, creating a new cursor with the same name as an existing one will overwrite the existing one. In other words:

SELECT .... INTO CURSOR CurChoice

That has the effect of deleting the previous version of CurChoice and creating a new cursor with the same name. You don't have to worry about what you call stacking up. The new version will be completely clean; VFP will not keep the old one hanging around in any way.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

>The "GO" Btn builds the SQL Cursor called "CurChoice" which is "ReadWrite" and which picks the serveral thousand records
of the "MainData.dbf" requested

You didn't say anything about the relation between your tables (eg which is parent and which is child data)

Let me assume your ProdFrm.frm form showing Products.dbf should call the ActiveProduct.frm as child form with just one product.

Then the GO button should really just forward the ID of the current record in the grid on ProdFrm and the ActiveProduct form should get all needed data for that product id in it's own private datasession.

That way you won't need to requery the main forms grid all the time (unless there is data changed due to changes in the child form)

Aside of that recommendation I agree on what Mike said, the requerying of the given cursor name will not stack up memory consumption, the old cursor with the same name is closed and the new cursor is built. You just have to be careful if curChoice is used as rowsource/recordsource of the current form, that can cause grids bound to that cursor to get blank.

Bye, Olaf.

 

[mccartmd]

Thx Mike and Ole, you were a great help!
Been trying to figger this for a long time. . .that brain cell obviously died 20 years ago!!!