>Since I worked with remote views a lot in my VFP I got out of the select * habit early.

I was not talking about selecting into the biz layer, but copying newly entered data into the backend again -
as you probably realized ;-) Automatic rewrites of each update statement like the CA does for each changed ro is clearly better,
but a * is better than listing ***all*** fields just for syntax needs

>That said, as I was reading some Julie Lehrman stuff today on EF Code First and doing a walkthrough on the much needed Migrations that are in EF 4.3 caught myself thinking that I had become so comfortable now with TSQL and thinking in terms of workning directly on the backend that while some of the codefirst or even model first stuff is cool, I am still drawn to maintaining DB schema in the database and pushing up to the EF from there.

It is cool only because so much automation is in place. But for me conceptually DD/schema based is clearly superior.
Firmly on Hank's side on this - even if nearly all current fwk/ORM does it the other way.

>As to somebody else maintaining my code ... hey, I"m a hired gun - if they won't hire me to do it ...

I sometimes advise the customer to either let the person responsible for this mess fix it,
or get off my back and let me fix it so it does not break at every change
or has 50 maintainance points for each schema change.

>Apres moi, le tempete merdeux <g>

For similar attitudes the advice is coupled with the hint that such fix
could be argued to fall under unpaid guarantee work,
as the code is below accpeted standards.
Works rather well with large coder for hire groups,
if the customer is one of the whales and has enough balls to demand unpaid fixes ;-)