Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • What sort of database? Is each table a file?

    If so...

    Is it possible that an earlier instance of the script crashed or was interupted while it had that file open? Can you read the file in a text editor, or does NT give you an error?

    Do you see different behavior depending on whether you read/copy the file on the local machine vs via filesharing?

    If you can't read the file from a share (and possibly locally), it may be that Win thinks the file is in use, possibly by a crashed/interupted previous instance of the script (or maybe the script was fine, but Win just spaced out and forgot to remove the busy/lock note).

    In that case, re-booting will solve the problem. Reboot, and you'll be able to read the file again.

    Warning: if the contents of the file are screwed up, it is possible that the next time your script runs it might fail when trying to read the file and crash, leaving the file in the same messed up state (you can't access it until you reboot), so check the file contents after reboot before you run that script again.

    I ran into this with DBD::AnyData (CSV files) shortly after moving a project to a new win2K server. I don't know what caused the initial corruption, but from that point on, any time the script tried to touch that file, everything went kaboom and the file was foobar until the next reboot.

    The only symptom was that one day the script stopped working for most varieties of functionality. It took a bit of digging to find out that it failed on accessing a specific file, and then since we couldn't get in the file, it took a bit longer to realize what was going on.

    If this is happening to you, there may be other files which were horked at the same time... Any file which was open when the script crashed is suspect. Hopefully only the file-lockeness will be screwed up, but it might take a few reboots to be able to continue debugging to find which file had the corrupted content. You may have to wade through several files that have normal content but just got locked by the script crashing.

    Or maybe this is nothing like what you're seeing...

    Good luck :)

    Post to let us curious minds know how it turns out!

    -matt
    • The database we're using Microsoft SQL Server 2000. We stopped and restarted that server and, before anything else could touch the database, we successfully dropped the table. I've added it back and everything seems to work perfectly. Of course, we haven't done any load testing on the new table, so it might be a bug waiting for its opportunity to bite. It's extremely frustrating that we cannot find any logs anywhere which refer to this table or what the problem might be.

      I've double-checked the code wh