Joel D Canfield noted: > 1. One best practice is to never use SELECT * - could someone explain > why, and tell me when this is okay if ever? Right now I am doing this: >>my primary argument is future needs: listing all the columns makes it >>really easy to change from 'select * ' to 'select * except for column >>13' which you can't do. it's also self-documenting. right there in your >>code you've got all the column names, when you come back in six weeks >>to adjust something. Hi Tom, Let me build on Joel's good example. I think many people view 'select *' as lazy or as fast but somehow less than best practice -- but they don't see any real harm to it, right? What could it hurt? ;-) My guess is that this is probably because they may have 'ownership' of the entire data chain from creation to manipulation to loading and reporting. They know everything about the data flow and approve or personally make any changes that happen. They have full control. That's nice. But that's not always the case. Sometimes you are not the only developer working off that data store. Sometimes you are not the only person or the only group who can affect a change to the table structure. That is the case where 'select *' gets scary, and why it's a good idea to give up the practice now. It doesn't "scale" to working on bigger projects with bigger teams ... for potentially bigger money ;-). * Now, right off the bat, if your design depended on a fixed number of columns or on a specific field structure (e.g. "name" is field # 3 or the total number of fields is divisible by four) then any structural table change has the potential to completely flummox your design and break your app ... And pretty much generally trash years of cumulative work. Fun Stuff! * Granted, fields are often added at the end of the table, which can still wreck your design, but usually not as badly. But rework is always fun, right? So let's look at a different issue. * Those newly added db fields may contain confidential information that should not be made available to the audience you are 'select *'-ing to. Consider an extra-net application made available to your suppliers and large customers. If some dba in another part of the company thinks adding supplier credit ratings to this table is a good idea, then _your_ [select * --> display *] application (perhaps written years before the table change) may suddenly expose the company to legal liabilities ... which is not a conversation you want to be on the receiving end of! There are a lot of areas; HR applications, Payroll applications, Finance applications where it may turn out to be MUCH more than merely a bad idea to 'select *'. It's safest to explicitly call out the fields you intend to use. [More readable and better documentation too!] Select * is more than just lazy - it can get you and the company into hot water. HTH, RonL.