YES ! but not it's addressed explicitly

  • the trivial one by self-restricting 1:many  to a single link
  • inheriting of classes is a 1:1 parent-child- relationship  (sample.person<-sample.employee)
  • the normal property -> object reference (sample.employee->sample.company)

I just verified:

  • Download an Ubuntu Docker image
  • Install a Caché Ububtu distribution
  • tar + gzip the image and you are part of the game with 550 MB only 

@Mike Minor 
I just installed a full instance on WIN10. boooooring slow!!
If you don't disable AutoStart @ Boot in the config Win reacts rather confused.
Especially if your drive has changed by dynamics from F : -> D: or similar.
In addition, a lot of info is saved in  Win-Registry. angry

Overall performance is not a thrill but acceptable

Next trouble: Dismount of the flash drive. Painful

My strong recommendation: Use a Docker container instead.  Example here CrossECP-Cache
Then you are really mobile and fast

I miss a button  "Excellent Answer"    in the community

Big Thanks!

So you have to examine this special record in detail in the underlying Global.
Seems to be a broken record that you hit by accident.

OK. this looks like the first record you find is already in trouble.
I'd expect your data type is something else then stored.
Next omit the conversion %ODBCOUT()  just to see what internal content is and where it starts

  select ID,%INTERNAL(VerzamelDatTijd),
        DateTijdSec from GLPPatTcActie
         where pnr = '27085070017'
         and LTestId->Makey='BLA'
         and glpactieid->makey in ('TAV','TMA')
 

The next question is of course which program writes these values? and how? what's the source?

I get more and more the impression that some 'aged' program writes directly into the global.
Probably directly some $HOROLOG which is a combined %DATE,%TIME construct.

 

OK!
Now I see the problem. Each datatype has its specific conversion from internal format to ODBC format
So if VerzamelDatTijd is %Date or %Time or %Timestamp and the stored content doesn't fit
you get most likely this error.
It could be by principle := it fits never, a design issue
It could be just a glitch in some data record.
I suggest you start the SQL shell from terminal prompt.  USER>do $system.SQL.Shell()
And then run your modified query:

select  ID,%INTERNAL(VerzamelDatTijd),%ODBCout(VerzamelDatTijd),DateTijdSec
from  GLPPatTcActie 
 where pnr = '27085070017' and LTestId->Makey='BLA'
-- and VerzamelDatTijd < '2021-03-04 09:04'
and glpactieid->makey in ('TAV','TMA')
--
order by DateTijdSec desc

ID shows the flaky record
%INTERNAL() shows the raw content
%ODBCOUT() should trigger the error

Once you know the content you should be able to fix it.




 

what date time format would you expect this to be ???? 

'2021-03-04-2021 09:04'  

YYYY-MM-DD-YYYY HH:mm

Not really standard! Rather a wrong DateTime in your Query !

using SQL you can compare the last change between definition and compilation of classes
a negative difference shows where recompilation is required.
I used Posix-Timeformat for an easier compare

SELECT 
def.ID, cmp.TimeChanged compiled,  def.TimeChanged defined, 
to_char($piece(cmp.TimeChanged,',',1),'J')-to_char($piece(def.TimeChanged,',',1),'J') diff
FROM %Dictionary.ClassDefinition def
left outer join %Dictionary.CompiledClass cmp
on def.ID=cmp.ID
where NOT def.name %startswith '%'
order by 4

Just any Select.   e.g. 
          SELECT 17+4 as BlackJack, NOW() as TimeToWin
no table required
or
          SELECT Top 5 *  FROM %TSQL_sys.types