We had a similar problem, but with the help of K2 managed to find the root cause, and a work around (at end of this entry).
In our case the error messsage was "Check and Build Process
Error: FAILED - c:\program files\k2 blackpearl\Processes\administrator\obj\Debug\Deployment\administrator.msbuild(59,5) : error : SmartObjectServer Exception: Could not publish SmartObjectDefinition to server: Error refreshing ServiceInstance 'WorkflowReportingService'. Service returned : 'Workflow Reporting SO Service: Invalid object name '_procset'.".
The error occcurred for the Deploy operation either in the K2 Web Designer, or K2 Studio (if "Create Workflow Reporting SmartObjects" was left checked).
We found two contributors to the problem:
[1] Our database collation setting was "SQL_Hungarian_Cp1250_CI_AS", and
[2] inconsistent honoring of capitalization when referencing Table and/or Field names in stored procedures.
The key value in the above error message is the reference to '_procset' by
one of the stored procedures in the K2Server database, which is a
reference to one of its tables, a table formally named _ProcSet.
Aspect [1] is related to a "feature" of the SQL_Hungarian_Cp1250_CI_AS collation setting that honors several character combinations of the language that are normally taken together; the letters 'c' followed by 's', the Hungarian "ch" phonetic, is one example, and the letters 's' followed by 'z', the Hungarian 's' phonetic, is another.
To reproduce, open up SQL Query Analyzer and create a scratch database with SQL_Hungarian_Cp1250_CI_AS collation setting, create a _ProcSet table, then try a few queries on that table with various capitalizations:
create database foo collate SQL_Hungarian_Cp1250_CI_AS
use foo
create table _ProcSet (id int)
select * from _procset (will fail with message "invalid object name '_procset')
select * from _Procset (will fail with same message)
select * from _procSet (will succeed)
select * from _ProcSet (will succeed)
Noting that the "CI" part of the Hungarian collation setting means case-insensitive, we'd first of all expect this to be an SQL bug. E.g., one would expect "insensitive" to really mean "insensitive" in any/every way. However, we are not linguistic experts, and the outcome was that the issue was being submitted to Microsoft by K2. The problem will, of course, occur for any collation setting that includes similar treatments of multi-letter combinations, and procedures or queries don't honor the capitalization of the object names.
Aspect [2] is being addressed by K2. I.e., some kind of patch or service pack with stored procedures cleaned up to insure that references to objects do honor the capitalization of object names.
The short term workaround:
change the collation setting of both the K2Server and K2ServerLog databases:
alter database K2Server collate Latin1_General_CI_AI
alter database K2ServerLog collate Latin1_General_CI_AI
(K2 was also going to insure their installation documentation specifies requirements for case insensitive collation configurations).