From: Daniel R. <da...@ac...> - 2017-04-21 18:32:29
|
Hi, I'm using Visual Studio 2015, with all updates, Firebird ADO.Net 5.8.1 and Entity Framework 6.1.3. I'm trying to generate an EF6 object by using Code First from Database. One table is causing an error when it is trying to generate the code. Up to now, the other tables that I generated the EF6 code for, by using the Code First from Database template, worked properly. Here's the call stack generated within Visual Studio: Microsoft Visual Studio An error occurred generating the Code First model. The error occurred generating the contents of TempModel1.cs. System.ArgumentOutOfRangeException: MaxLength must be greater than zero. Parameter name: maxLength at System.Data.Entity.Core.Metadata.Edm.TypeUsage.ValidateMaxLength(Int32 maxLength) at System.Data.Entity.Core.Metadata.Edm.TypeUsage.CreateStringTypeUsage(PrimitiveType primitiveType, Boolean isUnicode, Boolean isFixedLength, Int32 maxLength) at FirebirdSql.Data.EntityFramework6.FbProviderManifest.GetStoreType(TypeUsage emeype) in C:\Users\JirflDocuments\devel\NETProvider\working\Provider\src\FirebirdSql.Data.FirebirdClient\FirebirdClient\FbProviderManifest.cs:line 350 at Microsoft.Data.Entity.Design.CodeGeneration.ColumnDiscoverer.Discover(Ederoperty property, DbModel model) at Microsoft.Data.Entity.Design.CodeGeneration.Edeelper.<> c_DisplayClass5_0.< GetConfigurations> b_0(IPropertyConfigurationDiscoverer f) at System.Linq.Enumerable.WhereSelectArraylterator‘ZMoveNextO at System.Linq.Enumerable.WhereEnumerablelterator‘l .MoveNextO at System.Linq.Enumerable.< 0FI'ypelterator> d_92‘1 .MoveNextO at System.Linq.Enumerable.WhereEnumerablelterator‘l .MoveNextO at Microsoft.Data.Entity.Design.CodeGeneration.DefaultCSharpContextGenerator.TransformText0 at Microsoft.Data.Entity.Design.CodeGeneration.DefaultCSharpContextGenerator.Generate(DbModel model, String codeNamespace, String contextClassName, String connectionStringName) at Microsoft.Data.Entity.Design.CodeGeneration.CodeFirstModelGenerator.< Generate) d_3.MoveNext0 And, here's the definition of the table that I'm having a problem with: CREATE TABLE CLAIMSDETAIL ( SERVICENO INTEGER NOT NULL, FILOPTOHCFACLAIMNO INTEGER, DATESTART TIMESTAMP, DATEEND TIMESTAMP, PLACEOFSERVICE VARCHAR(2), TYPEOFSERVICE VARCHAR(2), HCPCS_CPTCODE VARCHAR(5), MODIFIER1 VARCHAR(2), MODIFIER2 VARCHAR(5), DIAGNOSISCODE VARCHAR(1), CHARGES CURRENCY, DAYSORUNITS VARCHAR(2), EPSDTFAMILYPLAN VARCHAR(2), EMG VARCHAR(2), COB VARCHAR(2), LOCALUSE VARCHAR(8), MODIFIEDDATE TIMESTAMP, MODIFIEDBY USERNAMETYPE, INVOICEDETAILITEMNO INTEGER, MODIFIER3 CPT_CODE_MODIFIER, MODIFIER4 CPT_CODE_MODIFIER, DIAGNOSTIC_CODE VARCHAR(10), DIAGNOSIS_CODE_POINTER_1 INTEGER, DIAGNOSIS_CODE_POINTER_2 INTEGER, DIAGNOSIS_CODE_POINTER_3 INTEGER, DIAGNOSIS_CODE_POINTER_4 INTEGER, SERVICE_SEQUENCE_NO INTEGER DEFAULT 1, ESPDT CHAR(2), SUPPLEMENTAL_INFORMATION VARCHAR(80), UC_DIAGNOSIS_CODE_1 ICD9_CODE, UC_DIAGNOSIS_CODE_2 ICD9_CODE, UC_DIAGNOSIS_CODE_3 ICD9_CODE, UC_DIAGNOSIS_CODE_4 ICD9_CODE, DIAGNOSIS_CODES COMPUTED BY ( coalesce(iif(diagnosis_code_pointer_1>0, diagnosis_code_pointer_1, ''),'')||coalesce(iif(diagnosis_code_pointer_2>0, diagnosis_code_pointer_2, ''),'')||coalesce(iif(diagnosis_code_pointer_3>0, diagnosis_code_pointer_3, ''),'')||coalesce(iif(diagnosis_code_pointer_4>0, diagnosis_code_pointer_4, ''),'') ), DIAGNOSIS_02_12_CODE_POINTER_1 COMPUTED BY ( case diagnosis_code_pointer_1 when 1 then 'A' when 2 then 'B' when 3 then 'C' when 4 then 'D' when 5 then 'E' when 6 then 'F' when 7 then 'G' when 8 then 'H' when 9 then 'I' when 10 then 'J' when 11 then 'K' when 12 then 'L' end ), DIAGNOSIS_02_12_CODE_POINTER_2 COMPUTED BY ( case diagnosis_code_pointer_2 when 1 then 'A' when 2 then 'B' when 3 then 'C' when 4 then 'D' when 5 then 'E' when 6 then 'F' when 7 then 'G' when 8 then 'H' when 9 then 'I' when 10 then 'J' when 11 then 'K' when 12 then 'L' end ), DIAGNOSIS_02_12_CODE_POINTER_3 COMPUTED BY ( case diagnosis_code_pointer_3 when 1 then 'A' when 2 then 'B' when 3 then 'C' when 4 then 'D' when 5 then 'E' when 6 then 'F' when 7 then 'G' when 8 then 'H' when 9 then 'I' when 10 then 'J' when 11 then 'K' when 12 then 'L' end ), DIAGNOSIS_02_12_CODE_POINTER_4 COMPUTED BY ( case diagnosis_code_pointer_4 when 1 then 'A' when 2 then 'B' when 3 then 'C' when 4 then 'D' when 5 then 'E' when 6 then 'F' when 7 then 'G' when 8 then 'H' when 9 then 'I' when 10 then 'J' when 11 then 'K' when 12 then 'L' end )); ALTER TABLE CLAIMSDETAIL ADD CONSTRAINT PK_CLAIMSDETAIL PRIMARY KEY (SERVICENO); CREATE UNIQUE INDEX CLAIMSDETAIL0 ON CLAIMSDETAIL(FILOPTOHCFACLAIMNO,SERVICENO); CREATE INDEX IDX_CLAIMSDETAIL ON CLAIMSDETAIL(FILOPTOHCFACLAIMNO); CREATE INDEX IDX_CLAIMSDETAIL1 ON CLAIMSDETAIL(INVOICEDETAILITEMNO); CREATE INDEX I_CLAIMSDETAIL_DATESTART ON CLAIMSDETAIL(DATESTART); Any help would be appreciated. Also, this table is used as is within our Delphi code for at least 5 years, and we do not want to change that code. -- Best regards, Daniel Rail Senior System Engineer ACCRA Solutions Inc. (www.accra.ca) ACCRA Med Software Inc. (www.filopto.com) |
From: Jiří Č. <ji...@ci...> - 2017-04-22 07:48:08
|
My *guess* is that it's the computed columns and the length is not discovered properly. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ |
From: Daniel R. <da...@ac...> - 2017-04-22 12:58:26
|
Hi, At April 22, 2017, 4:47 AM, Jiří Činčura wrote: > My *guess* is that it's the computed columns and the length is not > discovered properly. I was starting to suspect that, since the other tables that I was able to generate the code for didn't have computed fields. Are there any hints that I can use? I can try to look at the code to see if I can fix the problem. And, since I never did look inside the ADO.Net driver code. Can you guide me to what would be the area of code that I would need to look at? I'm willing to try to fix the problem, since this is not the only table in that database that has computed fields. -- Best regards, Daniel Rail Senior Software Developer ACCRA Solutions Inc. (www.accra.ca) ACCRA Med Software Inc. (www.filopto.com) |
From: Jiří Č. <ji...@ci...> - 2017-04-22 13:09:39
|
> I was starting to suspect that, since the other tables that I was able > to generate the code for didn't have computed fields. Are there any > hints that I can use? > > I can try to look at the code to see if I can fix the problem. And, > since I never did look inside the ADO.Net driver code. Can you guide > me to what would be the area of code that I would need to look at? > > I'm willing to try to fix the problem, since this is not the only > table in that database that has computed fields. You can create a table without computed field, generate the CF for it. And then do the same for a table with computed field. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ |
From: Daniel R. <da...@ac...> - 2017-04-24 15:16:58
|
Hi, At April 22, 2017, 10:09 AM, Jiří Činčura wrote: >> I was starting to suspect that, since the other tables that I was able >> to generate the code for didn't have computed fields. Are there any >> hints that I can use? >> >> I can try to look at the code to see if I can fix the problem. And, >> since I never did look inside the ADO.Net driver code. Can you guide >> me to what would be the area of code that I would need to look at? >> >> I'm willing to try to fix the problem, since this is not the only >> table in that database that has computed fields. > You can create a table without computed field, generate the CF for it. > And then do the same for a table with computed field. But, what could cause it not to recognize those fields properly? Because when I look in the database's system tables, the RDB$FIELD_TYPE and RDB$FIELD_LENGTH both have values in them, one would be VARCHAR(132) and the others would be CHAR(1). -- Best regards, Daniel Rail Senior Software Developer ACCRA Solutions Inc. (www.accra.ca) ACCRA Med Software Inc. (www.filopto.com) |
From: Jiří Č. <ji...@ci...> - 2017-04-24 15:39:38
|
> But, what could cause it not to recognize those fields properly? > Because when I look in the database's system tables, the > RDB$FIELD_TYPE and RDB$FIELD_LENGTH both have values in them, one > would be VARCHAR(132) and the others would be CHAR(1). Don't know. If you can confirm it's really those fields, put it to tracker and I'll look at it. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ |
From: Daniel R. <da...@ac...> - 2017-05-02 12:05:49
|
Hi, At April 24, 2017, 12:39 PM, Jiří Činčura wrote: >> But, what could cause it not to recognize those fields properly? >> Because when I look in the database's system tables, the >> RDB$FIELD_TYPE and RDB$FIELD_LENGTH both have values in them, one >> would be VARCHAR(132) and the others would be CHAR(1). > Don't know. If you can confirm it's really those fields, put it to > tracker and I'll look at it. Sorry for the late reply, I'm under a time crunch to complete a project. Once I have the time(hopefully within a month), I'll try to reproduce it with a database that contains one table with those kind of computed fields. There was another table that had one computed field, and that one was simpler in construct, and the Code First from Database wizard didn't have any problems with that table. So, it must be something with that one table in particular and the complexities of its computed fields. As soon, as I have a reproducible test case, I'll enter an issue in the tracker. -- Best regards, Daniel Rail Senior Software Developer ACCRA Solutions Inc. (www.accra.ca) ACCRA Med Software Inc. (www.filopto.com) |