This Field Test does not include HealthShare Health Connect.

Thanks in advance for your patience...

No it does not.

I see the Release Notes posted are from 2017.2.  We'll get that updated.  

The documentation as installed does include 2018.1 release notes, though admittedly a bit skimpy at the moment. 

The changes to the underlying data platform version 2017.2.2 are described in these release notes as noted in this Maintenance Release announcement earlier this month.

Unlike most maintenance releases we've not created separate release notes for this release.  Relevant information has been added directly to the main documents.

Caché and Ensemble 2018.1 Field Test is coming soon this summer.

Hi John,

I've updated the original announcement to reflect our current status, which is to release in October.

Here are some details from the developer:

Customers need to know which SQL queries play a significant role in their application performance. To help in this determination we now keep statistics against all SQL in the SQL statement index. The information we record is:

1) Number of times a query is run

2) Total time spent in query

3) Standard deviation of the query

4) Date we first recorded seeing a query run

Although this information is deliberately sparse to keep the overhead of recording it as small as possible (both in time taken and space used) it should allow the following sorts of questions to be asked:

1) Which query is run more often than any other?

2) Show me the slowest 5 queries?

3) Which queries take more total time than any others?

4) A developer has a way to optimize query X, is the overhead of this query actually significant on my live system?

All this data is stored in the SQL statement index and viewable in the system management portal under the statement index pages as additional columns. Users can sort by these columns as needed. The data will be recorded by all SQL including cached queries via xDBC, or server side cached queries e.g. %SQL.Statement or embedded SQL. We default to always recording this information on any query except for a 'natural' query which is one we can determine at compile time is so simple that the overhead of recording statistics will effect performance and there is no advantage to keeping statistics as the query is already very simple. A good example of a natural query is 'select Name from Table where %ID=?' as this query does not involve any looping and any index references. We will mark these queries as natural in the SQL statement index. The exact definition of what is a natural query may be extended in the future. By default we will now collection statistics on all non-natural queries. To minimize the overhead of this collection the data is stored in the partition and only written to a global either when the process terminates or after a set period of time. This writing of the data to a global does not directly update the statistics in the SQL statement index, but a background process periodically wakes up which aggregates the data from any processes into the global statistics. This means the data in the SQL statement index does not include the most recent activity, but by deferring this update we avoid blocking the process doing useful SQL work.

The statistics are SQL mapped from the INFORMATION.SCHEMA.STATEMENTS class so you can perform SQL queries against this to view the statistics as well as viewing them in the SMP.

Planning to post a new Field Test for 2016.2 today.  Final Release Date will be based on how that goes, but not too far out since we've been in Field Test for a while.

People from 50 different customer organizations are now experimenting with 2016.2.  Downloads are running 68% Caché and 32% Ensemble.  Six WRC problems have been opened, only one of which has (so far) identified a DEFECT (fixed by JN1628).