E10.0.700.4 Data Model Regenerate Caused Record Visibility Issue


Yesterday we added a UD field to the ShipDtl record and regenerated the data model. Now two things are happening, one we are not able to add lines to pre-existing packs from yesterday (the day of the regen) however new packs function fine. Secondly, and more importantly when we go to invoice a pack from yesterday we do not see it in the selection area. This has occurred on different machine with different users. We’ve tried rerunning the regen, clearing client cache, and trying different users on the same machine, nothing has helped. Any input on a direction to go would be appreciated.

I’m assuming you also recycled IIS at some point?

As @Aaron_Moreng has mentioned, active sessions will still have the old data model loaded which will cause many issues between client and server communications. Reset IIS or your application pools and the issue should be resolved.

The steps we followed were to regenerate the data model then stop and start the application pool. I think recycling the IIS is the same as starting and stopping the application pools or is that incorrect?

Do you have any data directive on the ShipDtl table - if so, have you tried disabling while testing?

Also, what is the data type and default of the field that was added? Was this the first UD field added to ShipDtl?

Can you run a quick BAQ to take a look at the data that is listed on that new column for the pre and post BAQ to see if there may be some issue with the validity of that data? (i.e. are they all NULL or do they have some value like 0 or empty string)

Also, I generally perform a iisreset from the command prompt when the specific application pool restart fails through the admin console. While this is not officially required and will restart everything that is tied into your iis on the production server, I’ve found that sometimes this escalation method is required when a stop/start gets stuck or doesn’t function as we’d expect.

Yes this is the first UD field in ShipDtl, however not our first UD field in the system.

The ud field added was an Integer field, when I create a BAQ and query the ShipDtl table The field appears and shows zeroes.

I’ll look into recycling the IIS via command prompt.

I’m looking at resetting the IIS through the command line, will this reset everything using IIS on that machine? I guess if you could give an example of what you write to accomplish this would be helpful to me and help further my understanding. I’m just wanting to make sure I’m understanding this correctly before moving forward.

Use the Recycle IIS button on the Epicor admin console. I think Epicor has it’s own application pool…but I’m not 100% sure.


As @Aaron_Moreng has mentioned, the Epicor admin console has “everything you need” to recycle Epicor’s application pool. Assuming you’ve tried that route and have not had success, if you open cmd as an admin and type “iisreset” it will reset your entire IIS on that server rather than just the Epicor-related application pool. As a disclaimer, I don’t know if this is okay to do in your environment because I don’t know what other applications you may be hosting on this server. Also, you shouldn’t do this if it will negatively impact production. If you have users connected to any of these applications, the applications will restart, the users will be kicked out, and potentially in-progress data can be lost.

Yes, this will reset everything using IIS on that machine.

1 Like

I believe I’ll stay within the confines of the admin console. We’ve restarted the application pool twice and it doesn’t seem to help. Thanks for the input so far Joesphmoeller and Aaron_Moreng we’re continue to troubleshoot the issue.

@EpiUser - see this thread: Object reference not set ... On NON-customized form - #11 by Noffie - ERP 10 - Epicor User Help Forum

TL;DR version: Althought the official line from Epicor Support is that you should NEVER need to do an IISRESET command, there is some anecdotal evidence, and even a mention of it in the official documenation on doing a Regenerate Data Model, that sometimes a full reboot/IISRESET is the only thing that does the trick.

1 Like

Thanks @Noffie for this terrific thread reference. @aidacra does a great job at describing all of the disadvantages to doing this. As you also note, anecdotally I’ve found that this is the “unplug, plug back in” fix that is sometimes required.

To add support to @Noffie’s suggestion. Whenever we’ve added a new UD field we’ve had to do IISREST about 30-40% of the time it seems.

Also appending @josephmoeller’s disclaimer. I don’t know your environment, so you’re the best judge when/if a reboot/IISREST is safe to try.

One note for those back in 10.0…

We fixed a timing issue with deploying the UD fields between 10 and 10.1. In 10.0 you could ‘stage’ the changes by doing a sync in the UD form. Then deploy them in Admin Console via the data model regen.

We combined all that effort behind the admin console regen now. If you don’t do the regen immediately after the sync in 10.0 you get goofy results.


I think this is exactly what happened. the ShipDtl records created between the time the UD field was synced and the time when the data model regen happened, which was about half a day, seemed to have issues. Deleted the UD field from the environments and this corrected all the issues. We looked at the regeneration log and investigated the regen thoroughly and it all looked correct. Just something buggy happened…

I think creating the UD field, syncing it, then regenningthe data model immediately will be the route we try next as we still need to implement the UD field.

Depending on the table extended and how the table is used oddities like that could happen back then. Support had a data cleanup script if you need it to recover those records.

1 Like

Check with Epicor support. We had an issue like this with on a client
system and they issued a fix.

You could try touching the records via DMT–query the affected records out
and then update one of the fields and see if it fixes itself. (No

Since the UD fields are kept in a separate table, my theory is that Epicor
does an inner join under normal circumstances, and that keeps the records
from being found.

Either that or something else. :slight_smile: