Since I worked with remote views a lot in my VFP I got out of the select * habit early. Maintaining the SSIS that uses SPs is really nice compared to trying to maintain the VBA scripts that some of the guys were using. Of course the whole thing is limited in that these particular packages are running on SQL 2005 so both BIS and any ability to run the TSQL in debug mode are iimited.

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.

I really believed set based processing was some ancient thing that nobody who knew how to work in a procedural language would even use but I have to say I am getting a more balanced view of strengths and weaknesses of each.

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

Apres moi, le tempete merdeux <g>

>>Thanks Sergey. I did think of that but it means either generating a new set of identity keys ( not sure if in the long run that will be problem or not on this table ) or I guess turning off indentity while doing the insert ( never did that on the fly so don't even know if that is possible.)
>
>Do yourself a favor:
>imagine the maintainers after such change being able to set rewards on your head (***not*** including alive).
>As I have to babyset such a system, I regularly wish for such ability as a job benefit...
>
>>Since you haven't suggested a magic bullet version of the code below <g> I will assume I should just stop being lazy and write the update properly, specifiying all the possibly changed columns.
>
>This is not about the lazyness of creating the longer line,
>but my main gripe with pure SQL based coding when compared to some wrappers/patterns
>like ActiveRecord, CursorAdapter or ADO.Net is,
>that the update / merge commands need the equivalent of insert into () select *,
>as this is the part where manual changes after schema changes are likely to miss something.
>
>>It's funny , coming from a heavily procedural mindset in VFP and C# I didn't realize the power of set based thinking until this project pushed me out of my comfort zone and I started to learn and do things in T SQL I had not attempted before.
>>Now I see why Denis Gobo and some of the other guys I work with are so comfortable accomplishing some pretty cool stuff on the back end when my first impulse is to start looping through records in my business objects.
>
>Otherwise only masochists would code set based ;-)
>But that omission rankles...
>
>regards
>
>thomas