You can use the wProcDelete stored procedure in the transaction database.

The wProcDelete stored procedure works as follows:
The wProcDelete stored proc have 2 parameters:
o @ProcName NVARCHAR(128) - The proc name you want to remove. Remember that this is the FullName and NOT the Name
o @Version INT (optional) The version you want to remove.

Examples:

exec wProcDelete 'K2CSD-CS-SetXML' (Will delete all the versions)

exec wProcDelete ' K2CSD-CS-SetXML',5 (Will delete only version 5)

---

First of all I think it's strange that there is no way to properly delete processes using the tools provided, such as the Service Manager.

Second, the stored procedure you are referring to does not expect the FullName, but the Name. I tried the FullName, but it didn't help, so I tried the Name and it worked. I looked into the database and noticed the stored procedure indeed checks the Name field.

Third, the problem with the Name field is that I could have two processes within the server that both have the same Name, but are exported from two different Projects in K2.net Studio. That means I can only remove both of them or none.

In my scenario I was just playing a little with the features, setting up a demo and then realised I needed to change some things. I created a new project to do the changes in and had the same process (with a few differences, but the same name).

I can certainly imagine other scenarios where duplicate names appear. Another problem with this is that the instances of all these processes will appear in the same worklist. (although I didn't yet went deep into it to see if I can filter based on the FullName, but didn't see any way of filtering on it right away)
--edit--: I just saw that filtering based on FullName is possible... --edit--

Isn't there a better way to handle these things?

---

I would actually argue that the server should either:

1) Not allow duplicate process or destination queue names
2) Provide a way to distinguish between them from the reports and the Service Manager.

I created a new process for a colleague to play with. I renamed the process before I exported it, but I didn't rename any of the destination queues. Oops. Now I have two of every queue, and I can't actually tell which queue goes with which process. I _presume_ Destination Queues are not global to the server, but local to a process (see dbo._DestQueue.Root in the K2 database) which begs the question "Why are they not listed below the process itself?" I could see where global queues would be useful, though.

I had to manually whack the duplicate queues. Plus the one I had renamed 'cause of typo...

In fact, on the topic of queues, I can't quite figure out why the ability to add/edit queues isn't in the Service Manager. It would be nice to allow non-developers (say the business process owner) to manage the queues without Studio. I ended up using AD groups, but that just shifts queue membership management to a different IT department, instead of into the hands of the process owner (who has the Service Manager). Perhaps we'll see finer-grained control over these sorts of things in BlackPearl

---

I have tried to delete a process with the following way :

exec wProcDelete 'ProcessTest'

where "ProcessTest" is the name of the process that i want to delete


and it works

---

I had a look at this stored procedure this morning and was unable to find where the filtering was located for FullName instead of Name.

We recently did a reorganization of our process structure and now we have processes in the _procSet table with the same Name. I want to make sure that we don't wack all the process with the same name.

 Where is the filtering done in the stored procedure?

 Thanks.

---

Hi david,

Can We remove the project already exported into the server?

---

There are some unsupported scripts that you can get from K2 Tech Support that enable database clean up.  You can ask for "K2.net 2003 Clean-up Stored Procedures".  Please note these are NOT supported for production systems but on development systems you can use it - just remember to make backups of your dbs before running any script.

---