Deciding whether you need sites in separate databases
By default, your system is set up to have all sites in a single database. Use this information to determine whether your company needs multiple databases that contain sites.
Switching from one option to the other
The copied site remains in the source database. If any other remaining sites are still valid in the source database, they must be moved to a new database, because there is currently no way to remove a site that contains transactional data from a database.
Differences between single database vs. multiple databases
You must understand the differences between the options.
_All tables vs. base tables
If sites are in different databases, the _all tables in each site database contain data specific to other sites on the current site’s intranet. The base (_mst) tables in each site database contain only data specific to the current site. The _all views point to the base tables.
If all sites are in one database, the _all tables still exist but do not contain any data. They are simply views pointing to the base tables. The base tables contain data for all sites in the database, including the current site, filtered by the site_ref column value. However, if at least one site listed in the sites table for an application database is in a separate application database, then the _all tables are populated, and the _all views point to the _all tables.
Event handlers
Application Event System events and event handlers (including the Active option) are defined for a database, not for an individual site. However, you can use the Applies to Sites field to specify the sites for which an event handler is active.
For more information about event handlers, see the Guide to the Application Event System.
Optional modules
Country-specific localizations, some industry packs, and some optional products are licensed for an application database; however, you might not want all of the sites in a database to access all of the features in each of the optional modules. For these products that are installed with SyteLine, you can use the Optional Modules form at a site to enable module features for that site.
See the Infor SyteLine Licensing Administration Guide for more information about what it means to enable a module for a site.
Speed of replication
Replication between sites is faster if the sites are on the same SQL server. However, replication between sites within the same database is not any faster than for sites in different databases on the same server.
Multi-site tables and shared tables
Multi-site tables include a site_ref column that indicates the site to which a row of data belongs. Most application tables are multi-site and have an _mst suffix. Several Mongoose tables are also multi-site.
Most Mongoose tables, and a few application tables, are considered to be “shared” by all sites in a database.
For more information, see the white paper, Coding and Schema Changes Made in SyteLine 9.00 for Multiple Sites per Database.
Data visibility
If you have two sites in the same database that are not replicating data between each other, and are not sharing _all table data, a SQL user with direct database access to one of the sites can still view base (_mst) table data for both sites. If that is not desirable, then the two sites should not be placed in the same database.
Process defaults
Settings on the Process Defaults form apply to all sites in a database.
Modified reports
For form-based reports or Dataview reports, you can use the scope level to distinguish between sites.