Entity Framework Core provider for Progress OpenEdge
EntityFrameworkCore.OpenEdge is an Entity Framework Core provider that allows you to use Entity Framework Core with Progress OpenEdge databases through ODBC connections. This provider supports EF Core 9.
Features
Querying: SELECT, WHERE, ORDER BY, GROUP BY, SKIP/TAKE (paging), COUNT, SUM, FIRST
Joins: INNER JOIN, LEFT JOIN, Include for navigation properties, filtered includes
String Operations: Contains, StartsWith, EndsWith (translated to LIKE), Length property
Data Manipulation: INSERT, UPDATE, DELETE operations with OpenEdge-optimized SQL generation
Scaffolding: Reverse engineering of existing OpenEdge database schemas (Database First)
public class MyDbContext : DbContext
{
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseOpenEdge("Driver=Progress OpenEdge 11.7 Driver;HOST=localhost;port=10000;UID=<user>;PWD=<password>;DIL=1;Database=<database>");
}
}
Using a DSN
Create an ODBC DSN for your Progress OpenEdge database:
public class MyDbContext : DbContext
{
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseOpenEdge("dsn=MyDb;password=mypassword");
}
}
Custom Schema Configuration
By default, the provider uses the "pub" schema. You can specify a different default schema:
public class MyDbContext : DbContext
{
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
// Using custom schema (defaults to "pub" if not specified)
optionsBuilder.UseOpenEdge(
connectionString: "dsn=MyDb;password=mypassword",
defaultSchema: "myschema");
}
}
Note: The schema parameter affects table name resolution when tables don't have explicitly defined schemas in your entity configurations.
OpenEdge databases don't have true primary keys. Primary indexes exist but are not required to be unique, which conflicts with EF Core's entity tracking requirements. The rowid is your best option for a reliable primary key:
[Key]
[Column("rowid")]
public string Rowid { get; set; }
OpenEdge SQL requires explicit boolean comparisons (e.g., WHERE IsActive = 1). The provider automatically handles this:
// This C# code:
var activeUsers = context.Users.Where(u => u.IsActive).ToList();
// Becomes this SQL:
// SELECT * FROM "Users" WHERE "IsActive" = 1
Paging with Skip() and Take()
OpenEdge requires literal values for OFFSET and FETCH clauses. The provider automatically inlines these values rather than using parameters:
// This code:
var pagedResults = context.Users.Skip(10).Take(20).ToList();
// Generates:
// SELECT * FROM "Users" OFFSET 10 ROWS FETCH NEXT 20 ROWS ONLY
No Update Batching
Each INSERT, UPDATE, and DELETE operation executes individually. Multiple changes in a single SaveChanges() call result in multiple database round trips.
Parameter Handling
The provider uses positional ? parameters instead of named parameters, carefully managing parameter order to match SQL placeholders.
Architecture Highlights
Query Pipeline
LINQ queries are translated into OpenEdge-compatible SQL with several key customizations:
Boolean Handling: Implicit boolean checks are converted to explicit comparisons (WHERE "IsActive" = 1)
String Functions: .Contains(), .StartsWith(), and .EndsWith() translate to SQL LIKE expressions using CONCAT functions
Paging: Skip() and Take() values are inlined as literals into OFFSET/FETCH clauses
Parameters: Uses positional ? parameters instead of named parameters
Update Pipeline
The update pipeline handles OpenEdge's specific requirements:
Single Command Execution: Each modification is processed individually in its own command batch
No RETURNING Support: OpenEdge doesn't support RETURNING clauses, affecting concurrency detection and identity retrieval
Parameter Ordering: Carefully orders parameters to match positional ? placeholders in generated SQL
DateTime Formatting: Uses ODBC timestamp escape sequences { ts 'yyyy-MM-dd HH:mm:ss' } for datetime literals, which OpenEdge requires for proper datetime handling
Query Pipeline Deep Dive
For developers interested in the technical details of how LINQ queries become SQL:
Query Translation Process
LINQ Expression Tree: C# LINQ methods create a .NET expression tree
This repository is a fork and modernization of an older OpenEdge EF Core provider originally written for .NET Framework 2.1. The current implementation represents a significant evolution with proper architecture, comprehensive type mappings, and OpenEdge-specific optimizations.
Branch Structure & Status
The repository maintains multiple branches for different EF Core versions:
Branch
EF Core Version
Status
Description
master
9.x
✅ Complete
Fully validated with all essential features
efcore8
8.x
⚠️ Needs Features
Basic migration complete, missing essential features
efcore6
6.x
⚠️ Needs Features
Basic migration complete, missing essential features
efcore5
5.x
⚠️ Needs Features
Basic migration complete, missing essential features
efcore3.1
3.1.x
⚠️ Needs Features
Basic migration complete, missing essential features
How to Contribute
Priority: Feature Backporting
The most critical contribution needed is backporting essential features from the master (EF Core 9) branch to older versions
Backporting Process:
Check out the target branch (e.g., efcore8)
Compare implementations with master branch
Adapt the features to the target EF Core version's API
Ensure all tests pass
Submit a pull request
Future Development Priorities
Query Translation Enhancements:
Method/Member Translators: Evaluate need for additional translators (Math functions, DateTime operations, etc.)
Nested Query Optimizations: Improve performance for complex subqueries and navigation property includes
Aggregate Function Support: Expand beyond basic COUNT/SUM operations
Performance & Reliability:
Bulk Operations: Investigate workarounds for OpenEdge's single-command limitation
