AllAccepted answers
Robert Cemper · Feb 2, 2018

It would be easier to help you with the concrete call  to ZAUTHENTICATE in hands.

In addition ZAUTHENTICATE.mac needs to be modeled by un-commenting  lines.

Or do you use the pre-configured OAUTH2.AUTHENTICATE.mac

in both cases you need to have activated this line:

Set Properties("Comment")="....whatever you may pass along...."

according to your description this is done .

So the issue might result from the way the call is done
Comment in ZAUTHENICATE.mac Line 90 says:

Properties - Array of returned values, passed by reference

So your call should look like

 Do ^ZAUTHENTICATE(ServiceName,Namespace,Username,Password,Credentials,.Properties)
#;--------------------------------------------------------------------^^^


 It's the dot in front of variable name Properties that does the Pass by Reference and enables you to use the updated array after the call.

The dirty approach would be to name your array %myProp instead of Properties thus using a variable with public scope.

Robert Cemper · Feb 2, 2018

Pls. be more specific on "It is not working."
+ what would you expect to work
eventually you have code and data separated, then it's more than just a single DB
various mapping may add even more DBs

You should get previous releases from WRC based on your service contract.
But be aware: from 2007 to 2017 there have been  15..20 releases.   
Each with changes + release notes that may affect you.  

Robert Cemper · Feb 2, 2018

Hi Ben,

I just installed a few samples as in description . CONGRATULATIONS !
- not only that I get what I want and leave the rest aside
- I also can split samples by subjects in several DBs and namespaces without being trapped by (hidden) dependencies.

I think this makes live for training and teaching significantly easier!
And allows central bug fixing independent from core release dates.


A great idea! Thanks!

Robert Cemper · Feb 2, 2018

To my understanding the main purpose of introducing %INLIST in our SQL was
to have a more handy option than the classic IN (....)

%INLIST takes a Single $LISTBUILD()  as parameter with a Variable number of values that you pass at runtime by only 1 "?"

while IN (p1,p2,p3,p4)   or better IN (?,?,?,?)  requires a fixed static number of parameters during execution. 
so you have to know the maximum number of values ahead when you create your query
and eventually to fill unused parameters by some impossible value to feed the query

 

Robert Cemper · Feb 1, 2018

Query 1 Example 1 could be marginally faster by less line terminations and less command dispatch:
But as this will be compiled some kind of code optimizer eventually might run.

Query2 Example1 is faster by less line terminations and less command dispatch.

BUT:  Both cases aren't the place to win benchmarks. Rather look for Global access , SQL optimizing, ....

Robert Cemper · Feb 1, 2018

Hi Ben,
- I like the idea of external samples. That offers definitely more flexibility .
- DOCUMATIC is unchanged and works local!  That's important. OK 
- JDBC: it isn't visible in Custom Install.  You only see xDBC -> ODBC .   
   Not an issue, rather a surprise. The .jar are  where they used to be before.

I'm really happy that we finally can get out of old chains imposed by 40yrs (DSM-11 and others) backward compatibility .

Robert  

Robert Cemper · Jan 31, 2018

rewrite of comment:

if this is something like

SELECT people.name, holiday.date, people.ID||'^'||holiday.ID as UNIQ
FROM people JOIN holiday
ON people.country = holiday.country

Then the bolded expression should not be longer than your 50 Char.

IF you use CachéStorage
ID is always a unique positive Integer (1.... 19digits)  and you can always disassemble it by the separator.