Currently the data in subscripts does not need any translation. Once you enable your database to UNICODE, the data in subscripts pop up as UNICODE data.

There is a few questions to answer first:

- what is the 8-bit language encoding you use (does your 8-bit encoding of the "important" characters differer form the first 256 positions of the UNICODE?)

- are the affected characters used only in the data, or are they also hardcoded within routines/methods/class definitions/...?

- are there $listbuild structures used (if you use persistent classes then the answer is "yes")? 

- is it sure that the $lb structures were not used in subscripts (oh, it is silly idea isn't  it :-)?

- are binary data strictly separated form the textual ones (I mean not only pictures etc. but  various hashes, signatures etc.)?

- is it a production system?

- how big is the database, what is the time window to provide the conversion, how fast is your hardware?

- + bunch of minor or subsequent questions...

The answers and their combination affect heavily the conversion procedure. For example, if your answer to the first question is "no problem, the character codes do not differ", then no conversion is needed at all. 

If, on the other side, you face a transfer of xTB of data on a huge production system with hundreds of concurrent users with SLA > 4nines, consider some budget and hire a Maatrix expert (me). 

My last visit to Buchlov, a few years ago, was in the scope of a medieval philosophy conference, focused on the works of Jan Duns Scotus, doctor subtilis. I look forward comparing the atmosphere - then and now. 

Hi, could I join the Global Masters Lonely Hearts Club Band? Thx. Michal

Hello Bill,

is it now the right time to update our 2016.3 FT server to the 17.1 FT?

+ a question about the Document Model (and the object instance x json conversions) - is it completely out of plans out of the 2017.1 only?

Regards

Michal

As a consequence of the previous answers it is not allowed to address instance properties using the "dot dot" syntax within a class method. Using the previous example: it is ok to use 

set tCarNumber=..CarNumber 

within the PrintCar() method (providing there is a CarNumber property defined)

but you cannot use it in ClassMethod - as a class method can be called outside of any instance context.

https://fr.wikipedia.org/wiki/Accent_aigu

Hello Bill, yes, we can - no problem. Thank you. Michal

Hi Stefan,

the .$toJSON() system method, when used for registered object, inserted two more attributes to the resulted JSON string (on top of the propery:value pairs): the $CLASSNAME and the $REFERENCE. Is it still there in the "new approach". And if so, is it controllable? Could one switch it on an off somehow?

Thank you

Michal

Hi there, 

is it recommendable to downgrade the 2016.3 FT to the 16.2 FT, now? 

We do have two servers with 16.3 and we would like preserving all the settings (and databases as well, of course).

Thank you 

Michal

Maybe it is worth to mention that there is much simpler solution now in 2016 for the object-to-JSON conversion. It is a tiny part of the new powerful DocDM concept (http://localhost:57772/csp/docbook/DocBook.UI.Page.cls?KEY=GJSON_intro#G...).

try this:

set pObject=##class(%Object).%New()   ///this is one of the ways to create a DocDM object 

pObject.error="my-error-1"

set pObject.description="Error number one"

set  string=pObject.$toJSON()  ///here you call a system method "toJSON()" via dot dollar syntax

write string

........

However, the output capturing can be useful in other situations (or with the older versions of Cache).