Or maybe it would be interesting to know, how K2 processes run on a server. Do they run in address space of K2Server.exe? Or K2Server creates an AppDomain for every process? Maybe an AppDomain with some lower rights?

Because thinking about this, my DataSet has a precompiled connection string, which should be correct (not should be, it is correct) but an event failed with message:

"An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)"

This looks like my assembly doesn't get enough rights to connect to server if the connection string is correct.

---

K2 server runs as K2Server.exe, under the identity specified in your list of Services on the server

if you were to create a standard .NET config file for K2Server.exe, i.e. K2Server.exe.config then you should be able to put your config values in there

this should save you hard coding your connection string within your assembly

---

Hi.

Yes, of course I tried this, but it's not working. I created K2Server.exe.config which contains following (passwords are changed):

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
    </configSections>
    <connectionStrings>
        <add name="VBL.SchvalovacieProcesy.DAL.Properties.Settings.ProcesyConnectionString"
            connectionString="Data Source=dbserver;Initial Catalog=crm;User Id=sa;Password=password"
            providerName="System.Data.SqlClient" />
    </connectionStrings>
</configuration>

And it's not working. But, when I have correct connection string in assembly then it works just fine. But, I don't want to recompile my assemblies when connection string has to be changed and then recompile process so assemblies should be upload again to server.

So, have you tried this, is it working at your K2 server?

And one more question is, is there any easy way of writing debugging information to K2 console window? Maybe the I should try to log something to see, why this configuration file is not working.

---

mifko:

Hi.

Yes, of course I tried this, but it's not working. I created K2Server.exe.config which contains following (passwords are changed):

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
    </configSections>
    <connectionStrings>
        <add name="VBL.SchvalovacieProcesy.DAL.Properties.Settings.ProcesyConnectionString"
            connectionString="Data Source=dbserver;Initial Catalog=crm;User Id=sa;Password=password"
            providerName="System.Data.SqlClient" />
    </connectionStrings>
</configuration>

And it's not working. But, when I have correct connection string in assembly then it works just fine. But, I don't want to recompile my assemblies when connection string has to be changed and then recompile process so assemblies should be upload again to server.

So, have you tried this, is it working at your K2 server?

And one more question is, is there any easy way of writing debugging information to K2 console window? Maybe the I should try to log something to see, why this configuration file is not working.

i am not using this no, but was told this was possible by one of our K2 consultants, should we ever decide we need to use it

personally, i would contact the support team & ask them to confirm whether this is the case, in case i'm leading you down the wrong path here but a quick search also comes up with this post http://forum.k2workflow.com/viewtopic.php?t=1504&highlight=config

on the other hand, can you confirm that you restarted the K2 server in order for it to take on the new config file? your config file also looks like a .NET v2.0 config file, have you definitely configured your K2 server to be running under v2.0 of the .NET framework?

by the way, our chosen method of implementing this is to keep the connection string in the K2 string table and then pass the connection string to the assembly that wants to use it, either as a parameter of the method calls where it's required or initialising it in a static string within the assembly so that it just gets set once for all future calls, depending on the requirement

---