Okay I think there are resons for SELECT * and I see where a LEFT/RIGHT would be useful on a very complex JOIN; joing 4 - 8 tables, but I always have a key match. That's probably why I wasn't seeing the point. I design my tables so that every key for related data is on the table. Unless like with that contact type field I cut a corner.

If I have Contacts and Employees and an employee is a contact I have a contact key in the employee table. If I have a Sales Rep who is an employee I have a contact and an employee key on the SalesRep table. Now this is easy if you are starting from scratch but I can see and remember it being a @#$%^&*( when working on a long standing data center with 300+ tables. My little app only has 40 though and maybe will get bigger.

As far a SELECT * what if I have a data object that loads info from a table. I have a stored proc that SELECT * FROM X WHERE key = @key. If I add fields I don't have to worry about updating that query. I have to update my UPDATE, INSERTand my object. It's one less thing to worry with. CRUD sucks any way you look at it, why not save myself a little time..?

I rarely want all the data returned unless there is a key match. I don't have any major reports on this app, but yes I know what you mean now. It came back to me. It's a must for proper reports to use LEFT. RIGHT does suck. I just remebered a join I had to write from Sales Reporting about 4 years ago. That thing was evil. it was DB2 also. Ahhhhh DOS