Regenerate Data Model error CS0116: A namespace cannot directly contain members such as fields or methods

Epicor ERP 10
1

When running the Regenerate Data Model task within the Epicor Administration Console, I get the following error, “error CS0116: A namespace cannot directly contain members such as fields or methods”.

Has anyone else encountered such an error and/or does anyone have suggestions for resolving it so that the normal Regenerate Data Model task can complete?

NOTE: this is in Epicor ERP version 10.0.700.3

RegenerateDataModelFailsWithErrorCS0116
RegenerateDataModelFailsWithErrorCS0116.png706×524 224 KB

2

I suggest that you copy the content of the DataModelGenerator.log file. It is saved under C:\Users\YOURUSERID\AppData\Local\Temp\Epicor\DataModelGenerator

3

Did you find an answer for this? We are having the same issue and support is of no help.

4

Guys, whenever I see an “unable to build” error on the regeneration of data model, I always suggest suspending virus protection on the server. I had a 10.0 implementation where I swear I rebuilt data models many times over 6 months with no problem, then suddenly one day “unable to build.” Epicor Support tried to tell me it was virus protection, but of course we had made no changes to the virus protection so I discounted this input from them. When I finally tried it, just to get to the next step with Support, I felt like an idiot when it worked. It didn’t help that I had signaled some project risk to management. I hope you’ll try it, even if it doesn’t seem to be the issue.

5

Remember that the Entity Framework is trying to sync what the program “knows” about the database and what the database actually looks like. Several users have found that they created VIEWs or other items in their database and the EF doesn’t know about it and bombs.

Epicor hinted that they are working on a way to create these extra elements from withing the framework to keep these in sync.

Food for thought,

Mark W.

6

Have not found a resolution yet.

In case it helps anyone else, Epicor Support responded with:

The Regen problem you are having is addressed in the following KnowledgeBase page:
KB0029531 Getting .NET errors that cause Regen to fail - Doing a Data Model Regen, getting .NET errors and it stops.

Resolution

EVALUATION:
There could be several reasons for this error:

  1. Bad characters in the field name.
  2. An index could be missing from a base table.
  3. Possible manually added a schema outside of Epicor to tables that were created outside of Epicor also.

RESOLUTION:

For issue # 1
In Extended UD Table Maintenance, locate and remove any EXUD fields which has a special character in the field name (#, !, &, $, etc.) then rebuild the data model.
Use Attached SQL Script (QueryToFindSpecialCharactersInUDTables.sql) that can be used to search/find any EXUD fields that contains a Special Character.

For issue #2
Use this script to find the table without an index (NOTE- some tables have no index because they are for example, conversion tables):

SELECT SCHEMA_NAME(schema_id) AS SchemaName,name AS TableName
FROM sys.tables
WHERE OBJECTPROPERTY(OBJECT_ID,‘TableHasPrimaryKey’) = 0
ORDER BY SchemaName, TableName;
GO

If you find a table that is a base table without an index then you can run a script SIMILAR TO THIS ONE (this one is for the PartCost table):

ALTER TABLE [Erp].[PartCost] ADD CONSTRAINT [PK_PartCost] PRIMARY KEY CLUSTERED
(
[Company] ASC,
[PartNum] ASC,
[CostID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = OFF) ON [PRIMARY]
GO

For issue #3 Identify and then remove the “foreign” schema. The Regen should work fine after that.

QueryToFindSpecialCharactersInUDTables.txt (1.7 KB)

7

We got those as well and none worked. They also gave us this:
Delete from the production environment - In the e.g. c:\inetpub\wwwroot\E10DemoDB_102200_CURRNET\Server\Assemblies
When the AppServer starts, if these are missing, it will create new ones.

This did not work either. Ours works in Pilot but not Live. I just ran a SQL Compare and will be excluding any tables in Live that are not in Pilot. We also have to exclude the ReportStyle_UD table otherwise reports will not print.

8

Epicor Support suggested we compare Data Types in the UD Tables and we observed that the [UD_SysRevID] field is formatted as TIMESTAMP in the initial UD table but then formatted as INT in the ICE.ZDataField table. (See below SQL statement.) Epicor Support commented that this [UD_SysRevID] field is automatically created by the Epicor application when a new UD Table is created, so they’re not sure how to explain the data type difference, but currently think this may be the cause of the DataRegen failing. At this point they’re having me upload a copy of the database for them to analyze. Still waiting for that analysis.

Here is an SQL statement to compare the datatypes in the Part_UD table (if you have that one). For other custom tables, replace the ‘Part_UD’ with the name of your custom UD table(s):

DECLARE @TableName NVarchar(30) = ‘Part_UD’

;WITH ITable AS(
SELECT
c.Name
,c.DataType
FROM ICE.[Column] c
JOIN ICE.[Table] t ON t.TableID = c.TableID
WHERE t.Name = @TableName
),
ZTable AS(
SELECT
FieldName
,DataType
FROM ICE.ZDataField
WHERE DataTableID = @TableName
)
SELECT
@TableName [Table Tested]
,*
,CASE WHEN i.DataType <> z.DataType THEN ‘*** MisMatch ***’ ELSE ‘’ END AS [DataTpe-Check]
FROM ITable i
JOIN ZTable z ON i.Name = z.FieldName;

9

We got ours to work. We ran a DB compare between pilot and Live and then excluded all tables and views that were in Live and not Pilot. We are now going to work to figure out which one is causing the issue.

10

What do you mean “excluded”?

11

Epicor Support is telling us there is a “known issue” in version 10.0.700.3 which causes Data Model Regeneration to fail and for which they have developed a “patch” to the Data Model Regeneration problem.

One would suppose newer versions do not have this same issue.