Frequently asked questions about shared tables and master sites

Q: When would I want to set up a master site?

A: We recommend that you set up a master site even if you do not plan to share any tables at this time. (The only exception might be if you have only one or two sites to maintain.)

If on-premises, master sites currently allow you to centralize entry of customers, items and vendors and to centralize maintenance of licenses and users.

If a cloud environment, master sites currently allow you to centralize entry of customers, items and vendors and to centralize maintenance of users.

Q: On-premises only: Why would I want to set up shared _all tables?

A: If on-premises and your system is replicating a lot of data among many sites, processing time is reduced when the _all tables exist only at the master site.

For example, your system replicates Inventory/Transfer data between 10 sites. A user releases a job that has an “exploding” bill of material, generating thousands of record updates throughout the system. If the inventory-related _all tables are stored at each of the 10 sites, system processing speed will be affected during replication of these records to all the sites. If the _all tables are stored only at the master site, processing will be much faster.

Q: Why would I want to set up shared user tables?

A: It allows one administrator to maintain one set of users and user permissions in the master site that are applicable to all of the using sites on the intranet. This information is included:

• User information

  This can include application-specific data such as user initials, multi-site group, etc.

• Groups information, including user-group assignments and user-group authorizations.

You also have the option to exclude the AccountAuthorizations_mst, UserGroupMap_mst, and/or user_local_mst tables when you share user tables. This allows administrators to maintain users and most user settings in the master site, but apply different permissions for those users in each of the sites. Or you can maintain authorization groups globally (so they are the same for all sites), but maintain the user groups locally, so users can be assigned to different permission groups at different sites within an intranet.

Q: Can I set up some tables to reside only at the master site, and other tables to be replicated at all sites?

A: If on-premises, then yes, for _all tables. No, for user tables.

If a cloud environment, then no, for user tables.

Q: Which tables does it make most sense to maintain at a master site rather than replicating?

A: This depends on your data, and the parts of the system you use the most.

Q: Which tables can only be maintained from a master site?

A: If on-premises and you are using intranet licensing, then the license tables can only be maintained from the master site. Other than that, you can maintain data at any site (slave or master site).

If a cloud environment, then you can maintain data at any site (slave or master site).

For both environments at the master site, special forms are available for maintaining data about multi-site vendors, customers, and items. You can still maintain this information for specific sites from those sites. But from the master site, you can maintain vendor, customer, and item data for all the sites on the intranet.

Q: On-premises only: Can I have a master site for one intranet and not for another one? If so, why would I want to do that?

A: Yes. The other intranet may not have large _all tables, or performance is good. Then for that intranet, there might not be a need for shared _all tables. Also note that if an Intranet is flagged as External, then it could not have a master site.

Q: Can I set up a master site any time, or just when setting up the application initially?

A: At any time.

Q: Can I change the master site after it is set up?

A: If on-premises, then Yes. Some of the _all or user tables at the slave sites have been dropped and would have to be rebuilt, and the data that resides only in the master site’s tables would have to be reloaded into the rebuilt tables. You can do this in the Intranet Shared Tables or Intranet Shared User Tables forms.

If a cloud environment, then Yes. Some of the user tables at the slave sites have been dropped and would have to be rebuilt, and the data that resides only in the master site’s tables would have to be reloaded into the rebuilt tables. You can do this in the Intranet Shared User Tables forms.

If you remove a master site, these features that depend on a master site will no longer be available:

• Multi-Site Vendors form
• Multi-Site Customers form
• Multi-Site Items form
• On-premises only: Intranet licensing

Q: On-premises only: Can I have a master site on one intranet and no master site on another intranet, and still perform replication between sites on both intranets?

A: Yes.

See the example in the Mongoose Replication Reference Guide.

Q: Why would I use a master site if all of my sites are in a single database?

A: The Multi-Site Customers, Multi-Site Items, and Multi-Site Vendors forms can only be used from a master site.

Since all sites are in the same database, most user tables are shared across all sites even without a master site and without setting up Intranet Shared User Tables. However, you can share these user tables only if a master site is defined, through the Intranet Shared User Tables form: AccountAuthorizations_mst, UserGroupMap_mst, user_local_mst.

Q: Can I add a new site to an existing intranet that has shared tables?

A: Yes. If on-premises, see the online help. If a cloud environment, then contact your Infor representative.

Q: On-premises only: Can I add an existing site that is currently on a non-shared intranet to an intranet that has shared tables?

A: Yes.

Q: On-premises only: Can I change an existing site that is currently on a shared table intranet to be on a different intranet?

A: Yes. You would need to unshare the tables for the site’s current intranet, which then rebuilds them at all the sites in the intranet. Then you would move the site to another intranet. And then you would reshare the tables in the old intranet.

Q: What happens to users at the other sites if the master site goes down for an extended period?

A: All sites on the intranet that link to the master site will not be able to access/update the tables that are only on the master site.

Q: On-premises only: Do I still need to set up replication categories and replication rules at each site?

A: Yes, if the sites are in different databases. Even if you select a category to be shared (controlled by the master site), you still may have to replicate that category, because there may also be other tables (not _all or user tables) as well as non-table data, such as stored procedures, included in the category.

Although shared tables still appear in the replication category, those tables are not replicated when a rule for that category is set up between sharing sites. Also, if you try to add a shared table to a new replication category, the system will not allow it unless you are in the master site.

Q: On-premises only: Can you change the “Reports To Entity” structure for sites on a shared-table intranet? Can a site that reports to an entity be on a different intranet than the entity?

A: There is nothing to stop it, but this is not a recommended approach.

Q: Will my site see data from all other sites on the intranet when we share a table?

A: If the dropdown list in a form is based on an “_all” table, and if you are in a using site where that _all table is actually a view, then it will access that view.

If you share user tables, an administrator at any site on the intranet can see and update data for all users and groups, if the administrators have the appropriate permissions. If you originally share user tables and then change to per-site user tables, the user and group information for all users on the intranet is loaded into the tables at each non-master site.

Q: On-premises only: When I upgrade to another service pack or version, will the upgrade utility recognize when a site is using a view and not try to update an non-existing _all or user table?

A: Yes, the upgrade process will check for views before trying to add or change columns in an _all or user table. However, if you are sharing user tables, you must first unshare the tables, upgrade, and then reshare the user tables. These steps are not required for shared _all tables.

Q: On-premises only: If I have existing sites containing the same user names and group names or IDs, what happens when I share the user tables?

A: If the system finds matching user names or group names with different IDs in different sites during the sharing process, it assigns new IDs to the names in the shared user tables at the master site. It also updates the IDs in any non-shared tables that reference the IDs at the non-master sites.

However, the processing assumes that you do not have conflicting user names, for example, the user name "jjones" is unique among all users on all sites on the intranet. If you have existing sites with conflicting user names, for example, "jjones" is James Jones at site OH but Jean Jones at site MI, then you must change one of the user names and all its referenced areas before sharing the user tables.

It is best to share the user tables before sites contain user and group data, if possible. Processing runs much faster with minimal data, and you are less likely to encounter conflicts.

Q: Can I use the master site to copy records from one site to multiple other sites?

A: You can use the Multi-Site Customers, Multi-Site Vendors, and Multi-Site Items forms to copy records to multiple other sites in the same intranet as the master site. The other sites must be in the same multi-site group as the master site. Item BOMs are not copied with item records when you use this method.