Search results

I can't find any solution to release the locking. But somehow, I found an alternative which is equivalent to "DoCmd.OutputTo". As of now, "DoCmd.TransferSpreadsheet" will do the job. I can drop the table now after exporting the report.

I doubt it would work. I guess you forgot to mention where the DoCmd.OutputTo should took place.

I've attached a test database. It contains 2 tables and 1 report. Open and close the report, table1 should be dropped. Rename the 2nd table to "TABLE1" and open the report, this time click that button to export the report (to excel). Close the report and you will be greeted by ERROR3211.

I'm not sure how the DoEvents could unlock the table. I already tried inserting the DoEvents after the DoCmd.OutputTo line, nothing changed. DoCmd.OutputTo command still holding the table. I've seen some suggestion from the net as what you've suggested, neither it solved their problem.

The locking happens only when I am trying to execute DoCmd.OutputTo. Opening and closing the report doesn't raise this Error. It dropped the table successfully. I am the only user of this table. It is still under develop. "No locks" is the default setting.

Hi! Why DoCmd.OutputTo acOutputReport is locking the table even though the report was closed? Is there a way to release the table and initiate a drop table query? Note: I need to keep the file that was exported.

Instead of true or false, is it possible to get the actual returned code for that three scenarios?

Regardless of which selection, all returned true except pressing cancel from an API prompt.

Your code returns only boolean, but i wan't to capture according to user's selection. What will be the return value if user select each of the following. 1. Copy and Replace 2. Don't Copy 3. Copy, but keep both files Thanks.

You've nailed it!

Thanks man. I was aware prior posting this question hoping for an answer or an alternative.

Anyhow, I appreciated your effort. While waiting from someone who might have the turn around better research an alternative a shell copy I guess.

Not really, I googled prior throwing question in this forum. I was aware though that once the process started i't can't be stopped. That's the purpose of coming here at the first place rather than leaving it behind just like that. I persist that somehow there might be some better approach than...

That's it? What you see is what you get? C'mon man, that's where "professional programmers" thing come in to play, at least there might be an alternative than just letting the user bleed.

Have you put in to consideration by clicking that "YES" button, user tends to get bored and will decide to abort the process?

Please elaborate "proper coding and contingency measures would strip out the need to ever do it", if you are copying 1 huge file to a server? If you don't mind.

Not at all, I need somehow that a user could interrupt during the copy progress just as how windows simulate it.

Hi! Please share your thought or a link to a discussion with code samples as to how to achieve this simulation. User intervention to abort Scripting.FileSystemObject CopyFile() with a button.

Ohh, I see thank you!

Well, I hope I'm good as you. If you don't mind to lend me a link, i'll be grateful. Thanks