Windows Server 2008 R2 Enterprise Windows Server 2008 R2 Datacenter Windows Server 2008 R2 Foundation Windows Server 2008 R2 Standard Windows Server 2008 R2 Web Edition Windows 7 Enterprise Windows 7 Home Basic Windows 7 Home Premium Windows 7 Professional Windows 7 Starter Windows 7 Ultimate More…Less
Symptoms
Assume that you use Active Directory cmdlets to interrogate Active Directory objects on a computer that is running Windows Server 2008 R2 or on a Windows 7-based computer that has the Remote Server Administration Tools feature installed. When you try to run the Get-ADObject cmdlet, you receive an error message that resembles the following:
The given key was not present in the dictionary.
Cause
This issue occurs because the cmdlet query returns an attribute that is not listed in the aggregate schema. When the Windows PowerShell cmdlet formats the attributes for the result of cmdlet query, the cmdlet retrieves a list of interesting attributes from Active Directory to track the formatting operation. Then, the cmdlet compares this list against the list of attributes that are retrieved for the aggregate schema. When the cmdlet query returns an attribute that is not listed in the aggregate schema, the issue that is described in the «Symptoms» section occurs.
Resolution
Hotfix information
A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.
If the hotfix is available for download, there is a «Hotfix download available» section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.
Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft website:
http://support.microsoft.com/contactus/?ws=supportNote The «Hotfix download available» form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.
Prerequisites
To apply this hotfix, you must be running Windows 7 Service Pack 1 (SP1) or Windows Server 2008 R2 SP1.
For more information about how to obtain a Windows 7 or Windows Server 2008 R2 service pack, click the following article number to view the article in the Microsoft Knowledge Base:
976932Information about Service Pack 1 for Windows 7 and for Windows Server 2008 R2
Registry information
To apply this hotfix, you do not have to make any changes to the registry.
Restart requirement
You must restart the computer after you apply this hotfix.
Hotfix replacement information
This hotfix does not replace a previously released hotfix.
File information
The global version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.
Windows 7 and Windows Server 2008 R2 file information notes
Important Windows 7 hotfixes and Windows Server 2008 R2 hotfixes are included in the same packages. However, hotfixes on the Hotfix Request page are listed under both operating systems. To request the hotfix package that applies to one or both operating systems, select the hotfix that is listed under «Windows 7/Windows Server 2008 R2» on the page. Always refer to the «Applies To» section in articles to determine the actual operating system that each hotfix applies to.
-
The files that apply to a specific product, SR_Level (RTM, SPn), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table:
Version
Product
Milestone
Service branch
6.1.760
1.22xxxWindows 7 and Windows Server 2008 R2
SP1
LDR
-
The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately in the «Additional file information for Windows 7 and for Windows Server 2008 R2» section. MUM and MANIFEST files, and the associated security catalog (.cat) files, are extremely important to maintaining the state of the updated component. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature.
For all supported x86-based versions of Windows 7
File name |
File version |
File size |
Date |
Time |
Platform |
---|---|---|---|---|---|
Microsoft.activedirectory.management.dll |
6.1.7601.22079 |
774,144 |
06-Aug-2012 |
17:12 |
x86 |
For all supported x64-based versions of Windows 7 and of Windows Server 2008 R2
File name |
File version |
File size |
Date |
Time |
Platform |
---|---|---|---|---|---|
Microsoft.activedirectory.management.dll |
6.1.7601.22079 |
774,144 |
06-Aug-2012 |
18:11 |
x86 |
Status
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the «Applies to» section.
More Information
For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:
824684Description of the standard terminology that is used to describe Microsoft software updates
Additional file information
Additional file information for Windows 7 and for Windows Server 2008 R2
Additional files for all supported x86-based versions of Windows 7
File name |
X86_a72e15df5fd0ce2c991e6e8f403daead_31bf3856ad364e35_6.1.7601.22079_none_8aa6ed2c8a8746ce.manifest |
File version |
Not applicable |
File size |
706 |
Date (UTC) |
07-Aug-2012 |
Time (UTC) |
09:46 |
Platform |
Not applicable |
File name |
X86_microsoft.activedirectory.management_31bf3856ad364e35_6.1.7601.22079_none_1aeb5954edaf626a.manifest |
File version |
Not applicable |
File size |
2,809 |
Date (UTC) |
06-Aug-2012 |
Time (UTC) |
17:33 |
Platform |
Not applicable |
Additional files for all supported x64-based versions of Windows 7 and of Windows Server 2008 R2
File name |
Amd64_6d4f87cd9f3324175b411631038a43a5_31bf3856ad364e35_6.1.7601.22079_none_215c5e0ff5ba5791.manifest |
File version |
Not applicable |
File size |
710 |
Date (UTC) |
07-Aug-2012 |
Time (UTC) |
09:46 |
Platform |
Not applicable |
File name |
Amd64_a72e15df5fd0ce2c991e6e8f403daead_31bf3856ad364e35_6.1.7601.22079_none_e6c588b042e4b804.manifest |
File version |
Not applicable |
File size |
708 |
Date (UTC) |
07-Aug-2012 |
Time (UTC) |
09:46 |
Platform |
Not applicable |
File name |
Amd64_microsoft.activedirectory.management_31bf3856ad364e35_6.1.7601.22079_none_7709f4d8a60cd3a0.manifest |
File version |
Not applicable |
File size |
2,813 |
Date (UTC) |
06-Aug-2012 |
Time (UTC) |
18:46 |
Platform |
Not applicable |
Need more help?
An System.Collections.Generic.KeyNotFoundException “The given key was not present in the dictionary” can be the result of using a too old MySQL Connector/NET version in your ASP.NET web application. A KeyNotFoundException is thrown when an operation attempts to retrieve an element from a collection using a key that does not exist in that collection. An unsupported character set like utf8mb4 can be such a key, if your Connector/NET doesn’t support this character set. Luckily there is an easy workaround for this.
MySQL (Oracle) Connector/NET versions prior to 6.0.8, 6.1.6, 6.2.5, 6.3.6 lack a mapping for UTF8MB4 as charset. Connecting to a MySQL database and querying a table that has been created with CHARSET=utf8mb4
results in a .NET exception:
Exception Details: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary. at System.Collections.Generic.Dictionary`2.get_Item(TKey key) at MySql.Data.MySqlClient.CharSetMap.GetCharacterSet(DBVersion version, String CharSetName) at MySql.Data.MySqlClient.CharSetMap.GetEncoding(DBVersion version, String CharSetName) at MySql.Data.MySqlClient.Driver.Configure(MySqlConnection connection) at MySql.Data.MySqlClient.MySqlConnection.Open() at ASP.mysql_data_aspx.MySQLConn()
A more extended exception is:
System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary. at System.Collections.Generic.Dictionary`2.get_Item(TKey key) at MySql.Data.MySqlClient.CharSetMap.GetCharacterSet(DBVersion version, String CharSetName) at MySql.Data.MySqlClient.MySqlField.SetFieldEncoding() at MySql.Data.MySqlClient.NativeDriver.GetColumnData(MySqlField field) at MySql.Data.MySqlClient.NativeDriver.GetColumnsData(MySqlField[] columns) at MySql.Data.MySqlClient.Driver.GetColumns(Int32 count) at MySql.Data.MySqlClient.ResultSet.LoadColumns(Int32 numCols) at MySql.Data.MySqlClient.ResultSet..ctor(Driver d, Int32 statementId, Int32 numCols) at MySql.Data.MySqlClient.Driver.NextResult(Int32 statementId) at MySql.Data.MySqlClient.MySqlDataReader.NextResult() at MySql.Data.MySqlClient.MySqlDataReader.Close() at MySql.Data.MySqlClient.MySqlCommand.ResetReader() at MySql.Data.MySqlClient.MySqlCommand.ExecuteReader(CommandBehavior behavior) at MySql.Data.MySqlClient.MySqlCommand.ExecuteReader() at ASP.mysql_data_aspx.MySQLConn()
Googling for a fix, some suggestions were to add CharSet=utf8;
to your connection string. Unfortunately I was unable to resolve the exception with this added.
The best way to fix this System.Collections.Generic.KeyNotFoundException with Connector/NET is to simply update your Connector/NET version. Support for utf8mb4 charset is built in in versions 6.0.8, 6.1.6, 6.2.5, 6.3.6+:
MySQL Connector/NET did not support the
utf8mb4
character set. When attempting to connect toutf8mb4
tables or columns, an exceptionKeyNotFoundException
was generated. (Bug #58244)https://dev.mysql.com/doc/relnotes/connector-net/en/news-6-0-8.html
And MySQL Connector/NET now supports MySQL servers configured to use utf8mb4 as the default character set in version 8.0.9.
MySQL Connector/NET now supports MySQL servers configured to use utf8mb4 as the default character set.
https://dev.mysql.com/doc/relnotes/connector-net/en/news-8-0-9.html
If, for some reason, you cannot or will not update your MySQL Connector/NET version anytime soon, there is an easy workaround available; SET NAMES 'utf8'
. Yes, that’s right: as your first statement, set the three session system variables
- character_set_client
- character_set_connection
- character_set_results
to the given character set utf8. You can even use latin1, but that may give some undesired encoding issues…
Imaging the following C# MySql.Data.MySqlClient test script for querying your MySQL database table:
Code language: C# (cs)
string sql = "select * from aspnet_site_comments"; MySqlCommand cmd = new MySqlCommand(sql, conn); MySqlDataReader rdr = cmd.ExecuteReader(); while (rdr.Read()) { Response.Write(rdr[0]+ "<br/>"); } rdr.Close(); } catch (Exception ex) { Response.Write(ex.ToString()); }
Are you looking for rock solid, eco-friendly, .NET hosting? Look no further! UmbHost offers powerful hosting services for websites and businesses of all sizes, and is powered by 100% renewable energy!
If your MySQL database server has in its my.cnf
server config:
Code language: SQL (Structured Query Language) (sql)
character_set_server utf8mb4 collation_server = utf8mb4_unicode_ci
And your table aspnet_site_comments
is created using ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
, it throws an System.Collections.Generic.KeyNotFoundException exception. Alter your code to first set the character_set_* to utf8 (don’t mind my pseudo-code, you’ll get the idea) as a workaround for this issue:
Code language: C# (cs)
string setcharset = "SET NAMES 'utf8'"; // <-- !! MySqlCommand charsetcmd = new MySqlCommand(setcharset, conn); MySqlDataReader charsetrdr = charsetcmd.ExecuteReader(); charsetrdr.Close() string sql = "select * from aspnet_site_comments"; MySqlCommand cmd = new MySqlCommand(sql, conn); MySqlDataReader rdr = cmd.ExecuteReader(); while (rdr.Read()) { Response.Write(rdr[0]+ "<br/>"); } rdr.Close(); } catch (Exception ex) { Response.Write(ex.ToString()); }
Only use this as a temporary fix, you should still update Connector/NET ASAP. That’s it!
- Remove From My Forums
-
Question
-
I am using following code to filter out some data from one datatable to another
if (dtKeys.Rows.Count > 0 && objEntryPlanningReport.PostageCalculationTable != null && objEntryPlanningReport.PostageCalculationTable.Rows.Count > 0) { dt = objEntryPlanningReport.PostageCalculationTable.Clone();//cloning the structure try { foreach (DataRow dr in dtKeys.Rows) { DataView datavw = new DataView(); datavw = objEntryPlanningReport.PostageCalculationTable.DefaultView;//Getting the default view datavw.RowFilter = " JobID = '" + dr["fkJobID"].ToString() + "' and fkContainerID='" + dr["csmContainerID"].ToString() + "' "; //filter out the data i wanted to extract if (datavw.Count > 0) { foreach (DataRow drMatched in datavw.ToTable().Rows)//error in this line.The given key was not present in the dictionary. { dt.ImportRow(drMatched);//copying the matched rows in my desired table } } } } catch (Exception ex) { //throw; } dt.AcceptChanges(); } return dt;
But On random basis On the line I have highlighted I am getting following error
The given key was not present in the dictionary.
How can i avoid it
Kamran Shahid Principle Engineer Development (MCP,MCAD,MCSD.NET,MCTS,MCPD.net[web])
Answers
-
This is not really an «exception», it’s just a problem with the debugger. The debugger attempted to get the Capacity of thet able, but it took too long, so it aborted the attempt. Usually that just means the computer doesn’t have enough resources to do everything
it needs to do within the time that Visual Studio allows.I would recommend looping through dr directly (instead of the view). Add dr[«fkJobID»] and dr[«csmContainerID»] to your Waches window, and put a breakpoint somewhere in your loop. Keep hitting F5 until you see where one of those two calls returns an exception
instead of a legitimate value.
Check out
My Blog. Now updated to actually work!-
Marked as answer by
Wednesday, May 9, 2012 3:34 AM
-
Marked as answer by
This C# exception article demonstrates the KeyNotFoundException.
KeyNotFoundException. A KeyNotFoundException was thrown.
This is likely caused by an invalid usage of the Dictionary collection. As always we want a quick way to fix the problem. We look at correct and incorrect examples.
Example. First, here we see some code that looks correct. But it has a severe flaw. This is the problem: you cannot look up a key that is not found in the Dictionary and try to assign your variable to its value.
Here: The KeyNotFoundException is thrown on the final line of try-block. The string «test» is not present in the collection.
TryCatch
C# program that throws KeyNotFoundException using System; using System.Collections.Generic; class Program { static void Main() { try { // // Create new Dictionary with string key of "one" // Dictionary<string, string> test = new Dictionary<string, string>(); test.Add("one", "value"); // // Try to access key of "two" // string value = test["two"]; } catch (Exception ex) { // // An exception will be thrown. // Console.WriteLine(ex); } } } Output System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary. at System.ThrowHelper.ThrowKeyNotFoundException() ...
Example 2. We can fix this exception by using the TryGetValue method on the Dictionary constructed type. Note that could use ContainsKey instead of TryGetValue, but the below code preserves the intention of the previous code.
ContainsKeyTryGetValue
C# program that does not throw using System; using System.Collections.Generic; class Program { static void Main() { Dictionary<string, string> test = new Dictionary<string, string>(); test.Add("one", "value"); // // Use TryGetValue to avoid KeyNotFoundException. // string value; if (test.TryGetValue("two", out value)) { Console.WriteLine("Found"); } else { Console.WriteLine("Not found"); } } } Output Not found
You always have to use the if-statement when testing values in the Dictionary, because there is always a possibility that the key will not exist. The C# compiler cannot detect missing keys. They can only be detected at runtime.
Tester-DoerCompile-Time Error
Summary. We saw how to raise and catch the KeyNotFoundException during runtime. We then saw how to avoid causing the exception. We discussed alternatives, such as TryGetValue and ContainsKey, and looked at a program that does not have this problem.
Related Links
Adjectives
Ado
Ai
Android
Angular
Antonyms
Apache
Articles
Asp
Autocad
Automata
Aws
Azure
Basic
Binary
Bitcoin
Blockchain
C
Cassandra
Change
Coa
Computer
Control
Cpp
Create
Creating
C-Sharp
Cyber
Daa
Data
Dbms
Deletion
Devops
Difference
Discrete
Es6
Ethical
Examples
Features
Firebase
Flutter
Fs
Git
Go
Hbase
History
Hive
Hiveql
How
Html
Idioms
Insertion
Installing
Ios
Java
Joomla
Js
Kafka
Kali
Laravel
Logical
Machine
Matlab
Matrix
Mongodb
Mysql
One
Opencv
Oracle
Ordering
Os
Pandas
Php
Pig
Pl
Postgresql
Powershell
Prepositions
Program
Python
React
Ruby
Scala
Selecting
Selenium
Sentence
Seo
Sharepoint
Software
Spellings
Spotting
Spring
Sql
Sqlite
Sqoop
Svn
Swift
Synonyms
Talend
Testng
Types
Uml
Unity
Vbnet
Verbal
Webdriver
What
Wpf
- Remove From My Forums
-
Question
-
Has anyone seen this?
I removed the old MP and was trying to update it with a new mp.
Deployment Infrastructure encountered an error while performing deployment operations.
MP name: FileAttachment_DatawarehouseNames
MP version: 1.0.0.3
Operation: Update
Error message: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.ThrowHelper.ThrowKeyNotFoundException()
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at Microsoft.SystemCenter.ResourceAccessLayer.IdentityCalculator.GetGuid(String idRef)
at Microsoft.SystemCenter.DeploymentEngine.OpenDirectedSequencer.HasDeleteDependencies(Int32 i, DeployerBase[] deployers)
at Microsoft.SystemCenter.DeploymentEngine.OpenDirectedSequencer.Serialize(DeployerBase[] deployers)
at Microsoft.SystemCenter.DeploymentEngine.DeploymentSequencerBase.Sort()
at Microsoft.SystemCenter.DeploymentEngine.PackDeploymentManager.Execute()
at Microsoft.SystemCenter.DeploymentEngine.PackDeploymentManager.Run(IXPathNavigable instance)
Help
Answers
-
Yup, you have a upgrade incompatibility, and you are redefining relationships, so this might be an issue even if you wait for it to be cleared by MPSync.
I suggest that you do the following in TEST to prove out the issue before moving to production:
- remove the new MP from test
- wait for MPSYnc or manually run MPSync twice
- verify the old and new MPs have been removed from the Datawarehouse Management Packs view,
- change the internal name of your MP, in order to prevent another MP Upgrade issue
- re-import the renamed MP to see if it will replace that relationship or if it will have further problems.
I suspect you might still have an issue with the same name relationship being defined differently by the new MP, even if you are not attempting to upgrade the MP, but i can’t be sure, so test it.
-
Proposed as answer by
Thursday, February 12, 2015 7:49 PM
-
Marked as answer by
Andreas BaumgartenMVP
Thursday, February 12, 2015 7:49 PM
I have created some log output to help with the search.
I have replaced the nuget package reference by a direct project reference, and logged wherever either:
m_enlistedTransaction
was being set, ors_transactionConnections
was being mutated.
Timestamps are from bottom to top. Note how the first run of my Quartz job has no problems, but the second run (after a few minutes of inactivity) seems to think that it can reuse some existing connection.
Unfortunately, I’ve logged the hash code of the enlisted transaction rather than the underlying System.Transactions.Transaction
.
My comments should help provide some insight into what’s going on. Note that the first run performs a couple of (unrelated) transactions back-to-back, successfully, but the second run throws on its very first attempt.
@bgrainger Any idea why FindExistingEnlistedSession()
in OpenAsync()
finds an existing connection on my subsequent job run, for a brand new transaction?
I could only find the .NET Framework source, but it looks like the hash code and even equality of Transaction
is based entirely on its InternalTransaction.TransactionHash
. Perhaps such hash codes end up getting reused, and the new transaction is seen as identical to an old one? Then again, the old one is being removed from the dictionary, so it still doesn’t explain.
SUBSEQUENT JOB RUN:
// Step 3: Throw when attempting to find the related Transaction in s_transactionConnections
Jun 1, 2021 @ 17:10:22.550 System.Collections.Generic.KeyNotFoundException: The given key 'System.Transactions.Transaction' was not present in the dictionary.
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
at MySqlConnector.MySqlConnection.DoCloseAsync(Boolean changeState, IOBehavior ioBehavior) in /app/MySqlConnector/MySqlConnection.cs:line 1004
at MySqlConnector.MySqlConnection.CloseAsync(Boolean changeState, IOBehavior ioBehavior) in /app/MySqlConnector/MySqlConnection.cs:line 972
at MySqlConnector.MySqlConnection.Dispose(Boolean disposing) in /app/MySqlConnector/MySqlConnection.cs:line 653
at System.ComponentModel.Component.Dispose()
// Step 2: Close after the first of our two queries within our transaction, passing the enlistment on to a new dummy
Jun 1, 2021 @ 17:10:22.545 message:DoCloseAsync: Setting (stealing) m_enlistedTransaction: transaction 41727345 for connection 17882254.
Jun 1, 2021 @ 17:10:22.543 message:DoCloseAsync: Unsetting (donating) m_enlistedTransaction: transaction 41727345 for connection 20809629.
// Step 1: Enlist, which does not add to s_transactionConnections, presumably because the "TryGetValue" condition concludes the dictionary already has that transaction
Jun 1, 2021 @ 17:10:22.524 message:EnlistTransaction: Setting m_enlistedTransaction: transaction 1 for connection 20809629.
FIRST JOB RUN:
// Second iteration of open transaction scope, perform query, commit:
// Step 5: Unenlist at the end of the transaction, which also removes from s_transactionConnections
Jun 1, 2021 @ 16:41:39.451 message:UnenlistTransaction: Removing from s_transactionConnections: transaction 11 for connection 33771145.
Jun 1, 2021 @ 16:41:39.449 message:UnenlistTransaction: Unsetting m_enlistedTransaction: transaction 11 for connection 33771145.
// Step 4: Close after the second of our two queries within our transaction, passing the enlistment on to a new dummy transaction (used to hold the session)
Jun 1, 2021 @ 16:41:39.410 message:DoCloseAsync: Setting (stealing) m_enlistedTransaction: transaction 35287174 for connection 33771145.
Jun 1, 2021 @ 16:41:39.408 message:DoCloseAsync: Unsetting (donating) m_enlistedTransaction: transaction 35287174 for connection 52697953.
// Step 3: Open the new connection, but actually reuse the previous one within the transaction
Jun 1, 2021 @ 16:41:39.258 message:OpenAsync: Setting (stealing) m_enlistedTransaction: transaction 35287174 for connection 52697953.
Jun 1, 2021 @ 16:41:39.257 message:OpenAsync: Unsetting (donating) m_enlistedTransaction: transaction 35287174 for connection 44419000.
// Step 2: Close after the first of our two queries within our transaction, passing the enlistment on to a new dummy transaction (used to hold the session)
Jun 1, 2021 @ 16:41:39.254 message:DoCloseAsync: Setting (stealing) m_enlistedTransaction: transaction 35287174 for connection 44419000.
Jun 1, 2021 @ 16:41:39.253 message:DoCloseAsync: Unsetting (donating) m_enlistedTransaction: transaction 35287174 for connection 41300193.
// Step 1: Enlist (caused by OpenAsync), which also adds to s_transactionConnections
Jun 1, 2021 @ 16:41:39.190 message:EnlistTransaction: Adding to s_transactionConnections: transaction 11 for connection 41300193.
Jun 1, 2021 @ 16:41:39.133 message:EnlistTransaction: Setting m_enlistedTransaction: transaction 11 for connection 41300193.
// First iteration of open transaction scope, perform query, commit:
Jun 1, 2021 @ 16:41:39.108 message:UnenlistTransaction: Removing from s_transactionConnections: transaction 10 for connection 9779853.
Jun 1, 2021 @ 16:41:39.106 message:UnenlistTransaction: Unsetting m_enlistedTransaction: transaction 10 for connection 9779853.
Jun 1, 2021 @ 16:41:39.018 message:DoCloseAsync: Setting (stealing) m_enlistedTransaction: transaction 17561922 for connection 9779853.
Jun 1, 2021 @ 16:41:39.017 message:DoCloseAsync: Unsetting (donating) m_enlistedTransaction: transaction 17561922 for connection 60800190.
Jun 1, 2021 @ 16:41:37.623 message:OpenAsync: Setting (stealing) m_enlistedTransaction: transaction 17561922 for connection 60800190.
Jun 1, 2021 @ 16:41:37.621 message:OpenAsync: Unsetting (donating) m_enlistedTransaction: transaction 17561922 for connection 48950176.
Jun 1, 2021 @ 16:41:37.593 message:DoCloseAsync: Setting (stealing) m_enlistedTransaction: transaction 17561922 for connection 48950176.
Jun 1, 2021 @ 16:41:37.592 message:DoCloseAsync: Unsetting (donating) m_enlistedTransaction: transaction 17561922 for connection 57171047.
Jun 1, 2021 @ 16:41:37.305 message:EnlistTransaction: Adding to s_transactionConnections: transaction 10 for connection 57171047.
Jun 1, 2021 @ 16:41:37.262 message:EnlistTransaction: Setting m_enlistedTransaction: transaction 10 for connection 57171047.