Script Works, but "Not in Database" when trying to list

I have been asked by a client to modify somebody elses script which the client owns and is modifiable, but when trying to list the script it fails with a message "Not in Database". Since the script in its current form works one presumes SL finds the script to interpret it.
The script does not have a UUID in my Inventory even though it is there and let's me change its Name.
Anybody any ideas how to recover this script.

When scripts get borked like that, they have a way of staying borked :/ There are compiled and source components, and only the compiled part needs to be intact for the script to run. Is the client's copy of the script readable? If so, could they paste the source into a notecard for you?

Sometimes these things recover themselves. The asset servers (or something back there) will notice a not in db error and start some recovery process to try and get it back.

If the problem is still happening in a day, I'd add a support ticket.

That sounds almost like it could be a blacklisted resource. That is, one that LL has actually stripped out of the database because it has been used for extreme griefing or a DCMA take down request or something. I've seen that message before in such circumstances. Hope I'm wrong.

The script is an innocent move object script and what has happened since it was written by somebody else is that the link in Linden's database between the script object that contains the compiled script and the script object that contains the source, which must be loaded for editing, this link has been broken unretrievably, even the UUID identifier has be lost.
The only answer is a complete respecification of the User requirements and rewrite the scrite from the ground up.
Thank you all for your comments.

This particular problem likes to happen when one saves a script but closes the script window before the done message is shown at the bottom of the window.

In that case, the client compiles the script and uploads the binary code but gets no chance to reupload the source code.

Mono will change this behavior due to the compiler being located on the server rather than in the client.

This happens a lot with assets (especially scripts) in attachments. It is a well-known and well-documented bug, and has been for a long time.

Essentially, the asset server "loses" the contents of some attachments, sometimes, with scripts, losing the source code component. I have several scripts in attachments which are now permanently stuck, as I can't access the source code anymore to fix or upgrade them.

http://jira.secondlife.com/browse/SVC-553

In other words, always ALWAYS keep a copy of non-trivial scripts directly in your inventory. Best even to work from those copies and drag them into your objects after each revision.

Funny. Seems it would solve the problem if the client uploaded the source code FIRST. You can always recompile; disassembling/decompiling is another matter.

I had a copy of the lost scripts in my inventory separate from the objects they were in. It didn't make a difference.

My theory is that it has something to do with a buggy reference counting mechanism in the asset database related to attachments.