how to close a table used, in a "select sql " after the query have been executed to a curs

[titoneon]

Hi Everyone,
i just trying to immediately, to close the table included in the following "SQL SELECT " after this is executed.

SELECT sono, prtid FROM somast04 INTO CURSOR junkmast04

I just want to use the cursor created to display the content into a Grid but i want to make sure that the table "somast04.dbf" get closed immediately after the above "select sql" is issued.

How can i do that ?

the reason is cause this table belongs to a particular application that sometimes during the day needs to be reindex, so any extra application that use such table, will need to be close, in order to reindex that table, so i just looking for just populate the Grid from the content of the cursor so that way, i don't need to have that table open ("somast04.dbf")
Thanks for the help

 

[Mike Lewis]

Should be easy enough:
[tt]
USE IN somast04[/tt]

Or, a slightly safer version:

[tt]USE IN SELECT("somast04")[/tt]

which has the advantage of not throwing an error if somast04 happens not to be open.

(Note the use of quote marks in the second form, but not in the first.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[ggreen61]

You would have opened the table via a USE command or by a Data Environment. In each of these the table is assigned an Alias. To close the table you can issue the command:

USE IN SELECT('somast04')

 

[Mike Lewis]

You would have opened the table via a USE command or by a Data Environment

Not necessarily. In this case, it might have been the SELECT command which opened the table.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[titoneon]

Thanks a lot Mike, ggreen61 too, i was looking for some kind of command as:

CLOSE TABLE SOMAST04.DBF

But actually nothing like this exist.

 

[Olaf Doschke]

Yes, no close table exists, because USE opens AND closes tables.

USE actually is a command about a workarea and tells what to use in it. On the other side, it closes whatever is open in the workarea.

The command versions, which Mike and ggreen61 gave you already both do not open a new DBF or view or cursor, the just tell to USE the workarea by wither its alias name (Mikes USE IN somast04) or in a workarea number (USE IN SELECT("somast04")). It's not that easy to understand, but I can't believe you never used USE to close a workarea. The typical code foxpro developers programmed to close a certain alias named table is:

SELECT somealias
USE

as USE without any further command clause simply closes whatever is open in the currently active workarea and since SELECT somealias makes the workarea with that alias name the currently active workarea.
You never wrote such code or saw something like it?

In short again: USE both opens and closes. If you SELECT somealias and then USE another.dbf you close somealias.dbf and at the same time open another.dbf in that same workarea. That's how this command and all it's variants work.

Bye, Olaf.

 

[Mike Lewis]

And this is, of course, quite consistent with FoxPro (or, rather, Xbase) language conventions.

Quite often, a command is in the form:

[tt]<command> [<object>][/tt]

The command performs some action on the object. But if you omit the object, the command returns the environment to its previous or default state. (I'm using the term "object" here very loosely.)

For example:

[tt]SET PRINTER TO [printer name][/tt]

If you omit the printer name, the command reverses any previous SET PRINTER command, and returns the printer setting to its default state.

Similarly

[tt]USE [table name][/tt]

without the table name reverses the previous action of opening the table.

I'm probably not explaining this very well, but I hope you understand what I am trying to say.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[titoneon]

Hi Olaf,
Yes, i know i can use "USE"(to close table) , what i did not know was, that i can use "USE" just to close that table and not the Cursor, that is the reason me asking how to close that table w/o closing the cursor
Thanks a lot
Rgds

 

[JRB-Bldr]

what i did not know was, that i can use "USE"

Be careful just using USE by itself.
Unless you are CERTAIN which table/cursor is being 'pointed' to, you will want to specifically identify which table/cursor you want to USE.

If you do as Mike suggested above USE IN somast04 or USE IN SELECT("somast04") which will specifically designate which table/cursor to close.

Good Luck,
JRB-Bldr

 

[TamarGranor]

Be aware that if the query resulted in just a filtered view of the table, which is quite possible given the query you showed, then closing the table will also close the cursor.

There's really no reason for you to bother closing the table after running the query. Just not an important thing.

Tamar

 

[Olaf Doschke]

what i did not know was, that i can use "USE" just to close that table and not the Cursor

USE closes whatever is in the workarea. A cursor also is a DBF, just look at DBF("cursoralias"). Indeed cursroralias is wrong in itself, as an alias is really giving a name to a workarea, so you can address it using a name instead of a number. So in short USE works on a workarea and closes whats open in it and opens something in it, when you specify it. Another corner case example is USE DBF() EXCLUSIVE can be used to open the DBF already open in a workarea exclusive, though exclusive access can only be achieved from somthing not open beforehand. Why does it work? It closes the DBF and then opens it again. And looking even closer at things, why DBF()? Because DBF() without any parameter gives the dbf file name of what the current workarea has in it, just like USE works in the current workarea, so here the concept of commands and also functions about workareas working in the current workarea go hand in hand. Because of the same reason you may do a query on the current workarea by SELECT something FROM ALIAS() instead of writing a perhaps legthy workarea alias name.

Bye, Olaf.