dotnet/efcore · error · InvalidOperationException

The number of values ({valuesCount}) doesn't match the numbe

Error message

The number of values ({valuesCount}) doesn't match the number of columns ({columnsCount}) for the data insertion operation on '{table}'. Provide the same number of values and columns.

What it means

Thrown inside GenerateModificationCommands(InsertDataOperation, ...) in src/EFCore.Relational/Migrations/MigrationsSqlGenerator.cs:875 (message key InsertDataOperationValuesCountMismatch). It compares operation.Columns.Length against operation.Values.GetLength(1) (the column dimension of the 2D values array) and throws InvalidOperationException when they differ. The migration API for InsertData takes a rectangular object[,] whose second dimension must equal the number of columns.

Source

Thrown at src/EFCore.Relational/Migrations/MigrationsSqlGenerator.cs:875

        if (terminate)
        {
            EndStatement(builder);
        }
    }

    /// <summary>
    ///     Generates the commands that correspond to the given operation.
    /// </summary>
    /// <param name="operation">The data operation to generate commands for.</param>
    /// <param name="model">The model.</param>
    /// <returns>The commands that correspond to the given operation.</returns>
    protected virtual IEnumerable<IReadOnlyModificationCommand> GenerateModificationCommands(
        InsertDataOperation operation,
        IModel? model)
    {
        if (operation.Columns.Length != operation.Values.GetLength(1))
        {
            throw new InvalidOperationException(
                RelationalStrings.InsertDataOperationValuesCountMismatch(
                    operation.Values.GetLength(1), operation.Columns.Length,
                    FormatTable(operation.Table, operation.Schema ?? model?.GetDefaultSchema())));
        }

        if (operation.ColumnTypes != null
            && operation.Columns.Length != operation.ColumnTypes.Length)
        {
            throw new InvalidOperationException(
                RelationalStrings.InsertDataOperationTypesCountMismatch(
                    operation.ColumnTypes.Length, operation.Columns.Length,
                    FormatTable(operation.Table, operation.Schema ?? model?.GetDefaultSchema())));
        }

        if (operation.ColumnTypes == null
            && model == null)
        {
            throw new InvalidOperationException(

View on GitHub (pinned to dbf9771522)

Solutions

Ensure every row in the values 2D array has exactly operation.Columns.Length entries (the second dimension matches the columns array length).
Re-scaffold the migration (dotnet ef migrations add) from the corrected model so InsertData arrays are regenerated consistently.
Prefer modelBuilder.Entity<T>().HasData(...) for seed data over hand-authoring InsertData, so EF keeps columns and values in sync.
Run a quick local build/script that asserts values.GetLength(1) == columns.Length for every InsertData in the migration.

Example fix

// before (mismatch: 2 columns, 3 values per row):
migrationBuilder.InsertData(
    table: "Users",
    columns: new[] { "Id", "Name" },
    values: new object[,] { { 1, "Alice", true } });

// after (aligned: 2 columns, 2 values per row):
migrationBuilder.InsertData(
    table: "Users",
    columns: new[] { "Id", "Name" },
    values: new object[,] { { 1, "Alice" } });

Defensive patterns

Strategy: validation

Validate before calling

static bool InsertDataShapeIsValid(string[] columns, object[,] values)
{
    return values.GetLength(1) == columns.Length;
}

// usage before calling migrationBuilder.InsertData
if (!InsertDataShapeIsValid(new[] { "Id", "Name" }, values))
    throw new InvalidOperationException("values second dimension must equal columns.Length");

Try / catch

try
{
    await dbContext.Database.MigrateAsync();
}
catch (InvalidOperationException ex) when (ex.Message.Contains("number of values") && ex.Message.Contains("data insertion"))
{
    logger.LogError(ex, "An InsertDataOperation has a values/columns length mismatch; fix the migration.");
    throw;
}

Prevention

Prefer modelBuilder.Entity<T>().HasData(...) over hand-authored InsertData so EF keeps arrays consistent.
When editing a generated InsertData, always update both columns and every value row together.
Add a unit test that scans migration files and asserts values.GetLength(1) == columns.Length.
Re-scaffold migrations after model changes rather than hand-editing values arrays.

When it happens

Trigger: A hand-authored (or hand-edited) migration calls migrationBuilder.InsertData(columns: new[] { "A", "B" }, values: new object[,] { { 1, 2, 3 } }) where the inner dimension of values does not match the columns array. Also when seed-data scaffolding produces a malformed values array, or when a developer edits an auto-generated migration and forgets a value.

Common situations: Editing a generated migration's InsertData values array and miscounting. Building a migration programmatically with mismatched column/value arrays. Copy-pasting InsertData calls and forgetting to add/remove a corresponding column. Model seed data (HasData) that resolves to a bad array after a column rename.

Related errors

AI-assisted analysis of dotnet/efcore@dbf9771522 (2026-08-06). Data as JSON: /api/errors/5a61d876bc461b65. Report an issue: GitHub.