I'm working on an SQL Server database where one of my tables has a column whose value seem to be increased by 10 at a time.
The column (called Customer.Object_id
) is a primary key (as can be seen in Microsoft SQL Server Management Studio), but I don't believe that the increase by 10 is handled by SQL Server because, when I use the "Edit" functionality for creating a new tuple, I get the request to fill in that particular column, so it should be handled by something else.
Here is the definition in SQL Server:
As an ORM, I use Telerik, so I guess that this one should be responsible, but I don't see it. The mapping configuration looks as follows:
private MappingConfiguration<CustomerObj> CreateCustomerObjMapping()
{
var mapping = new MappingConfiguration<CustomerObj>();
mapping.FieldNamingRules.CaseMode = Telerik.OpenAccess.Metadata.CaseChangeModes.CamelCase;
mapping.FieldNamingRules.AddPrefix = "_";
mapping.MapType(o => new
{
o.Id,
o.Name,
o.BackgroundColor,
// o.Code,
o.ForegroundColor
}).Inheritance(InheritanceStrategy.Vertical).ToTable(new TableName("Customer.Obj", string.Empty));
mapping.HasDiscriminatorValue(typeof(CustomerObj).FullName);
return mapping;
}
In here, I don't see any reference to the increase by 10, but I also have no idea how to interpret this information.
The column Id
is a normal column (although this one should be the one, being handled for this - that's a strategic mistake, done by my predecessor which I can't change any more).
Does anybody have an idea where the increase by 10 in the Customer.Object_id
column is handled?
1条答案
按热度按时间cdmah0mi1#
It seems like Telerik may have opted to use its HighLow key generation mechanism for your entity.
HighLow - Telerik Data Access always needs to associate its persistent types with a primary key. If such is not supplied, Telerik Data Access uses internal mechanism for creating IDs.
The HighLow generator has a default GrabSize of 10. This is supposedly configurable via either code or config.
I don't currently have access to test it -and since the product is deprecated the doc is pretty much stale- but I suspect if you insert more than 1 objects at once in a single transaction they may actually have consecutive Ids. (then skipping to the next 10 for the following transaction)