>> I just got curious myself about the topic and shared some thoughts about it. <<
I appreciated the links.
Since you are an advanced user and I am a newbie to Strataframe, would you mind looking at my posts about my problems with my parent-child relationship. This one smells like the same sort of nuance as the SET NOCOUNT ON issue, but I have no idea what it could be. Apparently, Strataframe thinks that the field luphdr_fk is not defined in the child business object, but I swear to god, it really is.
Yeah, I got your point. And I agree with you. I just got curious myself about the topic and shared some thoughts about it.
>> Just some thoughts that I found about SET NOCOUNT ON. <<
I realize that these sorts of issues can become religious issues and, not being a SQL Server DBA, I am not qualified to comment. My only point was that this should be clearly documented in the Strataframe documentation. I found it quite by accident.
Just some thoughts that I found about SET NOCOUNT ON.
http://petesbloggerama.blogspot.com/2006/10/note-to-self-set-nocount-on-not.html
http://drowningintechnicaldebt.com/blogs/royashbrook/archive/2007/07/17/why-quot-set-nocount-on-quot-sucks.aspx
Memorial Day??? Wishful thinking - the summer is ending, not beginning
My only real complaint about the framework is the poor documentation. Andy has been working as a SQL Server DBA for the last few years, so he writes all my SPs. Best practices dictate setting NOCOUNT ON at the beginning for performance reasons. Well, it is not documented anywhere that the framework requires that NOCOUNT be set OFF in order to handle saving data. Mentioning this little nuance in the topic on Table CRUD Stored Procedures might be a good idea, don't you think?
We also noticed that framework calls SP_ExecuteSQL directly - this is a real no no from a security standpoint. I wonder if the framework breaks if the DBA denies access permissions to system stored procedures and tables.
How do I set this up so that I can actually do this?
TIA
Marcia