This article was created in response to a support issue logged with K2. The content may include typographical errors and may be revised at any time without notice. This article is not considered official documentation for K2 software and is provided "as is" with no warranties.
This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.
Explaining the differences between an K2 Reconfiguration and K2 Repair and pit falls to avoid make the wrong choices.
Before You Begin
An important warning to keep in mind is that a K2 Repair will overwrite any cold fixes – at least DLLs you put into a K2 folder/GAC with the original versions, but the Database side of changes introduced with cold fixes won’t be reverted.
So, keep in mind that a backup copy of the code fix applied needs to be made.
K2 configuration is basically changing the settings in the DB and the config files.
K2 Repair is different as it is also supposed to do a fresh copy of the binaries.
This is in the event, something corrupted the K2 files, i.e. hard disk failure.
If a dll is in use and you have corrected the issue causing it, you could try a repair to see if you can get the dll to be updated again.
K2 Repair doesn’t work for a failed Database upgrade. Failed DB upgrades need to roll back to do good snapshots. Then fix the issue causing the failure and try again. So, server snapshots and Database backups are very important for upgrades.