Introduction
Real programmers don’t document their code.
This and many other phrases, one can hear when it comes to documentation. And if you’re really serious about making life of your co-workers, clients, and anyone else who will maybe read your code, harder than it already is, take your time and read carefully through this ultimate step-by-step guide How to write unmaintainable code.
While you shouldn’t take the above too seriously, there seems to be some truth in that developer and documentations are natural enemies. Be that documentation of the code itself or documentation about some application. I have seen quite a few documents written by developers that were supposed to be handed to the customers as some sort of manual or reference material. Many times, though certainly not always, you can nothing but agree with C.J. Date: “Good writing DOES matter!” The lack of precision in many technical writings is significant. Fortunately the metadata of an SQL Server database cannot be imprecise. So, at least documenting a database isn’t subject to imprecision when one refers only to the databases’ metadata and now one only needs time to actually do this job. But why spend more time on it than is absolutely necessary?
Purpose
The purpose of this paper is to show you, how ApexSQL Doc can make your life a little bit easier (at least with respect to that unwanted task of documentation) and save you a lot of time that you can spend more effectively otherwise. And I’m quite sure that you agree with me that every single hour spend less on documentation is worth almost every effort.
Why to document anyway?
Challenging question, hm? 😉
Of course, there are tons and tons of possible valid answers to this question:
- Company requirements
- Legal requirements
- Contractual requirements
- Structured methodological work approach
- CYA strategies
- …
Fact is that almost everything we do needs to be documented, either because one wants to keep such things for ones own purposes, or because someone in the food chain above us ask us to do so. My personal favourites in that respect are internal auditors, btw. Each time our department had such an internal audition we ended up documenting more things less people are actually interested in. I guess this probably sounds kind of familiar to one or two readers of this paper, but that is another endless story anyway. Now for something completely different…
Installation, System Requirements, supported SQL Server versions
As with all other ApexSQL tools, you can visit the ApexSQL homepage at http://www.apexsql.com and download a fully functional 30 days evaluation copy of their Doc tool. The download is just about 8 MB in size, so manageable even with a slower internet connection. Installation itself is just a matter of minutes.
The system requirements for ApexSQL Doc are as follows:
|
Software: |
ADO 2.8 (or higher) |
|
Operating System: |
Windows 2000 |
|
CPU: |
PC at 450 MHz (or faster). Pentium III recommended |
|
RAM: |
256 MB RAM (512 RAM recommended) |
|
Hard Disk Drive Space: |
30 MB |
As you can see, ApexSQL Doc requires MDAC 2.8 and the .Net 2.0 runtime. Both are not included in the software package, so you need to install them manually before installing the tool. If you don’t have both Pre-requisites already installed on your machine, you can get them from here:
Within this 30 days trial period, the only thing reminding you of that trial is a start-up dialog:
After the 30 days trial period expires, the software stops working and you have to decide, how to proceed. In case, you decide to buy the software, check out the latest pricing information available on the ApexSQL homepage.
This is now the 3rd ApexSQL tool I know and just like the other two, ApexSQL Log and ApexSQL Clean, I haven’t experienced any difficulties getting familiar with the software. Its overall appearance has the same “Look and Feel” as the other aforementioned tools, and so you find yourself comfortable with the software after just a few hours of use. However, this time things are a little bit different….