Post reply

Documenting EVERYTHING

  • August 16, 2007 at 6:07 pm

    #153753

    I have just been blind-sided by not one, but two, consulting firms who are pointing fingers at each other, and me, as to blame for poor performance on a server.  In order for me to start making sense out of things, and hopefully getting everyone to play nice together, I am in desparate need for documentation surrounding two of my SS2005 servers and all objects, specifically the databases, tables and structures.  Is there anything that can just "dump" this kind of information into some type of file that I can use for documentation?

     

    I'm in a 'free-fire' zone, everyone's shooting at everyone else, and everyone else is to blame for the problem.

  • August 16, 2007 at 8:15 pm

    #727527

    Quick and easy.  Visio does a pretty good job.  All of the Designer tools Erwin etc do it.

  • August 17, 2007 at 12:04 am

    #727543

    Hi

    In case you cannot use 3rd party tools SQL server DMV's and system tables can give out a fair amount of information.

    "Keep Trying"

  • August 17, 2007 at 2:26 am

    #727566

    Have a look at SQL Doc from Red Gate (disclaimer: I work for them).

    Regards,

    Andras

    Andras Belokosztolszki, MCPD, PhD
    GoldenGate Software

  • August 17, 2007 at 7:09 am

    #727624

    Rather than just free form 'dump' everything, why not design what your documentation requirements are. In particular, if you want to stop the shooting, ask (not demand) of your consultants to reconfirm their documentation is correct - it's a piece that they own and are responsible for. Then, ask them what you need to provide in supporting documentation to prove it's NOT their fault. Suddenly, you're offering to help them cover their butts - how can they refuse an offer of help? All you want is to document what you have - that's your incentive.

    Their answers will cover several points for you: 1. competency - do they know what they are talking about? 2. completeness - what aspects of the system are they aware of? 3. tool kit - they may send you a tool and ask you to run it and provide them with the results - if it's a pure (neutral) 3rd party tool that they haven't messed with, ok. If they ask you to run a query, then you can vet it to ensure it will do no harm before running. 4. if will help define a basis on which to have a rational discussion of what the current state of the system is, and what it should be.

    it's possible that the consultants require conflicting environmental settings - rather than that someone 'screwed up'.

    Good luck!

  • August 17, 2007 at 7:18 am

    #727630

    Steve -

     

    Already been through that.  The issue is that the project is going badly and both are loosing money because their work was on a fixed bid.  They are right now looking for any excuse to get paid for any additional work they can blame on someone else, or at the least get out of the project.  This is just not a good situation.

  • August 17, 2007 at 7:28 am

    #727633

    1. Documenting what the system has now, just as a record and to support future comparisons: Use a manager tool to script EVERYTHING you possibly can. Be prepared for a very large, verbose, inconvenient file.

    2. You didn't specify whether this is truly SS2k5 or other environment; you'll need to also document the hardware, OS, etc.

    3. Do you have a version control procedure for when the contractors want to introduce new versions of their stored procedures, UDFs, etc.?

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply