tbl.zap() not working for me

[Mike Wilson]

Hello,

I have a need to populate a table (Notecount) starting with the table being empty. I am using the following script which isn't emptying the table for me. Any assistance would be appreciated.

dim tbl as P
dim safety as L

tbl = table.open("Notecount")
safety = .t.
tbl.zap(safety)
tbl.close()

Thanks,

Mike W

[CALocklin]

Re: tbl.zap() not working for me

The "zap" requires exclusive access. (It doesn't have to be opend with File_rw_exclusive as long as the access is exclusive.) My guess is that there's another copy of the table already open.

Try either opening it with:

[COLOR=blue]tbl = table.open("Notecount",FILE_RW_EXCLUSIVE)[/COLOR]

or, better yet, precede the above with:

[COLOR=blue]IF table.inuse("Notecount")
    ui_msg_box( "NOT EXCLUSIVE", "your message here", 16 )
    END'
END IF[/COLOR]

[Mike Wilson]

Re: tbl.zap() not working for me

Cal,
Thank for steering me. The syntax is table.in_use(). So that's likely the answer. My script operates great one time but then not exclusive. Table.enum_open() lists it as open.

dim tbl as P
dim safety as L

tbl = table.open("Notecount")
safety = .t.
tbl.zap(safety)
tbl.close()

A fundemental question I guess I thought I knew the answer to and should know but I guess I don't. Doesn't the line tbl.close() at the scripts end close the table session? How do I close the table so it can be 'not open' and available for use?

Mike W

[CALocklin]

Re: tbl.zap() not working for me

A fundemental question I guess I thought I knew the answer to and should know but I guess I don't. Doesn't the line tbl.close() at the scripts end close the table session?

Yes.

How do I close the table so it can be 'not open' and available for use?

That should do it. HOWEVER, I believe I have seen A5 leave some tables open after certain operations. This may be one of them - I'm not sure and I can't even swear that it wasn't "my fault" when it happened.

All I can recommend is to check very carefully to be sure the table isn't being opened somewhere else.

Edit - perhaps the zap() isn't finished by the time you try to close it??? Maybe a xbasic_wait_for_idle() after the zap will help??? (I don't have a lot of hope for this but it shouldn't hurt.)

[Mike Wilson]

Re: tbl.zap() not working for me

Cal,
Thanks for you thoughts. I had already tried xbasic_wait_for_idle() , x 10 even. Didn�t help. �End� worked, though, so there must be something in the overlap of script execution that inhibits the tbl.close() event.

Arg! My application distributes NOTES one or more of 13-15 different department �Areas�. Each person (unique loginID) is responsible to sign off reading the messages for each Area they have involvement with. This part of the application generates a numeric summary of their unread messages.

I have this writing to a table (the one I want empty for the purposes of being temporary) with 2 fields, Area and Notecount. It starting with a Lookup() to a table with the list of Areas, This generates the variable vareav and uses the following filter to enumerate the number of records in each area they have not signed off on. The signature field is a Memo field (100 + employees).

a5_get_records_in_query("Notes", s_quote((Var->vloginid))+" !$ signature .and. "+s_quote(Var->vareav)+" $ Area")

After the table is created, I have it displayed as a List-List dialog box with OnDoubleClick fetching the Notes of that particular Area for review and sign off..

This temporary table that I cannot ZAP and Close is a major barrier to this entire scheme.

Arg! I guess another approach is needed� And this up until now was working sweet!

Mike W

[CALocklin]

Re: tbl.zap() not working for me

Instead of closing it after zapping, why not just populate the table while it's open? I've done that many times without problems.

If the "zap" isn't in an appropriate place, just move it so that it is immediately before the "populate" routine.

[G Gabriel]

Re: tbl.zap() not working for me

table.zap() is "fineky". I had trouble with it before.

Here are few better alternatives:

a-Create a temp table with xbasic, then delete it altogether, or

b-Duplicate the table (not the records) and delete the one with the records, or

c-If you do not mind shutting down all other tables, before running your table.zap() script, use: a5_forceclosetables() , or

d-Delete a range of records that encompasses all the records:
dim tbl as P
tbl = table.open("........")
query.filter =".t."
qry = tbl.query_create()
tbl.delete_range()
tbl.close()

This will work even if you have Forms/Browses based on the table open and staring you in the face!

Take your pick! I prefer option d.

[Ton Spies]

Re: tbl.zap() not working for me

I prefer gathering information first and then append it to the table.
Just before that I zap that table.

DIM Append as P
tbl = table.open("your_table_name",FILE_RW_EXCLUSIVE)
if (tbl.file_mode_get() = FILE_RW_EXCLUSIVE) then
	tbl.zap(.T.)
else
	ui_msg_box("Zap Data","You do not have exclusive use of the table.",UI_STOP_SYMBOL)
	end
end if
append.t_db = "tmp"
append.m_key = ""

For me it's easy, simple and had never troubles.
And if it should happen I have to gather my information again in 'temp' file "tmp.dbf"

Just as Cal stated I open a table and work with it after zapping.
And I wonder why should I close all other tables while zapping one table.

my 2 cents

Good luck

Ton Spies

[martinwcole]

Re: tbl.zap() not working for me

report it as a bug

[Dave McCormick]

Re: tbl.zap() not working for me

I've recently built some scripts with lots of operations in them. I found that sometimes A5 does in fact not seem to close tables when it's supposed to, and I would get errors telling me table was in use.

However, I found a good workaround (suggested by Ira Pelow at the user's conference).

Create each operation as a Separate function and then call the functions in your script. I have never had any problems with that technique, and I regularly run a script that performs almost 80 sequential operations using dozens of tables... These operations include pack's and zap's, which require exclusive access.

This technique also kept my master script much neater, and made trouble shooting considerably easier. Better still, if I needed to repeat an operation, I could do it with one line of code. (Thanks Ira!)

(It also seems to run faster... but I could be imagining that.)

dm

[Mike Wilson]

Re: tbl.zap() not working for me

Thanks all,

This gives me a few leads to work on. One will surely emerge successful. And then as I'm using Table.enum_open() to check the table status, I discover another table won't close issue I've spent the day with. Posted separately.

Mike W

[csda1]

Re: tbl.zap() not working for me

However, I found a good workaround (suggested by Ira Pelow at the user's conference).

Actually Dave, it is not a workaround, it's a better methodology.

And what you said is another independent validation that those who use UDF's over scripts operate more reliabily and have few problems with synchronous issues. I NEVER use XBASIC_WAIT_FOR_IDLE() and the like, and never have issues. Could it be that I use functions almost exclusively? Ya think?:)

(It also seems to run faster... but I could be imagining that.)

Global Function calls (UDF's) overhead is about 15 times faster than running Script_play("scriptname"), so yes, it is faster. Of course the code itself operates at the same speed with either.

[DaveM]

Re: tbl.zap() not working for me

From the days of clipper: If you use more than one time for a different form, report etc., write a script.

Dave
www.lotrun.com

PS I don't miss clipper!