Joel,

Your boss is actually correct. At times you would work hand-in-hand with the sys admin when applying patches or to fix an emergency, but never inside the server room.

A sys admin migrating code into production seems a little suspect, however. Production is usually its own department, with separate support and administrative groups. The development DBA hands off scripts to a production DBA (after it has gone through Change Management) to be executed on the production server(s).

The amount of documentation that is produced by these separate entities would overwhelm a single person or group who is already responsible for development.

This is the way that many medium-sized IT deparments work. My current client has about 120 people in the IT department and they use this method. Larger departments may have even more layers of infrastructure separating the development DBA and the production systems.

>Hi! I just had a discussion with my boss and he thinks that a DBA (see
>bellow) should not have access to the server room, he thinks also that all
>Service packs and patches on the MS SQL 2000 application side should be done
>by Sys admin, and even more that the Sys Admin are transfering the schema of
>a database from test environment to production mode. Me I don't think that
>way but I would like some comments.
>
>Thanks Joel
>
>Here my boss statement:
>Developer/DBA takes care of the data-model and programs; this does not
>require physical access.
>
>In large installations there is DBA who does not program / develop but works
>on db optimization (part of Sys. Admin group.)
>
>Sys. Admins apply patches to all products and in addition move programs/new
>data schemas to production from development / QA environments
>
>In proper environment; Developers have no “programming” access to production
>systems – in emergency they are issued “special access” by Sys. Admins.