[documentation] Draft (please comment): Can't open file: 'TABLE.MYI' (errno: 145)

Anisa mystavash at animecards.org
Fri Nov 10 16:52:00 UTC 2006


On 11/10/06, Gary Feldman <dpal_gaf_doc at marsdome.com> wrote:
>
> Anisa wrote:
> > ...
> >
> >     > errno: 145 is a MySQL error.
> >     >
> >     I think there needs to be some context around this.  How did the
> user
> >     get to this FAQ item?  Searching for "errno: 145"?  Or searching for
> >     "user error: Can't open file"?  The reason is that people are often
> >     intimidated by error messages, so some help in just reading this (as
> >     in:  If you see "(errno: nnn)", where "nnn" is some number, then
> >     this is
> >     a MySQL error).  But I don't think that sort of help belongs here.
> >
> >
> > But I feel very relieved when I look in the troubleshooting faq, or
> > indeed, anywhere in the handbook, when there is something with just
> > the right title.  :)
> So do I.  The problem is that the right title for you may not be the
> same as the right title for me.
> > What I did with the duplicate error faq was to have a short and long
> > explanation.  Would that do?
> I think I'm not explaining myself well, because I don't see how that
> would address the point I'm raising.
>
> One difference between this and the duplicate entry FAQ is that there
> are a variety of errors that can occur with regard to being unable to
> open a file.  Suppose there's more than one FAQ on this subject.  How
> will the user find the right one?
>
> Or suppose the user starts looking in the FAQ under "user error" (since
> that's the first part of the message), can't find it, and gives up?


I would be happy to add user error, it's in my original original draft, but
it made the subject of this message too long so I cut it out (long subject
titles are a pet peeve :).

The current FAQ is thoroughly unorganized.  A handful of them have
> actual fragments from error messages in their titles.  By putting this
> into context, I was thinking more along the lines of having a section of
> the FAQ dealing just with error messages, with perhaps the first entry
> being how to figure out whether the message came from MySql, PHP, or
> Drupal.


So it would!  But I don't know how to write that.  :(  I basically just saw
this problem in the forum and thought it'd be an easy page to add.

>     ...
> >     I think there should be some more information, for people who know
> >     nothing about databases.  Something like "Databases store
> >     information in
> >     tables, which are kept in files.  Do you see 'accesslog.MYI ' in the
> >     message? This file is used for the table named 'accesslog'
> >     (without the
> >     .MYI).  This is the table that has a problem.  Fortunately, MySQL
> >     has an
> >     operation to repair tables.  You can invoke it with phpmyadmin as
> >     follows:...
> >
> >     ...
> >
> >
> > I think anyone who is USING drupal should know what the heck a
> > database table is.
> I suppose, though from some of the questions that get asked in the
> forums, I'm not so sure.


:)  Quite!  So no assuming.

 But at a minimum, I think it should say that
> the filename 'accesslog.MYI' corresponds to the MySql table named
> accesslog.


I think if you are going to say it is a filename, you have to also say that
it's not a file that the person would actually have.

> When is this useful or possible?  I get the impression it's only for
> > when certain tables are corrupted.
> >
> I would think that's it's only for corruption at the MySql level (which
> I've never had happen), as opposed to being perfectly good as far as
> MySql is concerned, but having bad data as far as Drupal is concerned.


So repairing tables will fix this error all the time?

Anisa.


-- 
*********************************
www.AnimeCards.Org

16,000 scans and counting!
*********************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/documentation/attachments/20061111/a89893b9/attachment.htm 


More information about the documentation mailing list