Skip to main content
Nintex Community Menu Bar

We are moving our K2 on-premises server to another server. So, instead of installing 5.4, which is what we are currently on, I chose to install K2 5.5 fresh.

 

During the install we failed with this error:

 

19379i7742A2463F7D5E4F.png

 

Do we need another installer deployed with a fix for "SourceCode.Data.SmartBroker.inject.sql" ??

 

Does anyone have any tips or can help? Thanks.

The installer we used is K2 Five (5.5) (5.0006.1000.0).exe




 



 The error we see while installing


So we went back through the instructions and applied Azure SQL DAC pack here: https://help.nintex.com/en-US/K2blackpearl/ICG/current/default.htm#Install/AzureSQL/AzureSQL_BP.htm



 



Then we went back through the clean install of 5.5 and now have this:





 



Which leads to this https://community.nintex.com/t5/Technical-Issues/Powershell-Commands-to-Encrypt-and-Decrypt-Data/ta-p/123784



 



However, the instructions say this, "SQL Azure does not support this method so you can only use the PowerShell commands in this article with on-premises SQL servers."



 



But Azure SQL also has default data encryption on by default:





 



So now what? Should I get Nintex professional services to help now?



 



 



 


https://help.nintex.com/en-US/platform/ReleaseNotes/K2Five.htm looks like we have to find 5.0005.1000.4 installer to fix this issue


Hi



 



5.0005.1000.4 is K2 Five 5.4 installer. Do you have an open Nintex case for this?



 



Thanks



Vernon



 


NOPE





 


I'm going to file a ticket now. and 5.4.4 was not the solution. 


Hi Fred,



 



Did you find a solution to this issue? , I facing the same.


We gave up on running K2 on SQL server Azure.



 



Our consultant said she never has luck running it this way and the true work around would be to temporarily stand up a Windows VM in Azure and do the K2 install with the K2 DAC agent in that Azure VM. After the install, tear down the DAC VM.



 



So we went back to on-premises SQL server. Shame, because it would have been nice to reduce our infrastructure and costs with an Azure SQL server.


Reply