I can reproduce it, when the proc is represented as:
"[emda_cms2].[dbo].[sp_CaseStudies#SetLiveStatus]"
using this code:
/// <summary>
/// Tests to see if wacky names aren't butchered by the name mangling code for name overwriting
/// </summary>
[Test]
public void ProcNameManglingWithWackyProcNameTest()
{
string procName = "[emda_cms2].[dbo].[sp_CaseStudies#SetLiveStatus]";
DataAccessAdapter adapter = new DataAccessAdapter();
string newName = adapter.ProcNameChanger(procName);
Assert.AreEqual(procName, newName);
}
where ProcNameChanger is:
public string ProcNameChanger(string storedProcedureToCall)
{
DynamicQueryEngine dqe = (DynamicQueryEngine)CreateDynamicQueryEngine();
string procName = dqe.GetNewPerCallStoredProcedureName(storedProcedureToCall);
procName = DynamicQueryEngine.GetNewStoredProcedureName(procName);
return procName;
}
When I specify the proc without '[]', it works. Clearly a regexp thing. I'll see if I can get this fixed.
As a workaround: please use proper procedure names. Characters like '#' arent recommended for proc names, the same goes for the sp_ prefix: use another prefix than sp, as SqlServer will then always first search the system databases for a presence of the proc if you use a prefix of 'sp'. Use pr_ or something instead.
Btw the regexp is:
((?<catalogName>[[\w.]+]|\w+(?=.)).)?(?<schemaName>[[\w.]+]|\w+).(?<procName>[[\w.]+])
and what goes wrong is that the schema name is matched by the catalogname group, the procname till the # is matched with the schema name. Now, adding the '#' character to the match groups is not that hard, though it's of course just a matter of time till someone comes with the request that other characters have to be added as well. I'll see if I can find a list of allowed characters in procnames.
Ok, the list is: @, #, $ and _. That, with normal characters and numbers, the rest is not allowed.
