🚀 EF Core Just Changed the Way We Update Data — Here’s Why It Matters

Birupakhya Dash — Mon, 23 Mar 2026 11:56:58 +0000

🚀 EF Core Just Changed the Way We Update Data — Here’s Why It Matters

For years, updating records in Entity Framework followed a familiar pattern:

Fetch data from the database
Modify it in memory
Call SaveChanges()

It worked—but it wasn’t efficient.

🧠 The Problem with the Old Approach

var data = await _context.FtpRequestDetails
    .Where(x => x.FtpRequestId == ftpRequestId)
    .ToListAsync();

foreach (var item in data)
{
    item.FtpStatusId = 3;
}

await _context.SaveChangesAsync();

❌ Issues:

Loads data into memory unnecessarily
Slower for large datasets
Requires change tracking
More boilerplate code

⚡ The Game-Changer: `ExecuteUpdateAsync()` (EF Core 7+)

EF Core introduced a set-based update approach that directly executes SQL without loading entities.

await _context.FtpRequestDetails
    .Where(x => x.FtpRequestId == ftpRequestId)
    .ExecuteUpdateAsync(setters => setters
        .SetProperty(x => x.FtpStatusId, 3)
        .SetProperty(x => x.ThreadLocked, (bool?)null)
        .SetProperty(x => x.ThreadUnlockedTime, DateTime.Now)
        .SetProperty(x => x.Comments, "Rejected Details")
    );

🔍 What’s Happening Behind the Scenes?

This LINQ query is translated into a single SQL statement:

UPDATE FtpRequestDetails
SET 
    FtpStatusId = 3,
    ThreadLocked = NULL,
    ThreadUnlockedTime = GETDATE(),
    Comments = 'Rejected Details'
WHERE FtpRequestId = @ftpRequestId

👉 No entity loading
👉 No loops
👉 Just pure SQL execution

💡 Why This Matters

🚀 Performance Boost

Eliminates unnecessary data fetching
Executes directly in the database
Ideal for bulk operations

🧹 Cleaner Code

No loops
No manual tracking
Minimal code, maximum impact

⚙️ Better Scalability

Handles large datasets efficiently
Perfect for background jobs & batch updates

⚠️ Things to Keep in Mind

❌ No Change Tracking

EF Core won’t track these changes.

❌ No `SaveChanges()`

This executes immediately—no unit of work involved.

❌ No Entity Events

Hooks, validations, or domain events won’t run.

🧭 When Should You Use It?

✔ Bulk updates
✔ Background processing
✔ Performance-critical operations
✔ Updating multiple records at once

🚫 When NOT to Use It

❌ If you rely on:

Business logic per entity
Validation rules
Domain events or auditing

🆚 Old vs New

Feature	Old Approach	New Approach
Performance	❌ Slower	✅ Faster
Memory Usage	❌ High	✅ Low
Change Tracking	✅ Yes	❌ No
Code Complexity	❌ More	✅ Less

🏁 Final Thoughts

EF Core’s ExecuteUpdateAsync() is a major shift toward modern, high-performance data handling.

It brings the power of SQL directly into LINQ—without sacrificing readability.

👉 If you're still using the old pattern for bulk updates, it's time to upgrade.

💬 Have you started using ExecuteUpdateAsync() yet?
Would love to hear your experience!

DotNet #EFCore #CleanCode #Performance #SoftwareEngineering #CSharp #Developers

Fixing the "String or Binary Data Would Be Truncated" Error in EF Core

Birupakhya Dash — Wed, 18 Mar 2026 10:12:20 +0000

Fixing the "String or Binary Data Would Be Truncated" Error in EF Core

If you’ve worked with Entity Framework Core and SQL Server, you’ve likely encountered this error:

String or binary data would be truncated

At first glance, this error is frustrating because it doesn't tell you:

Which table failed
Which column caused the issue
What the allowed size is
What value exceeded the limit

So debugging becomes time-consuming.

The Problem

Consider this table:

Users
FirstName VARCHAR(20)

Now insert:

"ThisIsAVeryLongNameThatExceedsLimit"

SQL Server throws:

String or binary data would be truncated

But gives no details.

The Solution: DBGuard

To solve this, I built a library called DBGuard.

DBGuard validates entity data against the actual database schema before SaveChanges.

How It Works

Flow:

Application
→ EF Core SaveChanges
→ DBGuard Interceptor
→ Validation Engine
→ Database

Example

Instead of SQL Server error:

String or binary data would be truncated

DBGuard returns:

DBGuard Validation Failed

Table: Users
Column: FirstName
Allowed Length: 20
Actual Length: 45

Suggestion: Trim input or increase column length

Installation

dotnet add package DBGuard

Usage

builder.Services.AddDbGuard(connectionString);

builder.Services.AddDbContext<AppDbContext>((sp, options) =>
{
    var interceptor = sp.GetRequiredService<DbGuardInterceptor>();

    options.UseSqlServer(connectionString)
           .AddInterceptors(interceptor);
});

Features

Schema-aware validation
Column length validation
Null & type validation
Decimal precision validation
EF Core interceptor
Logging and diagnostics

GitHub

https://github.com/birupakhya2000/DBGuard

Final Thoughts

This is a common problem many developers face.

I’d love feedback and suggestions from the community 🙌

DEV Community: Birupakhya Dash

🚀 EF Core Just Changed the Way We Update Data — Here’s Why It Matters

🧠 The Problem with the Old Approach

❌ Issues:

⚡ The Game-Changer: ExecuteUpdateAsync() (EF Core 7+)

🔍 What’s Happening Behind the Scenes?

💡 Why This Matters

🚀 Performance Boost

🧹 Cleaner Code

⚙️ Better Scalability

⚠️ Things to Keep in Mind

❌ No Change Tracking

❌ No SaveChanges()

❌ No Entity Events

🧭 When Should You Use It?

🚫 When NOT to Use It

🆚 Old vs New

🏁 Final Thoughts

DotNet #EFCore #CleanCode #Performance #SoftwareEngineering #CSharp #Developers

Fixing the "String or Binary Data Would Be Truncated" Error in EF Core

Fixing the "String or Binary Data Would Be Truncated" Error in EF Core

The Problem

The Solution: DBGuard

How It Works

Example

Installation

Usage

Features

GitHub

Final Thoughts

⚡ The Game-Changer: `ExecuteUpdateAsync()` (EF Core 7+)

❌ No `SaveChanges()`