Did you mean to write name and Name respectively for the two queries or is that a typo? If it's not, try the first statement and write name with a capital N. Caps/no caps is very important for XML and it wouldn't be the first time that this has caused problems (where the documentation and what callmanager does do not correspond to each other).
If that's not it then it's likely a bug.. you can confirm that by looking at the WSDL for the call in question, then trace the execution of the two statements and compare the SOAP messages with their definition in the WSDL (yeah I know.. what's the point of WSDL if you have to do that but keep in mind that Cisco is manually writing WSDL files so there's no guarantee the webservices work the way they are supposed to and the way they do if you have your dev environment autogenerate the WSDL based on your code)
From the above you get a pretty good idea where I suspect the problem lies: the WSDL doesn't match what callmanager 5 really does
The problem here is not related to case sensitiveness. I tried with both ?Name? and ?name? typo but I got the same behaviour. Remember that SQL language is not case sensitive. To give a clear description of the problem lets examine this peace of AXIS/Java code:
The first call fails while the second succeeds. The only difference between the two calls is the value of the SQL statement and the number of requested columns. And both calls succeed when connecting to 4.2 Call Manager.
I am not sure that the problem is related to the soap encoding neither to the WSDL file and server implementation matching. Otherwise how do you explain that two calls to the same method (like explained above) with different parameter values do no have the same success behaviour?
In case my guessing is wrong, I have provided in the attachments the soap requests corresponding to both calls (unsuccessful one with its response and successful one) in order to help the investigation of the issue.
I made some additional tests and found out that when I modify the SQL query that causes the problem as follows:
"select Enum, Name, tkClass, Moniker, tkRisClass from TypeModel order by Enum",
the query works and I got a successful result.
The difference between the two queries is the columns that have been selected.
It seems like requesting some particular columns; I suppose those containing NULL values; make the query fail at the server side. And this problem seems to be specific to CCM 5.0; there is no problem with CCM 4.2.
Can anybody confirm this analysis? Is it a bug?
What is the correct way to use the executeCCMSQLStatement method? Is there any clear documentation or directives about the use of this method? How errors should be handled in this case?
I haven't had time to read through your responses yet but I can't help the urge to correct something:
>Remember that SQL language is not case sensitive.
Is not correct. It depends on which DB server you're using AND on which platform you run it. For instance, run MySQL on Windows and it's not case sensitive.. run it on Linux and it is. And to make matters worse, when you use the query browser to connect to a remote windows server, it's not case sensitive and if you connect to a remote linux server (with the same windows client locally installed) it is case sensitive. And with CCM 5.0 we no longer have MS SQL Server plus the thing runs on Linux and Linux cares a lot about cases.
It is good to know that SQL may be case sensitive. It seems to be not case sensitive with CCM 5.0 at least through the soap interface. However I've tested again by respecting the case sensitiveness and I got the same behaviour. It seems like case sensitiveness is not the heart of the problem.
Please let me know me know when you manage to get time to have a look to my last 2 posts, what you think about my issue.
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...