Re: Can't ZAP File - In Use
Hi Robert,
(This is based upon testing in V8)
When you enumerate all open tables, you are getting a list of all tables (actually their aliases) from all sessions (threads) that have tables open. Almost all layouts (forms, browses, etc) are run in different sessions. When you do a table.get(tablenameAlias), it only gets a table from the current session. If you select a tablenameAlias that is not open in the current session (like the interactive window), it will not get the pointer to a non-open anything (and will error as well), hence you can't close that object either.
I'll add, that you probably can change the session effectively using a With/End With construct using a pointer to the other session's variable space, although I have not tried it with table.get(), so I can't say this as a fact. You can also do this in the Interactive Window by
Now suppose you got the pointer to another sessions table, using the menu "Set Interactive Window Session..." choice, table.get() should work with tables from that session, again untested as of this time.
However, leaving the session setting alone, here is what happens;
Now that you have the form's table, try to close it. THIS WILL HANG ALPHA!!!
When you switch to the form, it will display "Table not open" or similar message in a modal dialog box, that you will not be able to close, at which point you will need to close Alpha Five with the task manager.
Which basically comes down to the similar thing I preach about variables, do not delete/close resources that you did not create/invoke etc. While you can reference them all you want, and within reason, modify values of other threads, you must be careful when deleting it's required resources.
So you can close the form (which will delete the thread, table opens and other resources of it's thread), but you can't just go and delete it's underlying table.
So the next question is whether ?TABLE.enum_open() is checking to see if any of the tables attached to the database are open, or whether it is any table that is opened by Alpha, attached or not.
The answer is that it doesn't matter if it is attached, just whether it is open. Now Alpha has a function
that will close all tables everywhere if they are not associated with a session (MDI window), but there is a fair amount of code done to enumerate all tables of other sessions and not delete those that are in other sessions. An orphan table will, however, be closed.
So there is really nothing special happening here, Alpha is acting in a reasonable way. It would have been nice for TABLE.enum_open() to return the associated window pointer object name (as an option), but they did not.
Hi Robert,
Originally posted by SNusa
View Post
When you enumerate all open tables, you are getting a list of all tables (actually their aliases) from all sessions (threads) that have tables open. Almost all layouts (forms, browses, etc) are run in different sessions. When you do a table.get(tablenameAlias), it only gets a table from the current session. If you select a tablenameAlias that is not open in the current session (like the interactive window), it will not get the pointer to a non-open anything (and will error as well), hence you can't close that object either.
I'll add, that you probably can change the session effectively using a With/End With construct using a pointer to the other session's variable space, although I have not tried it with table.get(), so I can't say this as a fact. You can also do this in the Interactive Window by
Now suppose you got the pointer to another sessions table, using the menu "Set Interactive Window Session..." choice, table.get() should work with tables from that session, again untested as of this time.
However, leaving the session setting alone, here is what happens;
tbl=formname.Table_Get()
?tbl.name_get()
= "tablename"
?tbl.name_get()
= "tablename"
Now that you have the form's table, try to close it. THIS WILL HANG ALPHA!!!
tbl.close()
When you switch to the form, it will display "Table not open" or similar message in a modal dialog box, that you will not be able to close, at which point you will need to close Alpha Five with the task manager.
Which basically comes down to the similar thing I preach about variables, do not delete/close resources that you did not create/invoke etc. While you can reference them all you want, and within reason, modify values of other threads, you must be careful when deleting it's required resources.
So you can close the form (which will delete the thread, table opens and other resources of it's thread), but you can't just go and delete it's underlying table.
So the next question is whether ?TABLE.enum_open() is checking to see if any of the tables attached to the database are open, or whether it is any table that is opened by Alpha, attached or not.
The answer is that it doesn't matter if it is attached, just whether it is open. Now Alpha has a function
a5_ForceCloseTables()
that will close all tables everywhere if they are not associated with a session (MDI window), but there is a fair amount of code done to enumerate all tables of other sessions and not delete those that are in other sessions. An orphan table will, however, be closed.
So there is really nothing special happening here, Alpha is acting in a reasonable way. It would have been nice for TABLE.enum_open() to return the associated window pointer object name (as an option), but they did not.
Comment