Also very helpful if you want to look at the problem from a global centric view rather than a code centric view is ^GLOSTAT:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

The key bit of information here is the 'service unavailable' error being returned rather than say a 'not authorized' or 'not found' errors. By default when out of licenses we return the service unavailable error so if anyone else sees this they should check license usage as a first step. If you get not authorized errors it is probably a security issue so check the audit log as this often shows the exact problem.

It sounds like somewhere in your application you have a call that returns OID values to the client, then as a separate step you wish to return the stream associated with this OID. Is it possible instead of returning the OID to the client you just return the stream directly to the client? So what is the need for the client to store the OID when it is really the stream the client wants?

Assuming there is a good reason for returning the OID you can follow this pattern.

• Server gets request where it would previously return the OID
• Server generates a new random number using $system.Encryption.GenCryptRand to generate a random number
• Server stores this random number in a table against the OID it wishes to associate it with and a timetstamp
• Server sends the random number to the client
• Client at some point wishes to get the stream so it sends the random number to the server
• Server looks up the random number in the table and finds the OID and serves up this stream if the request is within some time period of the random number being generated. Then it deletes the random number from the table.

You also need to write some code to cleanup this table and remove expired random numbers from the table periodically or it could grow over time if you generate values and the client never uses them.

As you know these escape sequences are valid HTML escaping of unicode characters. The general principal is always that you store the text in the database  as characters i.e. not escaped at all and you apply any escaping needed when serving this content to a client. So it appears you need to convert these escaped characters into something you can store in your 8bit database.

Now in general I would suggest using unicode in which case you can just make sure the data being sent to you is correctly converted into unicode characters and then you just store the characters in the database. This would then work with any characters and not just the few you are having problems with. However it sounds like you do not want to move from 8bit to unicode. If that is the case anything you do will be something of a hack, but you can just use $replace on the data coming in to convert say "%u2019" to "'" before you store it in the database to 'normalize' the input. This solution will only cover a few characters where you can find a suitable replacement but it may be enough to get by for the short term while you investigate moving to unicode as a permanent solution.