[ FAQ ] Epicor ICECommon Database

Kinetic ERP
, , ,
1

What does the ICECommon database store? Why was it introduced?

The ICECommon Database stores information and system data that Kinetic uses as read-only throughout its applications. This database improves installation and upgrade performance, making more storage available across the platform. Kinetic creates one ICECommon database for each SQL Server instance and major version. Each Kinetic database automatically connects to the ICECommon database matching its version number.

Can I remove or rename the ICECommon database?

No, the ICECommon database must be available for Kinetic to run properly. Do not modify or delete it.

When was the ICECommon database introduced? What tables does it contain?

Release Table(s) Added Note
2023.2 Ice.FieldHelp Previously stored in XML files on the smart client. Now available to the browser clients.
2024.1 Ice.ICECommonVer, Ice.ReportStore Previously deployed to each SSRS database during deployments. Now only RDL files used will be uploaded to SSRS.

Kinetic Development will add more read-only and shared data to this key database for each version, ensuring common data is consistent across all Kinetic installations.

Where is the ICECommon Database documented?

  • The Kinetic Architecture Guide contains a chapter on the ICECommon Database since 2023.2.
  • The Kinetic Help contains articles since 2024.1.

What’s the name of the ICECommon database for my release?

The ICECommon database name is suffixed by the ICE version, e.g., ICECommon_4.2.400. The equivalence between Kinetic and Ice versions is covered in KB0119789, Comparing Versions of Kinetic/ERP, UX Platform, Ice Framework, and .NET.

How to create or recreate it?

If you run a Cloud environment:

  • It installs with Kinetic and automatically upgrades with each Kinetic release.
  • The installation or upgrade process creates/updates this database in the background.

If you run an on-premise environment:

  • You must manually upgrade this database using the Epicor Administration Console (EAC) or the Database Migration tool (command-line tool).

  • It will also be created if the ICECommon database is missing when a new or demo database is created via the Epicor Administration Console (EAC).

    You can use this feature if you have no ICECommon database (or it was somehow deleted):

    • Open the EAC to Database Server Management > [server name].
    • Select Add New Database from the Actions menu.
    • Enter a temporary name (e.g., “TempEmptyDb”).
    • Complete the creation process.
    • Check that the ICECommon... database was created.
    • Delete the temporary database.

What happens during upgrades?

When upgrading, the common database will also be upgraded, but the old one will remain. When customers install a test database at that new level or upgrade their pilot environment, the database will be created and updated. But when they upgrade their live environment, they’ll just use the one there. This means that whatever data is in the common database is no longer needed as part of the DB upgrade process, saving time in this critical step of system downtime.

12 Likes
2

Thank you for the write up, I wondered what this was and how it impacted upgrades and how it impacted upgrading a test environment to a different release than the live environment when both were on the same SQL server.

1 Like
3

For on-prem sites, do not forget to add this database to your SQL backup and maintenance plans.

5 Likes
4

Great point!

5

There seems to be a bug… (or a feature) here I have a DB
2023.1 → 2024.1 that Created ICECommon_4_3_100

Then a few weeks later I reset the Db back to 2023.1 and re-did the uplift (same DB name and everything just restore from backup re-uplift)

2023.1 → 2024.1 that created ICECommon_4_3_1004_3_100 ← that looks a hell of a lot like they appended the version to the end of the version?

image

Halp! @Rich, @Olga

the problem is I have 4-5 DB’s in the same SQL box

the problem is I have 4-5 DB’s in the same SQL box am I gonna get
ICECommon_4_3_1004_3_1004_3_1004_3_1004_3_1004_3_1004_3_1004_3_100

2 Likes
6

We need an idea to simply make a new schema in the Epicor Database and get rid of IceCommon :slight_smile:

3 Likes
7

Here’s what I need to understand. I have the following Dbs (yes I know… :gun:me now and put me out of my misery… you try upgrading all these :man_facepalming:)

EpicorTest
EpicorPilot
EpicorTrain
EpicorA
EpicorB
EpicorC
EpicorD
EpicorE
EpicorF

They are all share one or two SQL Servers… As I understand it the ICE Common DB is per version and it stores the ReportStore (Reports and Custom Report?) does this mean that we are assuming that all of those DB’s above are sharing once ICE Common Db (since they are all in the same version) and if so… Can I no longer have different versions of the same report in different Dbs?

IE: Development B has an Updated copy of SSRS report but I don’t yet want to deploy it to Development C or Pilot

2 Likes
8

OK From the Help
Reports save in the following locations:

  • System reports install in the ICECommon database within the Ice.ReportStore view. Kinetic then pulls these system reports into the Ice.ReportStore database table, so you access these system report files from this table.
  • Custom SSRS Reports you create save to your Kinetic database in the Ice.CustomReportStore table. Do this in Report Style Maintenance by selecting the Upload SSRS Report action to upload a new report style.
  • BAQ reports you create save to your Kinetic database in the Ice.CustomReportStore table. Like custom SSRS reports, custom BAQ reports save to this table after you upload them to the server using the BAQ Report Designer.
  • The version history for the custom and BAQ reports you create save to your Kinetic database in the Ice.CustomReportStoryHistory table. This table starts recording version information after you upload the second and later versions of each custom SSRS and BAQ report.

:white_check_mark: It appears that Ice.Common just contains “System Reports” not Custom Reports.

9

It may be a bug as you stated because the Architecture Guide has the following:

Kinetic creates one ICECommon database for each SQL Server instance and major version. Your environments automatically connect to the ICECommon database.

It should share a single one between major versions.

1 Like
10

Ola hallengran "User databases*

1 Like
11

The ICE_Common DB contains Static information so a single archive should suffice - you should redo the archived copy after each Update. We are gradually moving our “Seed” and static data from the User DB and the File system to the ICE_Common DB.

Moving static information to ICE_Common reduces the size of the Kinetic DB, reduces the time required to Upgrade, and helps with permissions, performance, and environment management when compared with disk based software elements.

The ICE_Common DB is configured as Read-Only and the DB is not referenced directly from the Kinetic AppServer so additional SQL connections are not needed. Instead, the ICE tables in the Kinetic DB reference the ICE_Common data via SQL Table Pointers.

As already noted, the Base RDL definitions are in the ICE_Common but the Custom RDLs are stored in the Kinetic DB.

@josecgomez - thanks for the information on the Upgrade “oddity”. We are investigating.

8 Likes
12

As long as you can access said schema from tools like baq unlike ecf…

1 Like
13

Out of curiosity, how many records is this table supposed to have? I’m missing Field Help descriptions for nearly all fields (but still available on the field help “technical details” tab) in a 2023.2 installation. I just did a query and there were under 200 rows in the Ice.FieldHelp table.