Question of methodology
 

I work for a small but growing company that is experiencing growing pains. I have been doing the linux work for them since 1998, first as a third-party consultant and now as an employee. I have worked directly with their MS programmer for years with no real issues, but the company is growing and other employee hands are now in the pot. Recently we had a situtation where a few fields were removed from some SQL tables that the website accesses. I wasn't made aware of the deletion for a few days and data on the website was wrong. I was not using all of the fields of the table but the subroutines that I used to get and put data were designed to handle the data line as a whole and not part. I know that I am going to have to change my ways and be more selective in my queries.

Does anyone have any good advice to help me out with changing the way we interact, as we grow? Procedures that you use, policies that can be implemented and inforced?

Needless to say, management is livid about the bad data and wants a solution.

Hmm, I guess a start would be to appoint 1 person as DBA and the only person who can change the database. He/She would then also be repsonsible to inform the users of the database about proposed changes before they are carried out.

Technically I'm not sure. It might be overkill to add routines to check the database meta data first. I.e. see what fields are available...

Mons

Thanks monsm... our current DBA was the one that made the change to the table and didn't pass the information along. I guess what I am looking for is more of a documentation, policy and procedure method that is easy enough to use that is does not deter it's use. (ie. spend more time documenting than programming)

Well, the basic rule is that no columns are to be deleted from the DB without prior consultation with the programmers. A simple email might do with at least 1 weeks notice.
Its actually quite rare to remove columns, usually they get added or amended.
Really there should be a 1 page doc for any 'structural' changes to your system, with agreement from all relevant tech personnel.
Certainly the doc should be signed off by the mgr as well as the DBA. That will ensure the DBA updates everybody.
No changes on a Friday. A short(!) tech mtg every Monday at say 10am to keep everybody in sync.

I know when you started anything not directly tech (ie mtgs/paperwork) seems like a waste of time, but trust me I've worked for every company size and there is a reason for basic paperwork.
Your systems are now too big for everybody to know what's going on, nor should they need to.
Professionalism means keeping the rest of the team, inc mgr, informed (in advance!).