﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Ayende Rahien commented on Esent, identity and the case of the duplicate key</title><description>Laurion,
  
I actually assumed that the reason for that was to keep things simple, but that makes sense as well.
  
I don't _mind_, but I had some code that relied on being able to copy identity value to another table, without taking into account that it can be reused.
  
Just something to be aware of
</description><link>http://ayende.com/3974/esent-identity-and-the-case-of-the-duplicate-key#comment6</link><guid>http://ayende.com/3974/esent-identity-and-the-case-of-the-duplicate-key#comment6</guid><pubDate>Fri, 24 Apr 2009 07:08:43 GMT</pubDate></item><item><title>Benny Thomas commented on Esent, identity and the case of the duplicate key</title><description>It looks like your bookmark is the same and you will hit the first column each loop. Giving the same result?
</description><link>http://ayende.com/3974/esent-identity-and-the-case-of-the-duplicate-key#comment5</link><guid>http://ayende.com/3974/esent-identity-and-the-case-of-the-duplicate-key#comment5</guid><pubDate>Fri, 24 Apr 2009 06:42:21 GMT</pubDate></item><item><title>Fabio Maulo commented on Esent, identity and the case of the duplicate key</title><description>NH has the same behavior for 
&lt;increment strategy.
&gt;</description><link>http://ayende.com/3974/esent-identity-and-the-case-of-the-duplicate-key#comment4</link><guid>http://ayende.com/3974/esent-identity-and-the-case-of-the-duplicate-key#comment4</guid><pubDate>Fri, 24 Apr 2009 04:55:21 GMT</pubDate></item><item><title>Laurion Burchall commented on Esent, identity and the case of the duplicate key</title><description>In the code above the table is being opened each time and Esent behaves just as described.
  
  
This is done for performance reasons. Tracking the max autoinc value in the catalog would require updating a second database page on every update, generating more log and database I/O. If the table has a lot of inserts then the autoinc value would become 'hot', meaning that a lot of different threads would want to update this page. This makes checkpoint advancement harder because the page can only be written to disk when it isn't latched. That problem can be solved by our page versioning but creating versions uses up more buffer manager space.
  
  
One note about this -- when Esent looks for max(id) from the table it will look for an index where the first index segment is on id. If no such index exists then a full table scan has to be performed. No-one has made that mistake yet, but it is something to consider.
</description><link>http://ayende.com/3974/esent-identity-and-the-case-of-the-duplicate-key#comment3</link><guid>http://ayende.com/3974/esent-identity-and-the-case-of-the-duplicate-key#comment3</guid><pubDate>Fri, 24 Apr 2009 01:43:35 GMT</pubDate></item><item><title>Ayende Rahien commented on Esent, identity and the case of the duplicate key</title><description>Thomas,
  
Look again, the creation of the table is outside the loop
</description><link>http://ayende.com/3974/esent-identity-and-the-case-of-the-duplicate-key#comment2</link><guid>http://ayende.com/3974/esent-identity-and-the-case-of-the-duplicate-key#comment2</guid><pubDate>Fri, 24 Apr 2009 01:40:31 GMT</pubDate></item><item><title>Thomas Eyde commented on Esent, identity and the case of the duplicate key</title><description>Aren't you recreating the table in the loop? Then it's not so strange anymore. I would expect a new table to start counting from scratch.
</description><link>http://ayende.com/3974/esent-identity-and-the-case-of-the-duplicate-key#comment1</link><guid>http://ayende.com/3974/esent-identity-and-the-case-of-the-duplicate-key#comment1</guid><pubDate>Fri, 24 Apr 2009 00:35:32 GMT</pubDate></item></channel></rss>