Hi Evgeny,

IF you can afford a short OFFLINE state:

#5)  dismount DB / copy of cache.dat to a fast local device / remount it
      move the copy in a secure place: #2, #1

ELSE IF you have to remain online all the time:
#3)  on fast local device + move backup in secure place by #2,#1
 

NEVER #4) a fair chance for massive inconsitency

Robert
[semper fidelis]

Great explanation of the issue. Thanks!
So we have an nice example what Proleptic Gregorian Calendar used for $H calculation means:

 

write $zd($zdh("1492-10-12",3,,,,,-600000)#7,11)
Wed

 

And that's definitely not correct as you demonstrated very precisely.
But is common use in most programming and DB systems. 

But the date as such is questionable for 2 reasons

  • There is a 5..6 hours time gap between Spain and the Caribean sea 
  • At the and of the middle age every kingdom and smaller typically dated their documents
    by the years their actual king was in power. A common date as we know was not at all in place.

So Oct.12 is most likely a date back calculated by historians hundred years later . 
So we should interpret this date as an common agreed convention that by luck was Friday.

Thanks again for the contribution.

 

It's possible but counter productive
since: if you switch off journal this get's logged in Audit and generates at least 1 entry in journal
and swicthing it back on for the rest of your application you get another entry.

I just don't recommend things with negative impact on performance. 

Anyhow IF you insist it's your fate:

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

You may do it as well with SQL

select count(*) cnt , ID from (
  select 'PERS' Typ, ID from %Dictionary.ClassDefinition
  where Super [ 'Persistent'
    union all
  select 'XML' Typ, ID from %Dictionary.ClassDefinition
  where Super [ 'XML.Adaptor'
)
group by ID
order by cnt desc

Result : 2  both classes contained  in class

cntID
2%BI.Blog
2%BI.BlogPost
2%BI.DashBoard
2%BI.DetailList
2%BI.DocMag
2%BI.ImageList
2%BI.KPI
2%BI.ListField
2%BI.Measure
2%BI.PerfMet
2%BI.PerfMetNode
2%BI.PivotData
2%BI.PivotTable

Athanassios,

I googled some time around Python console:
It  is single threaded.  
But your expectations seem to be that the behavour is like a terminal.

To achieve this your have to run 2 Phyton consoles / shells as you required 2 Terminals.
a) 1 passive to receive messages from WRITE  see attaches example starting before b)
b) 1 active to trigger action in Caché

Your initial code from your questions using the Caché Phyton binding covers b) OK!

for a) you may use a listener similar to this Phyton example with the correct port, buffer,...  ToDo

   1 #!/usr/bin/env python
   2 
   3 import socket
   4 
   5 
   6 TCP_IP = '127.0.0.1'
   7 TCP_PORT = 5005
   8 BUFFER_SIZE = 20  # Normally 1024, but we want fast response
   9 
  10 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  11 s.bind((TCP_IP, TCP_PORT))
  12 s.listen(1)
  13 
  14 conn, addr = s.accept()
  15 print 'Connection address:', addr
  16 while 1:
  17     data = conn.recv(BUFFER_SIZE)
  18     if not data: break
  19     print "received data:", data
  20     conn.send(data)  # echo
  21 conn.close()

Dashboards are always fresh calculated.

Compare the performance in .NET  to  IE.  It should be rather close to each other being based on similar technology.

If there is a significant difference then you dig at  .NET end (buffers, ...)

If Chrome is significant faster then IE it's most likely the faster JS engine in Chrome.

Next you could look into global buffers of Caché and concurrent use of the Caché instance.
And (rarely) the complexity of your dashboard
 

Hi  Athanassios,

you can not run the sender code in the same terminal as the receiver code
you have to use 2 terminals:

Terminal #1) start receiver. This simulates your Phyton Console

set tcp="|TCP|4200"
open tcp:(:4200):1 write $s($t:"OK",1:"failed"),!
for line=1:1 use tcp read text use 0 write line,?5,text,!

now you wait for something to be sent:

#Terminal #2): run sender

    set person = ##class(Samples.Person).%OpenId(1)
    w person.Name
    do person.PrintPersonTCP()

 

for this test it's essential that the sender finds a receiver waiting for input. Probably the same issue with PhytonConsole?

It's like real life: If nobody listens, your words are lost. laugh  And it has to happen at the same time.

The ouput goes to port 4200. That works with Caché.  (see test code)

Attention:  The ! at the end of the WRITE is important as it triggers the send.
in SAMPLES it is at the beginning:  So you just get an empty line. and rest remains in buffer.
You may also add  WRITE !! before the CLOSE to flush the buffer and send an empty line for termination .

I have no knowledge on Python or PythonConsole but from your code I see no indication
where it starts listening at port 4200. pls. check.

Test code from Caché Terminal:

USER>set tcp="|TCP|4200"
USER>open tcp:(:4200):1 write $s($t:"OK",1:"failed"),!
OK
USER>for line=1:1 use tcp read text use 0 write line,?5,text,!
1    Name: Uhles,Rob O.

<READ>

 

[ <READ>  is the reaction to the connection CLOSE of the sender as I don't check termination ]

Sorry, I saw just that one Print method fromSAMPLES.
The redirect is especially required to convert a Write Command to a Write() Method and vice versa.
For "classic" devices as files , TCP, UDP, all kind of pipes ,SPOOL,Console, Teerminal,...all you find in Caché I/O Device Guide I just see no added value  except fiddling around $P which I never had the need to do over 40yrs