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.

The Strangest Bug 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The better DBA's I've worked with have been able to extract a healthy pile of clues from the admin tools provided with SQL Server (e.g., who has what locked).

    Since you're dealing with a single row in a single table, my number one cause of mystery grief on SQL Server--row locks getting escalated to page locks--probably isn't an issue.

    • dws wrote: The better DBA's I've worked with have been...

      Ovid replied: ha, ha, ha, grunt, snort, ha!

      We let our "DBA" go on the grounds that we couldn't afford him. That's true because while he might have been qualified to be an intern, he certainly wasn't qualified to be a senior DBA. He lied his @$$ off on his resume and when he was hired, no one was capable of evaluating his performance -- not surprising given that this company once hired a CTO who didn't know what FTP was. Then I returned to

      • "If you need to change it, you can just write a script to change all of the instances of it!"

        Hmmm...

        Actually, you could remove a layer of indirection by eliminating the username entirely. That way, if it changes, you don't have to update anything at all. You'll still be able to refer to users by other unique fields. The probability that any two users have the same hire date and birth date is probably sufficiently low ...and if not, you can just throw in more fields until you eliminate the duplication.

        The
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.