I want to re-iterate what Evgeny said ... you should never store your persistent objectscript class definition in source control without the storage definition block.  Doing so will cause the storage block to be regenerated from scratch each time source is loaded, and if there is existing data you may have a mismatch of where properties exist on disk and where where the source thinks they should live

@Alexandra Mirzac - welcome to the Community :)  I would suggest the following:

1) Make sure you have saved and compiled your class, and that it returned with no errors.  

2) Make sure when you are testing in Terminal you are connected to the correct Instance and the correct Namespace

3) Double-check spelling and case in your Terminal command compared to your compiled classname

Please try those things out and let us know if that moves you forward.

I don't have access to an active HS environment at the moment, but from testing the last part of your query, it looks correct to me.  You are saying with the query that has the literal timestamp you get results, but with the 2nd query which targets the prior 2 hours you are getting no results?  are you sure that there are records in that time window to fetch?  What happens if you change it to a 24 hour window (-24)?

Can you explain what you mean by this? "it only leaves me specifying the exact time"   It makes it sound like you are using a UI of some sort?  Assuming that is the case, you should be able to access the records directly from the underlying table using SQL.  If you tell us specifically what table you're trying to look at we may be able to be more specific in a recommendation.

These classes are still in your 2018.1 instance (if they were not you would not be able to log into the System Management Portal), however, the Security.* package only exists in the %SYS Namespace (as it is not a % package it isn't projected to other namespaces).  See:  https://docs.intersystems.com/ens201817/csp/documatic/%25CSP.Documatic.c...

It may have been that you used package mappings to make the Security.* classes available in your application namespace, or that they were mapped by the product (I don't remember - 2014 is 10 years old at this point ;) ).  However, best practice today is to change to temporarily change to the %SYS Namespace in your code if you ever need to call the Security.* package.  There are privileged calls in there which you typically don't want directly accessible within your application namespace.