Database Consolidation
K2 4.6 and later versions contain updates to the K2 database structures. These changes use the advances in performance of Microsoft SQL Server and include the schematization of the K2 data structure.
The structure of the K2 Databases could be different between new installations vs upgraded installations. However, as both types of installations utilize the same database schema, the K2 Server functions in the same manner.

A new installation will create a single database. The contents of the database is schematized to match the database layout of previous K2 versions. The following list presents the associated schemas:
K2HostServer
- Category
- CustomUM
- Designer
- Environment
- Eventbus
- HostServer
- Identity
- PackageDeploy
- Relationship
- Server
- ServerLog
- SmartBroker
- SmartForms
- SmartObject
- Workspace

When upgrading a pre-existing K2 installation, the existing K2 databases are not consolidated into one database. However, the following schematization and update procedures are done to streamline data storage and improve the performance of the K2 Server:
-
Creation of Synonyms
- Synonyms will be created with the object's previous names and (dbo) schema to support binary reference.
-
Clean-up of Database objects
-
Removal of depreciated code:
- Text -> NVARCHAR(MAX)
- Image -> NVARBINARY(MAX)
- Old Style OUTER JOIN
- Replaced sp_openxmldocument with xQuery
- Unicode Storage
- Preparing the database for case breaking
- Using Scope_Identity instead of @@Identity
- Renaming the Indexes
- Making use of IF EXISTS(SELECT 1… instead of IF EXISTS(SELECT COUNT….
- Using Fully Qualified Object Names
- Renaming Tables
-
Removal of depreciated code:
Dealing with Custom Database Objects
All stored K2 procedures, functions, and views have been dropped and re-created as part of the databse schematization that occurs when upgrading to K2 4.6:
- All dbo objects have been moved to the correct schema
- All code in stored procedures, functions, views are updated to call the schematized objects.
- The K2 4.6 update creates synonyms for these objects – and the referenced objects must be removed from the dbo schema in order to do this successfully.
It is possible to preserve your custom and future database objects within your K2 databases. To do this you must move your custom objects to their own schema – for example, move [dbo].[MyCaseSP] to [CaseSchema].[MyCaseSP] before performing the upgrade. Use a simple script if you have the names of the objects you want to preserve. If you do not want to update your code to reference the schematized objects then you will need to create synonyms for them.
It is a best practice to create all custom objects within the K2 Databases with their own schemas, rather than using a dbo within the K2 schema.
Performance Enhancements
FileGroups
Database files can be grouped together in filegroups for allocation and administration purposes. Some systems can improve their performance by controlling the placement of data and indexes onto specific disk drives. Filegroups can aid this process.
There will be 5 filegroups in the consolidated database:
- FG_SERVERLOG (K2HostServer)
- Serverlog
- FG_SERVER (K2HostServer)
- Server
- FG_SMARTBROKER (K2HostServer)
- SmartBroker
- CustomUM
- SmartObject
- SmartForms
- Relationship
- FG_HOSTSSERVER (K2HostServer)
- Category
- HostServer
- Workspace
- Designer
- Environment
- Eventbus
- PackageDeploy
- FG_IDENTITY (K2HostServer)
- Identity