>
> "The bit I'm struggling to understand is why you need to use a stored 
> procedure for the insert operation"


OK. Let me explain something.

1. My application is WinForm type.
2. It uses mssql-server built-in security mechanism. Everyone has the 
appropriate sql-server user. Each user assigning specific sql-server roles. 
Which in turn have the right to execute certain stored procedures.
3. In the stored procedure it is possible to examine additional security 
conditions (for example, possibility of the user to create(insert) document 
by additional condition) and to perform additional operation.

You may ask - why it can not deal with the application itself? Because of 
Reverse-Engineering (every-one can see .net code by using ILSpy or 
Reflector tool). And begin to connect to the server using something such as 
"Management Studio" and do everything that pleases. And that's just the 
above-mentioned mechanism will not allow him to do so.

And by the way: "sql server - stored procedures advantages and best 
advantage" [
http://blog.sqlauthority.com/2007/04/13/sql-server-stored-procedures-advantages-and-best-advantage/
]


If that isn't the case then I think that your initial requirement 
> (population of the CreateDate column by the DB server) can easily be met by 
> just mapping the CreateDate property as 'generated' and applying a default 
> to the column? 



I knew nothing about this feature. But thanks any way.


So, am I do something wrong? How do you make security strength and 
performance applications?


Понеділок, 29 квітня 2013 р. 17:25:20 UTC+3 користувач PeteA написав:
>
> The bit I'm struggling to understand is why you need to use a stored 
> procedure for the insert operation - is there a lot of logic in this 
> procedure that's hard to handle elsewhere?  If that isn't the case then I 
> think that your initial requirement (population of the CreateDate column by 
> the DB server) can easily be met by just mapping the CreateDate property as 
> 'generated' and applying a default to the column? 
>
>
> -----Original Message----- 
> From: [email protected] <javascript:> on behalf of 
> [email protected] <javascript:> 
> Sent: Mon 4/29/2013 8:26 AM 
> To: [email protected] <javascript:> 
> Subject: [nhusers] Re: OUTPUT parameters in stored procedure. 
>   
> OK 
>
> I asked "why???" because I really didn't understand why. 
>
> I have another idea how to retrieve what we want and don't use OUTPUT 
> parameters. 
> What if to sql-insert add another attribute (list of properties). Example 
> (mapping by code): 
>
>     m.SqlInsert("exec dbo.document_insert ?,?,?,?,?", new[] { 
> t.CreateDate, t.EditDate }); 
>
> And  at the end of "document_insert" write this: 
>
>     SELECT SCOPE_IDENTITY, @CreateDate, @EditDate 
>
>
> I think it's elegant way of  problem solving. 
>
> So, what will you say? 
>
>
> ?????????, 22 ?????? 2013 ?. 22:08:42 UTC+3 ?????????? 
> [email protected]???????: 
>
>         I know nhibernate doesn't support output parameters? but I don't 
> understand why. 
>          
>         Why I can't write something like this: 
>
>         <class name="Document"> 
>            ... 
>           <sql-insert>exec createDocument ?,? OUT,?,?</sql-insert> 
>           ... 
>         </class> 
>
>         I think it's very easy to implement. 
>
>         Now, for data access code I'm using pure ADO.NET. And my 
> "documents" table has "CreateDate" column, which is set by server, and 
> returns to my application by output parameter of stored procedure. 
>         I know I can set "CreateDate" property of my POCO class manually 
> but i don't want do it because I can't accurately synchronize client clock 
> to the clock of server. 
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "nhusers" group. 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] <javascript:>. 
> To post to this group, send email to [email protected] <javascript:>. 
>
> Visit this group at http://groups.google.com/group/nhusers?hl=en-US. 
> For more options, visit https://groups.google.com/groups/opt_out. 
>   
>   
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/nhusers?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to