blocks|key|454789|text|尽管IdeaBlade+forums已经对新的活动关闭，但它们仍然是可搜索的，并且确实经常包含关于DevForce问题的有用答案和信息。在这种情况下，如果你在那里搜索context_info，你会找到一些有用的线程。其中一个特别展示了如何使用EF+Provider+Wrapper+Toolkit或EF+6+DbCommandInterceptor与context_info一起工作。这些不需要DbContext。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|454790|entityMap|0|LINK|mutability|MUTABLE|url|http://www.ideablade.com/forum/forum_topics.asp?FID=54&title=devforce-2012|1|http://efwrappers.codeplex.com/|2|http://satalketo.com/2013/12/logging-sql-queries-mvc/^0|2|G|0|3D|R|1|45|P|2|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]|$A|T|B|U|1|V]|$A|W|B|X|1|Y]]|C|$]]|$1|D|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]|N|$5|G|H|I|C|$J|O]]]]

Although the <a href="http://www.ideablade.com/forum/forum_topics.asp?FID=54&amp;title=devforce-2012" rel="nofollow">IdeaBlade forums</a> have been closed to new activity, they are still searchable and do often contain helpful answers and information regarding DevForce issues. In this case, if you search for context_info there you will find some useful threads. One in particular shows how to use either the <a href="http://efwrappers.codeplex.com/" rel="nofollow">EF Provider Wrapper Toolkit</a> or <a href="http://satalketo.com/2013/12/logging-sql-queries-mvc/" rel="nofollow">EF 6 DbCommandInterceptor</a> to work with the context_info. These do not require a DbContext.

blocks|key|916587|text|我们需要为我们的应用程序做同样的事情。正如Kim提到的，在Dev+Force论坛上有很多信息。你可以找到我们所做的in+this+forum+post的完整解释，但我将在这里重现重要部分以供参考……|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|916588|我们在应用程序中也有类似的要求。在我们的示例中，我们需要在每次打开数据库连接时调用一个自定义存储过程-该过程将使用当前活动的用户‘标记’该连接，因为我们有许多需要知道当前用户的触发器(我们使用context_info来完成此‘标记’)。|916589|我们能够在EF+Provider+Wrapper+Toolkit+(现在似乎也在Nuget上)的帮助下处理这个问题。这基本上允许您将自己的逻辑注入到各种ADO.NET对象中-因此在最低级别的数据库访问中也是如此。然后，我们创建了自己的自定义DbConnection类，供DevForce/EntityFramework最终使用。它实际上非常简单，并且为我们提供了许多很好的“钩子”到最低级别的数据库访问，这已经派上了很大的用场。|916590|下面是我们的自定义DbConnection类的一些示例代码，它显示了您可以完成的各种事情：|916591|///+<summary>
///+Custom+implementation+of+a+wrapper+to+<see+cref="DbConnection"/>.
///+Allows+custom+behavior+at+the+connection+level.
///+</summary>
internal+class+CustomDbConnection+:+DbConnectionWrapper
{
++++///+<summary>
++++///+Opens+a+database+connection+with+the+settings+specified+by+
++++///+the+<see+cref="P:System.Data.Common.DbConnection.ConnectionString"/>.
++++///+</summary>
++++public+override+void+Open()
++++{
++++++++base.Open();

++++++++//After+the+connection+has+been+opened,+do+our+logic+to+prep+the+connection
++++++++SetContextInfo();

++++++++//...and+we+do+some+other+stuff+not+relevant+to+this+discussion
++++}

++++///+<summary>
++++///+Closes+the+connection+to+the+database.+This+is+the+preferred+method+of+closing+any+open+connection.
++++///+</summary>
++++///+<exception+cref="T:System.Data.Common.DbException">
++++///+The+connection-level+error+that+occurred+while+opening+the+connection.
++++///+</exception>
++++public+override+void+Close()
++++{
++++++++//Before+closing,+we+do+some+cleanup+with+the+connection+to+make+sure+we+leave+it+clean
++++++++//+++for+the+next+person+that+might+get+it....

++++++++base.Close();
++++}

++++///+<summary>
++++///+Attempts+to+set+context_info+to+the+current+connection+if+the+user+is+
++++///+logged+in+to+our+application.
++++///+</summary>
++++private+void+SetContextInfo()
++++{
++++++++//See+if+a+user+is+logged+in
++++++++var+user+=+Thread.CurrentPrincipal+as+OurCustomUserType;

++++++++//If+not,+we+don't+need+to+do+anything+-+this+is+probably+a+very+early+call+in+the+application
++++++++if+(user+==+null)
++++++++++++return;

++++++++//Create+the+ADO.NET+command+that+will+call+our+stored+procedure
++++++++var+cmd+=+CreateCommand();
++++++++cmd.CommandType+=+CommandType.StoredProcedure;
++++++++cmd.CommandText+=+"p_prepare_connection_for_use";

++++++++//Set+the+parameters+based+on+the+currently+logged+in+user
++++++++cmd.CreateParameter("as_session_id",+user.SessionID,+null,+DbType.Guid);
++++++++cmd.CreateParameter("ai_user_sid",+user.UserID,+null,+DbType.Int32);

++++++++//Run+the+SP
++++++++cmd.ExecuteNonQuery();
++++}|code-block|syntax|javascript|916592|在EF6和更远的地方，可能有一种更干净的方法来拦截数据库calls....but这种方法多年来一直运行得很好。|916593|entityMap|0|LINK|mutability|MUTABLE|url|http://www.ideablade.com/forum/forum_posts.asp?TID=3855&PID=15476&title=value-cannot-be-null-getting-ientityqueryt-when-using-usepersistentdbconnectionpersession#15476|1|http://efwrappers.codeplex.com/|2|http://nuget.org/packages/CommunityEFProviderWrappers.EFProviderWrapperToolkit^0|1L|I|0|0|0|5|R|1|14|5|2|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@$A|13|B|14|1|15]]|C|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|17|8|@]|9|@$A|18|B|19|1|1A]|$A|1B|B|1C|1|1D]]|C|$]]|$1|H|3|I|5|6|7|1E|8|@]|9|@]|C|$]]|$1|J|3|K|5|L|7|1F|8|@]|9|@]|C|$M|N]]|$1|O|3|P|5|6|7|1G|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|1H|8|@]|9|@]|C|$]]]|R|$S|$5|T|U|V|C|$W|X]]|Y|$5|T|U|V|C|$W|Z]]|10|$5|T|U|V|C|$W|11]]]]

We needed to do this same thing for our app. As Kim mentioned, there is a lot of information in the Dev Force forums. You can find a full explanation of what we did <a href="http://www.ideablade.com/forum/forum_posts.asp?TID=3855&amp;PID=15476&amp;title=value-cannot-be-null-getting-ientityqueryt-when-using-usepersistentdbconnectionpersession#15476" rel="nofollow">in this forum post</a> but I'll reproduce the important parts here for reference...

We had a similar requirement in our application. In our case, we needed to call a custom stored procedure every time a DB connection was opened - the procedure would 'mark' the connection with what user was currently active because we have lots of triggers that need to know the current user (we use context_info to accomplish this 'marking').

We were able to handle this with the help of the <a href="http://efwrappers.codeplex.com/" rel="nofollow">EF Provider Wrapper Toolkit</a> (also seems to be on <a href="http://nuget.org/packages/CommunityEFProviderWrappers.EFProviderWrapperToolkit" rel="nofollow">Nuget</a> now). That basically lets you inject your own logic into various ADO.NET objects - so at the very lowest level of database access. We then made our own custom DbConnection class that DevForce/EntityFramework end up using. It was actually pretty easy and has given us a lot of nice 'hooks' into the lowest level of database access that has come in handy a lot.

Here is some sample code for our custom DbConnection class that shows the kinds of things you can accomplish:

<pre><code>/// &lt;summary&gt;
/// Custom implementation of a wrapper to &lt;see cref="DbConnection"/&gt;.
/// Allows custom behavior at the connection level.
/// &lt;/summary&gt;
internal class CustomDbConnection : DbConnectionWrapper
{
 /// &lt;summary&gt;
 /// Opens a database connection with the settings specified by 
 /// the &lt;see cref="P:System.Data.Common.DbConnection.ConnectionString"/&gt;.
 /// &lt;/summary&gt;
 public override void Open()
 {
 base.Open();

 //After the connection has been opened, do our logic to prep the connection
 SetContextInfo();

 //...and we do some other stuff not relevant to this discussion
 }

 /// &lt;summary&gt;
 /// Closes the connection to the database. This is the preferred method of closing any open connection.
 /// &lt;/summary&gt;
 /// &lt;exception cref="T:System.Data.Common.DbException"&gt;
 /// The connection-level error that occurred while opening the connection.
 /// &lt;/exception&gt;
 public override void Close()
 {
 //Before closing, we do some cleanup with the connection to make sure we leave it clean
 // for the next person that might get it....

 base.Close();
 }

 /// &lt;summary&gt;
 /// Attempts to set context_info to the current connection if the user is 
 /// logged in to our application.
 /// &lt;/summary&gt;
 private void SetContextInfo()
 {
 //See if a user is logged in
 var user = Thread.CurrentPrincipal as OurCustomUserType;

 //If not, we don't need to do anything - this is probably a very early call in the application
 if (user == null)
 return;

 //Create the ADO.NET command that will call our stored procedure
 var cmd = CreateCommand();
 cmd.CommandType = CommandType.StoredProcedure;
 cmd.CommandText = "p_prepare_connection_for_use";

 //Set the parameters based on the currently logged in user
 cmd.CreateParameter("as_session_id", user.SessionID, null, DbType.Guid);
 cmd.CreateParameter("ai_user_sid", user.UserID, null, DbType.Int32);

 //Run the SP
 cmd.ExecuteNonQuery();
 }
</code></pre>

In EF6 and beyond, there might be a cleaner way to intercept database calls....but this approach has been working great for years.

I need to set the Context_info from my winforms application so that i can notify the database not to run a trigger if my application is saving a record vs a legacy app which needs to run the trigger. Everything i have read says it needs to be set using a data context.

In my application i am using an entity manager. How can i set the data context using an entity manager instead of a datacontext. I just want the trigger to know that it is my app running and saving the data on which the trigger is set

i want to do like the follow. "set context_info '0x1234'

at the start of the trigger i check to see if the context_info is set and dont run the trigger. The legacy does not set the context_info.

how can i set the context_info sql statement from Devforce IdeaBlade app

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我需要在winforms应用程序中设置Context_info，以便在应用程序保存记录时通知数据库不要运行触发器，而不是需要运行触发器的遗留应用程序。我读到的所有内容都表明它需要使用数据上下文进行设置。在我的应用程序中，我使用了一个实体管理器。如何使用实体管理器而不是数据上下文来设置数据上下文。我只想让触发器知道是我的...

问如何在Devforce IdeaBlade应用程序中设置context_info sql语句
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何在Devforce IdeaBlade应用程序中设置context_info sql语句EN