The SETI database seems to have crashed. This problem is not correctly handled by the scheduler, it returns funny messages to the clients :

<scheduler_reply>
<scheduler_version>603</scheduler_version>
<master_url>http://setiathome.berkeley.edu/</master_url>
<request_delay>3600.000000</request_delay>
<message priority="low">Can't find host record Invalid or missing account key.  Detach and reattach to this project to fix this. </message>
<project_name>SETI@home</project_name>
</scheduler_reply>

This advice is plain nonsense of course, detach/reattach will trash work but not fix the database

Try doing what it says; the S@h DB is fine.

---

Try doing what it says; the S@h DB is fine.

Now it is fine, yes, and my client has already reported the tasks.

But when that scheduler message returned, the status page said "Disabled" for the database on jocelyn - so there was probably not even a crash but just a short planned maintenance outage.

If the computer has other tasks from the project still in progress or ready to upload or ready to report and you follow the advice to detach from the project then reattach, how would it be possible not to lose the credit and progress from these tasks?

Or is there a special situation where detaching & reattaching wouldn't have their usual consequences?

Under what circumstances does BOINC advise crunchers (not just from SETI) to detach from a project?

...Or is there a special situation where detaching & reattaching wouldn't have their usual consequences? ...

I highly doubt that - especially as a reattach would not have succeeded with a scheduler that is unable to query the database.

...
Under what circumstances does BOINC advise crunchers (not just from SETI) to detach from a project?

In this situation, it does that when a host is attached using the original ("strong") authenticator and a user lookup by authenticator fails.

There should be a log entry (severity=critical) about that incident, if logging is enabled.

Maybe it would be a good idea, to treat at least CR_SERVER_LOST and CR_SERVER_GONE_ERROR from mysql_query() different than a normal "not found" error.