If you have multiple cursors anywhere in the class with the same name, that will come up. If it says C10, then you must have two different places where you're doing a "DECLARE C10 CURSOR FOR . . ." and you'll have to rename one of those cursors.

You can probably make that work, but why not put the method in a %CSP.REST class to start with and have the CSP page call it? That seems more in line with the way those things are meant to be used.

I think what you're looking for might be setting the isolation level to read committed. This will make the process wait for the in-progress changes have been committed, though you'll still want to make sure you handle SQLCODE -114 somehow, too. That's the code you get back if there's a timeout waiting for the lock. You should be able to set that using:


If you do that before your query, the rest of the process will run at that isolation level.

You can use that same method to set the LockTimeout too, by the way. Default is 10 seconds.

The error seems to occur when it's trying to access the log file. Under you advanced settings, have you checked where it's trying to find or create your log file and made sure it's valid?

It sounds to me like there's an issue with the design there. If the field can be duplicated, why is it marked as unique at all?

Rochdi, I'd get rid of:

Set Line = File.Read(1000)
While (File.Read(1000)'="") { S mystring=mystring_File.Read(1000)

And then after your set Httprequest = ##class(%Net.HttpRequest).%New(), use:

set sc = Httprequest.EntityBody.CopyFromAndSave(File)

Then you can check sc to see if you got any errors doing that.

Your tResult will have a property called %SQLCODE that gets set when the query is run. If %SQLCODE = 100, that means that the query ran successfully but returned no results or that you've reached the end of the result set. If %SQLCODE = 0, you have some results. If %SQLCODE is less than zero, that's an error code.

if tResult.%SQLCODE = 100{

//whatever you want to do for no results here


If you're encoding your data before sending it, you have to specify how it was encoded in a content encoding header so that the server you're sending data to knows how to decode it.

I think it's more likely, though, that it's an issue with your content type. Where you're setting it to "text/plain", if it's supposed to be json, you might try setting it to "application/json" instead.