Table Documentation

davegrdavegr Posts: 15
Before using SQL Source Control I would have one script file per object. The file would also contain comments related to function, change history, notes, author etc. The script file would be source controlled.

With SQL Source Control the data for the repository comes from SQL server which doesn't store comments from a CREATE/ALTER table script (as it does for stored procedures).

I would be interested to see how others have handled this situation. I thought of using extended properties but there doesn't seem to be any decent interfaces for managing these in an organized manner? I could use commit comments but these apply to all objects being checked in and also do not seem like the place for object specific comments to be placed.

Thanks

Dave

Comments

  • Hi there,

    Thanks for your post. I guess you could manually check the files out of source control and then just add your own comments into them like you would when developing sprocs. If you then did a "retrieve" from source control using SQL Source Control, the comments should be persisted in the development DB. The next time a table was modified directly in development DB, the comments should then still be there and they can be updated accordingly.

    HTH!

    Pete
    Peter Peart
    Red Gate Software Ltd
    +44 (0)870 160 0037 ext. 8569
    1 866 RED GATE ext. 8569
  • Hi Peter,

    Thanks for the reply.

    I'm not sure if I understand what you are saying. The first part about checking the script out of source control and adding comments is fine but comments from a CREATE/ALTER table script are not persisted in the database. They will only exist in the script file. If I go back to using a script file as my master then there is no need for SQL Source Control.

    I have solved this by using the extended properties to store object information and wrote my own extended property manager so as to be able to maintain the properties efficiently.

    Thanks

    Dave
  • @davegr - have you tried using SQL Doc to add your extended properties. You can add and edit these from the preview screen.

    David Atkinson
    Red Gate Software
    David Atkinson
    Product Manager
    Redgate Software
  • Hi David,

    I hope I'm wrong but SQL Doc only allows one to edit the MS_Description extended property. I don't see anything else that would let me add/change/delete other extended properties.

    I seem to recall some feature requests along this line for SQL Doc.

    Thanks

    Dave
  • Yes, this has been requested before.

    I'm be curious to understand why multiple extended properties are required, rather than just using the one?

    David
    David Atkinson
    Product Manager
    Redgate Software
  • Separate properties allow me to separate the various bits of information so you can then have some automated prcoessing of the meta-data. E.g. I could set a property name to a change request reference and the value would be some description of the change. It would be fairly easy to then get all the objects that were affected by a particular change. Right now I keep this information manually. Yes I could keep all this in one field and search the field for the change reference but this is error prone.

    In the interest of doing more customer development and less tool development I'll use the MS_Description field for now and look forward to you adding support for other extended properties in a future release!

    Thanks

    Dave
Sign In or Register to comment.