Can't ZAP File - In Use

[nugget3825]

Frustrating and normally, that means an easy answer.

The files: File1 and File2.
--------------------------------------------
I identified records for selection within File1
ZAP File2
Append selected records (File1 -> File2)
Zap File1
Append File2 to File1

Sounds simple enough. BUT, the ZAP on File1 says I can't do it because the file is in use. UNLIKELY as no one else is on my development laptop.

Help...

Lar

[Tom Henkel]

Re: Can't ZAP File - In Use

close file 1, then try the zap.

[nugget3825]

Re: Can't ZAP File - In Use

Tried issuing a table.close but didn't help.

Also, I have an operation that posts a logical field for selection. If I work that operation into the script, it fails. If I omit the post and run the script from outside the menu, i.e. - call it from the Control Panel, seems to work fine.

How can I force the file to close I guess is the question.

Lar

[Garry Flanigan]

Re: Can't ZAP File - In Use

Convert the "operation that posts a logical field for selection" to xbasic and then add a TABLE.close() at the end of the script. Note that you substitute the pointer name as used in the script for TABLE.
Operations often leave tables open, but in your case why the script works from Control Panel but not from a button is strange.
Also, from what you indicate, have you considered an xdialog to allow selection of the county (as mentioned in your other post)?

[jacobr]

Re: Can't ZAP File - In Use

How to find out different pointer of a table if opened more than once? I do also find difficulties in zap-ing a file!
Renny

[Mike Wilson]

Re: Can't ZAP File - In Use

This thread makes me cringe. Let's try and use the correct language so we are clear on what is needed.

You zap TABLES not FILES. FILES are either created, appended or removed/deleted. Database TABLES are zapped ( or emptied). Is that what you are trying for Renny?

[Al Buchholz]

Re: Can't ZAP File - In Use

Also one of the primary reasons a table isn't zapped is when the code is called from a form/browse that is bound to the table (or set that contains the table).

Therefore the table is open and you ain't gonna close it..

Hence the suggestion to use an xdialog, toolbar, or menu item that isn't bound to a table/set.

[SNusa]

Re: Can't ZAP File - In Use

To close all open tables for any .dbf application, this should work when run from the IW, but it doesn't!
~There may be a bug in the enum_open() method?

According to the wiki:
The TABLE.ENUM_OPEN() method returns a character string containing information about open tables.

dim vc_OpenTableList as C
debug(1)
'ON ERROR RESUME NEXT    'some tables are presumably internal, and can't be closed...  This gets around the problem.
vc_OpenTableList = TABLE.enum_open()    'get list of tables
msgbox("vc_OpenTableList")    'show OPEN tables...
for each item in vc_OpenTableList    'loop through tables
     TABLE.GET(item.value).close()    'use table pointer (without assigning a variable to the pointer) to close table.
          ' (these two lines below are the same as one line above)
          ' dim vp_Table as P = TABLE.GET(item.value)    'this line gets pointer to table.
          ' vp_Table.close()    'close OPEN table ~ PROBLEM HERE.....
next
'now zap that table!

The problem appears to be: Some of the user (enumerated / "open") tables (reported as open by enum_open() are not actually open!?!?

Example, try this: (Using any existing database containing .dbf tables).....

1. Copy the code above into the IW.
2. Double click on any .dbf table (to open a default browse, open a few tables by double clicking on the table if you wish)
3. Now go back to the IW and run the code from there.
4. Notice that the msgbox() indicates these table enumerate as open. (enumerated in list)
5. Set a watch variable (in the debugger) to item.value. (so that you know when you are on the tables you opened in the browses)
6. Trace through the code.
7. When TABLE.GET(item.value).close() attempts to close these "open tables" (listed in enumerated list) a [no table found] error is displayed....

Problem -> Tables show as open from vc_OpenTableList = TABLE.enum_open() but TABLE.GET(item.value).close() indicates error of [no table found].

Question: Are the tables really open in the first place? Or is enum_open() incorrectly reporting them as open tables since they are being displayed in the browse......???

PS: I know some of the tables that enum_open() returns are internal a5 tables. (That's why I had added the ON ERROR RESUME NEXT code...... I remmed it out to step through the code. When you first get to these "internal tables" you'll have to hit "skip" in the debugger, as they re at the top of the list.)

Also, if you open the tables using table.open("TableName") these tables are closed correctly. (So the code is closing tables as expected.) It's apparently just being fed incorrect information from the enum_open() method. ~ If that makes sense....

RSVP ~ Aaarrrgh!

[csda1]

Re: Can't ZAP File - In Use

Hi Robert,

~There may be a bug in the enum_open() method?

Extremely doubtful.

There are 2 problems I see. First, you are using the for each construct which returns a pointer. This may not be the best way because of the following line


TABLE.GET(item.value).close()

If you had done it like

ptr=table.get(item.value)
ptr.close()

that might be better. In some cases, such as DIM, it does not evaluate the leading part as an expression. Better to build the pointer in pieces than place an expression as you have if you are not sure. In Active X, only one level of pointer is supported in the parameters, so build a pointer to the variable space and use that as an intermediate pointer.

Also, since the for each is a language construct (not a function, but built into the language), then it's usage of the item.value pointer may also be a bit odd. Using item by itself may have been better. Alternatively, I would have used a for next loop, and just take each line of the text. That would eliminate any possible oddities.

I don't have time to try it right now, so you can play with those ideas.

[Al Buchholz]

Re: Can't ZAP File - In Use

To close all open tables for any .dbf application, this should work when run from the IW, but it doesn't!

dim vc_OpenTableList as C
debug(1)
'ON ERROR RESUME NEXT    'some tables are presumably internal, and can't be closed...  This gets around the problem.
vc_OpenTableList = TABLE.enum_open()    'get list of tables
msgbox("vc_OpenTableList")    'show OPEN tables...
for each item in vc_OpenTableList    'loop through tables
     TABLE.GET(item.value).close()    'use table pointer (without assigning a variable to the pointer) to close table.
          ' (these two lines below are the same as one line above)
          ' dim vp_Table as P = TABLE.GET(item.value)    'this line gets pointer to table.
          ' vp_Table.close()    'close OPEN table ~ PROBLEM HERE.....
next
'now zap that table!

Where did this code come from?

[Stan Mathews]

Re: Can't ZAP File - In Use

Robert,

Did you try the example in the docs? Sometimes they aren't fully laid out.

Only the interactive window open.

? table.enum_open("F"+crlf())
= C:\PROGRAM FILES\A5V11\TEMP\A_CASE.DBF
C:\PROGRAM FILES\A5V11\TEMP\A_GLOSS.DBF
<NUL>
<NUL>

'switch to control panel, open browse of customer table, switch back to interactive
? table.enum_open("F"+crlf())
= C:\PROGRAM FILES\A5V11\TEMP\A_CASE.DBF
C:\PROGRAM FILES\A5V11\TEMP\A_GLOSS.DBF
<NUL>
<NUL>
c:\program files\a5v11\samples\alphasports\customer.dbf


dim tbl as P
tbl = table.get("C:\DATABASES\ALPHASPORTS\CUSTOMER.DBF")
ERROR: No such table
'I believe the error occurs because the customer table is open in another session.

[SNusa]

Re: Can't ZAP File - In Use

Robert,
Did you try the example in the docs? Sometimes they aren't fully laid out...
'I believe the error occurs because the customer table is open in another session.

Hi Stan;

I've tried all sorts of things (including the examples) with this. What doesn't make sense it that the following enumeration code (for forms) works just fine across all open forms, when getting names of forms. ~One would expect that the .close() method to work in a similar fashion across all open tables. But I'm guessing you may be right.

dim vp_Form as P = parentform.this
dim vp_Object as P
dim lst as C

lst = A5.Form_Enum(2)
ui_msg_box("FORMS:",lst)
for each thingy in lst 
if is_object(thingy.value)	
    vp_Object = obj(thingy.value) ' -WORKS
    if(thingy <> parentform.Name(),vp_Object.close(),"")    ' closes all open forms except this one...
end if
Next

PS: I'm aware that the if/then loop (above) is a strange hybrid of if and iif, but it works OK, so I left it in place....

[Stan Mathews]

Re: Can't ZAP File - In Use

One would expect that the .close() method to work in a similar fashion across all open tables.

Closing a form is quite a different matter from closing a table. What should happen if one executed a command to close a table and there was a form open based on that table and the form had an incomplete record entry/edit in progress?

[SNusa]

Re: Can't ZAP File - In Use

Closing a form is quite a different matter from closing a table. What should happen if one executed a command to close a table and there was a form open based on that table and the form had an incomplete record entry/edit in progress?

Thanks Stan. Perfect analogy.

~Obviously, this difference (expected versus actual behavior) of the ".close()" method [on different object types] is necessary here.

Your statement brought up another interesting related question: Does Table.enum_open() [and most other similar methods] return all open tables, or only open tables for one particular user? (Important considerations when enumerating!)

Apparently, methods such as table.close() and the likes must only act upon the current form/session/user, right? ~Now I'm getting a bit overwhelmed thinking about method "session-reach" & scope. Is this info concisely listed anywhere? ~ I think I may need to start a new thread on the board.

It's a bit "daunting" realizing that different methods (or one single method) like .close() can effect different object collections (classes) at a different "scope" (for lack of a better word!) What is the correct term/wording for this "scope" concept used in this context?

Making reference to a recent quote here on this forum, I'm thinking that: "I may also be (exploring) the deep end of the pool!"
(time to pull out the scuba gear)

[SNusa]

Re: Can't ZAP File - In Use

Where did this code come from?

Hi Alan & Ira;

~Al, the code came from "my brain." Every thing works except for the close part. (Although the tables appear in the enumerated list, the tables aren't "there to close" unless they are explicitly opened via Xbasic code via table.open() etc.)....

Both Stan and Ira added some insight... But the thing is: <form>.close() method will & does [attempt] close all forms in the enumerated list where as <table>.close() does not consider (or even see) these tables as "open" (valid table objects) unless the tables were explicitly opened via Xbasic code.

~I don't see the big difference in how either of these objects should be acted upon by .close(). Especially after taking into consideration the fact that underlying tables [in forms] can also be in "edit mode" at the time the <form>.close() method is invoked, yet <form>.close() attempts to get the job done regardless of this fact. (Whereas the <table>.close fails, indicating the tables are not even there....)

Put another way:
<frm>.close() will attempt (at least) to close all open forms in the enumerated list as reported by form.enum().
<tbl>.close() only acknowledges tables that were opened via Xbasic code. ~Thus implying the list returned by Table.enum_open() is not correct!

My present thoughts are:
When a form or browse is open, the underlying table is open. (So the enumerated table report is correct.)
But I'm also thinking that for tables, there must be two "internal definitions" of open tables: Those opened within a form, and those opened directly via Xbasic. (And table.close() can only see/act upon the latter.)

Or maybe, because the form/browse has opened the table... It is impossible to access the table to close it. (Because you can not have an open form with a closed table! ~ Now this is starting to make sense to me.) ~If this is the case, a different error [indicating as such] would be much more appropriate.

I think I've got it figured out: Closing a form also closes an underlying table. (But you can't close the table that a form is based on, without closing the form itself.) ~ On this premise, there is no bug, but the [no table found] error returned is a bit misleading, and "subject to misinterpretation."