Errcode: 13, can't delete *.myi

[Guest_imported]

I'm throwing together a MYSQL/PHP/VB Frankenstein's monster to help some friends at my old alma mater manage an online catalog for their departmental library.

I'm having an odd problem with a batch .sql file used to delete all tables from a database provided as a coutesy to the System Administrators.

Specifically, sometimes some of the tables will not be deleted in a DROP TABLE statement because of:

Errcode: 13 Could not delete tablename.myi.

What's truly odd is that its not consistent about which tables it will refuse to delete.

Any insight?

 

[sleipnir214]

On what platform is your MySQL server running?

 

[Guest_imported]

Apache on my Windows Desktop as a development environment. It's ultimately going to be shipped off to some kind unix, hence the batch sqls.

 

[sleipnir214]

The deletion of tablename.myi may be related to file locking, both from within MySQL and by the filesystem itself.

Files with the .myi extension are files that contain indeces for MyISAM-type tables. When you drop the table, the index file has to be deleted. But if someone else has an operation pending that will require that index, MySQL will not release it. Also, Microsoft is known to do squirrely things with file locking in general because the locking mechanisms of their OSs are know to be primitive.

How are you issuing the drop commands?

 

[Guest_imported]

I'd guessed that the problem was with the indexes, but it really can't be because of any pending action against them, because the tables are empty, and the PHP front end and the VB administrator have yet to be written. The only connections open to this database are the MySQL Admin tool for windows and the instance of DOS MySQL I'm using to drop the tables.

The table deletion script is only important in so far as it helps test the efficacy of the the table creation scripts. Will just shutting down the Server and trashing the .myd, .myi and .frm files by hand get the job done?

 

[sleipnir214]

Do not just delete the files.

Does that admin tool use ODBC to access the server? There are known issued with Win32 and ODBC and "drop table".

If so, one workaround is to issue a "flush tables" before each drop.

Another is to shutdown then restart the server then issue the commands to MySQL without using ODBC.

 

[Guest_imported]

Yes, the Admin tool does use MyODBC. I'll proceed as you suggest.

Thank you good sleipnir, you are as wise as you are multilegged.

 

[Guest_imported]

I'm just confirming that the workaround you recommended did solve my problem, thank you very much.