Correct, bandwidth is not so much of an issue. Latency can be an issue as a high latency will make all actions that require server interaction be perceived slowly.

Also, you should be aware that Studio runs a server status check on a regular basis by default. If your latency or connection is bad you should increase the timeouts, otherwise, you will see a popup asking for a reconnection pretty often. The setting can be found here: Tools->Options, go to Environment->Advanced and take a look at the "Enable server status check" setting.

Again, it depends on what you are comparing to. Just looping over a global can be compared to a simple full table scan and the runtime performance should be pretty much the same.

If you have a complex query that can't be boosted by adding just another index or by running tune table, you can probably write your own custom logic. An even better solution is to implement a custom index that can be leveraged by SQL.

You have to keep in mind that the %SQL.CustomResultSet approach does not lead to reusable code. It can be used to solve a very specific problem, but it can't be reused for a similar problem on a different data set.

Well, that obviously depends on how good your owl logic is. wink  I only recommend this approach if the standard interface is insufficient for a specific need and you have to optimize further. 

Writing your own logic does not leverage optimizations from newer versions and you have to maintain it.

A major benefit of %SQL.CustomResultSet is that you can query any accessible data source, e.g. globals and files.

Hi Benjamin,

regarding your questions:

1) String concatenation is possible with the underscore "_" character. For example:

set myquery = "SELECT * FROM " _ tableName

Don't use the plus "+" character as this is the addition operator. It will evaluate your string and convert it into a number. Unless your string starts with a number, it will be evaluated to 0. 

2) Multiline statements are not supported in Caché Object Script, so you have to concatenate your string if you want to spread the query on multiple lines.



I have played with Visual Studio Code, but at its core, it is nothing more than a smart text editor like TextMate2 with some extensions for running tasks. It includes the runtime and can, therefore, add a debugger, which is nice. But it is not a full blown IDE.

VS Code has a user group, but it is not build to allow more complex workflow integration, which is something Atelier wants to offer at some point.

I am sure Bill can provide more insight. 

Thanks Eduard for posting the working solution. The reason why this works is that you actually create an object of your registered class and assign the values. The jsonProvider API can now walk the object and project the types properly.

In the non-working example, you created a zenProxyObject and assigned the values on your own. The zenProxyObject just deals with auto-types and guesses the best possible type fit. As you see, this guess can't be correct all the time as in this case.

If you want to create a JSON structure with specific types, either use a) the new JSON support in 2016.1 (recommended if 2016.1 is available) or b) create a subclass from %RegisteredObject and use the jsonProvider API.