You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my service, trying to use EF Core DBContext for service to access to database. In my Web API controller, I use constructor injection to get the db context, and when debugging, I can see the dbContext was injected into the controller and can be used. But the entity in the DbContext always has exception: System.ArgumentException: Data type 'VARCHAR' is not supported in this form. Either specify the length explicitly in the type name, for example as 'VARCHAR(16)', or remove the data type and use APIs such as HasMaxLength to allow EF choose the data type.
I did the following config on DbContext for my asp.net core web api in service fabric.
MyWebService.cs, config the dbcontext, and inject it into service. piece of code is like:
The above config way( way1 )--- using attribute in Entity gives me the VARCHAR not supported data type exception.
I also tried to use fluent API (way 2) to config entity property, for which I remove the attribute for the entity property like the following, but still same exception.
publicclassMyDbContext:DbContext{publicMyDbContext(DbContextOptions<MyDbContext>options):base(options){}publicvirtualDbSet<Features>Features{get;set;}protectedoverridevoidOnModelCreating(ModelBuildermodelBuilder){modelBuilder.Entity<Features>().Property(e =>e.FeatureName).HasColumnName("FeatureName").HasColumnType("varchar(50)");}}[Table("Features")]publicclassFeatures{publicstringFeatureName{get;set;}// other properties...}
Steps to reproduce
Further technical details
EF Core version: 3.1.4
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: .netcoreapp 3.1
Operating system:
IDE: Visual Studio 2019 16.6.0
The text was updated successfully, but these errors were encountered:
Note for team: As far as I can tell, we never made the change to make this work. I can't find anything indicating that we changed our mind saying that we should not do this. To me, this still seems liek a useful feature to support.
While working on our database provider I also discovered that MaxLength is ignored when TypeName is specified. The source code expects TypeName to be correct and complete, and "varchar" without a size is not correct and complete. If you make any changes to this, please keep in mind that it could affect database providers.
…fied separately (#21829)
* Fully support base type mapping names with precision/scale/size specified separately
Fixes#21061Fixes#21140Fixes#15159
* Updates from review feedback
In my service, trying to use EF Core DBContext for service to access to database. In my Web API controller, I use constructor injection to get the db context, and when debugging, I can see the dbContext was injected into the controller and can be used. But the
entity
in the DbContext always has exception:System.ArgumentException: Data type 'VARCHAR' is not supported in this form. Either specify the length explicitly in the type name, for example as 'VARCHAR(16)', or remove the data type and use APIs such as HasMaxLength to allow EF choose the data type.
I did the following config on DbContext for my asp.net core web api in service fabric.
MyWebService.cs, config the dbcontext, and inject it into service. piece of code is like:
MyDbContext.cs
The entity
Features
class, which is mapping to a table in databaseAnd in Web API controller, use constructor injection to get the dbcontext:
The above config way( way1 )--- using attribute in Entity gives me the VARCHAR not supported data type exception.
I also tried to use fluent API (way 2) to config entity property, for which I remove the attribute for the entity property like the following, but still same exception.
Steps to reproduce
Further technical details
EF Core version: 3.1.4
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: .netcoreapp 3.1
Operating system:
IDE: Visual Studio 2019 16.6.0
The text was updated successfully, but these errors were encountered: