Kevin,

it seems that the main point here is to stop Studio before deleting the content; not necessary to stop Caché.

BTW, there should be several subfolders inside, one for each server/namespace connection you've ever established.

Taking in account that real commercial systems should never delete anything, the lightweight solution can't be recommended for use in such kind of systems. I'm just curious: when it can be helpful?

Hi Robert,

But real commercial systems never delete anything. Just set a flag "isDeleted"

Let us discuss a case when an employee has left a company and joined a new one.
Where would you place this flag in The lightweight solution?

...Example1 is faster by less line terminations

AFAIK, line terminators are no longer stored in OBJ code since version 2010.1, so splitting a long code line into smaller ones can't affect performance at all.

-

I mentioned DAQ just because it was mentioned earlier and it was really buggy till 2017.x. I was apparently wrong as you seem to have all mnemonics embedded.

As to JOBEXAM.INT, isn't it better to ask somebody inside ISC? IMHO, too many "innocent" utilities are shipped w/o sources.

Hi, Nikita,
I'm a new WebTerminal user, just installed v.4.7.3.

JOBEXAM has problems with it, and it seems that it's %X364 support again. Here is an excerpt from my session: 

CWTv4.7.3 ...

...

USER > zn "%SYS"

%SYS > d ^JOBEXAM

<NOLINE>^%X364

╠%X364 ; BINDING FOR ANSI X3.64 NAMESPACE, NOV/92 ; LRS952 06/07/05

%SYS > w $zv

Cache for Windows (x86-64) 2017.2 (Build 744U) Fri Sep 29 2017 10:58:27 EDT

I've checked %X364 source, it has got correct DAQ() code with this Caché version.

Waiting for your help and advice.

This option: 

$ZD($h,12,,,,,,,,localeopt)

seems to be more safe as switching the default representation for $ZD($h,12) may ruin already existing functionality that is expecting English days' names.

To be honest, I'd prefer application level localization, just because not all possible languages are supported by Caché.

Hi John and Roman,

Although the answer is accepted, it seems that JOBEXAM can only help recognize that DBREST is still running, so the initial question about the completion time expectations would hardly be answered this way.

Roman, only your previous experience can help answering your question. BTW, "weakness" of your host as you described it can't be a reason of slow DB restoration as DBREST is single-threaded utility and mostly i/o bound one. The reasons for slowing DBREST down are usually: slow disk subsystem and/or slow LAN connection to network resource where .cbk files are stored.

Entry level SAS RAID and 1000BaseT LAN usually provide 40-50MB/s speed on DB restoration.

...and spread over documentation

...Or undocumented, as it is in cases #3 and #4. 

It seems that it's possible to form a simple rule whether you can use a private variable: if you can consider its name to be evaluated at compile time, you can, otherwise - no:

1) Indirection: variable names (or expression that contains them) are evaluated at runtime.

2) Xecute: similar to #1. In contrast, $xecute() arguments names can be evaluated at compile time.

3) Child process's symbol table filled with switch#2=1: runtime.  In contrast, job's entry arguments names can be evaluated at compile time.

4) %SYS.ProcessQuery is dynamically querying other process's symbol table, so, run time only.

It depends.

If you don't care about uniqueness of this hash, you can use any algorithm (the quicker the better, MD5Hash or even CRC32) and store your index like normal non-unique one. On calculated hash match to already stored (indexed) hash value you just compare the correspondent strings to separate real matches from the collisions. Maybe it's worth to use whole string as an index for reasonably short strings.

You can calculate a hash for each string and index this hash value. If use pure COS for index building, you can find duplicates earlier, just during index building, without quiering the index afterwards.