Solved: Re: Cisco Unity Connection CSP_SubscriberCreate

paulw.wilkinson · ‎12-15-2008

Hi,

Has anyone tried programming against Cisco Unity Connection 7 using the Informix client libraries?

I am trying to call Csp_SubscriberCreate but I get back an error -937 from the Informix client libraries. This seems to be related to the subscribercreate stored procedure returning two parameters as I can successfully call csp_subscribermodify and csp_subscriberdelete. I am sure that the data that I am sending to the procedure is correct because I have tested with CUDLI - It seems to be an issue with the Informix client libraries and the multiple return from this stored procedure.

Has anyone else tried this? Does anyone have any suggestions?

Thanks,

Paul

lindborg · ‎12-16-2008

So can you give a little more detail on what you're doing? Are you working in .NET? ADO? How are you setting up the call? Are you using the Informix .NET wrappers or are you using the ODBC drivers "straight" (i.e. installed off my site)?

I've had a number of sites use this and I use it myself without any issue - all the create procs should return a data reader (in the case of ADO.NET) or a recordset (in the case of ADODB) - the number of items (columns) shouldn't matter. The first return item should be the ObjectID of the newly created object.

If you're using the .NET wrappers from IBM's download site directly, I'd suggest not doing that - I use the straight ODBC method and it works fine (I have apps in both .NET and ADODB). For .NET I'm using simple command text construction and using the "ExecuteReader" method off a command object and assigning the output to a reader for review (if the reader is nothing then the proc failed).

Nothing too unusual - really the only trick to the Informix stuff is their lvarchar param needs special handling but other than that it's pretty straight forward.

If you let me know what you're doing, perhaps a small code chunk I can try and see what's going on.

View solution in original post

lindborg · ‎12-16-2008

So can you give a little more detail on what you're doing? Are you working in .NET? ADO? How are you setting up the call? Are you using the Informix .NET wrappers or are you using the ODBC drivers "straight" (i.e. installed off my site)?

I've had a number of sites use this and I use it myself without any issue - all the create procs should return a data reader (in the case of ADO.NET) or a recordset (in the case of ADODB) - the number of items (columns) shouldn't matter. The first return item should be the ObjectID of the newly created object.

If you're using the .NET wrappers from IBM's download site directly, I'd suggest not doing that - I use the straight ODBC method and it works fine (I have apps in both .NET and ADODB). For .NET I'm using simple command text construction and using the "ExecuteReader" method off a command object and assigning the output to a reader for review (if the reader is nothing then the proc failed).

Nothing too unusual - really the only trick to the Informix stuff is their lvarchar param needs special handling but other than that it's pretty straight forward.

If you let me know what you're doing, perhaps a small code chunk I can try and see what's going on.

lindborg · ‎12-16-2008

For grins I've attached some stripped down DB routines from my .NET 2.0 (I work in VS 2008 but these work in 2005 as well - I'm not doing any fancy class mods in the 3.0 framework).

There are 3 primary functions used for creating the stored procs calls and calling the procs with and without expecting a return to come back. For all creates I expect an ObjectID to come back for all mods I don't. I just noticed in the AddCommandParam" routine that I had to man-handle the time/date format stuff to make Informix happy as well as the lvarchar tags - I had forgotten about that.

At the top there's a simple "create subcriber" routine that I just tried and it works fine - I do force the "single row" option when setting up the ExecuteReader call - this may be where you're getting burned. I can play with it a bit and see if I get the same error you do when I don't force that.

Anyway, if you're working in ADODB instead or going through Matt's CUALS web interface or whatever, let me know.

paulw.wilkinson · ‎12-16-2008

Hi,

Thanks for the example code. I am sure it will help.

I have been using the IBM .Net libraries and I suspect that this is where the problem lies. These libraries seem to have an issue with the multiple return values and also don't seem to support named parameters on CommandType.StoredProcedure (I tried this when a text command didn't work. I was able to use a simple text command with named parameters to delete/update users).

I will try again with simple ODBC and let you know how I get on.

Paul

paulw.wilkinson · ‎12-17-2008

Switching to ODBC did the trick!

I am not sure why the IBM .Net providers have a problem with this particular stored procedure, but the ODBC interface (which you would think is essentially calling the same underlying modules) works fine.

Paul

lindborg · ‎12-17-2008

good deal.

yeah, I had problems with their .NET providers as well - and when I looked at what they were installing, it's just the same ODBC binaries with a wrapper - they didn't provide anything native for .NET. I've had no problems with straight ODBC in both .NET and ADODB applications so we're sticking with it.