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?



If you do not care about fractions of seconds, convert the $H values to count of seconds .. $zdt(datetime,-2) .. and then compare the integers:

set date1 = $zdth("2016-01-02 00:15",3)

set date2 = $zdth("2016-01-02 01:00",3)

zw date1,date2

w $zdt(date1,-2)>$zdt(date2,-2)

If you do care about the seconds fractions you can use the follows operator with some of the external formats:

s d1=$zts h .001 s d2=$zts

zw d1,d2

w $zdt(d1,3,1,6)]$zdt(d2,3,1,6)


w $zdt(d2,3,1,6)]$zdt(d1,3,1,6)


/// note: comparing the count of seconds would consider the d1 and d2 equal.

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.

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