This is the third article (see Part 1 and Part 2) where I continue to introduce you to the internal structure of Caché databases. This time, I will tell you a few interesting things and explain how my Caché Blocks Explorer project can help make your work more productive.
I work for a large NHS Trust in the UK and we are using Healthshare and we process 1000s of messages each day. Many of these are standard HL7 messages however for several months now we also pickup and drop off 10
The following post outlines an architectural design of intermediate complexity for DeepSee. As in the previous example, this implementation includes separate databases for storing the DeepSee cache, DeepSee implementation and settings. This post introduces two new databases: the first to store the globals needed for synchronization, the second to store fact tables and indices.
This tool is used to generate random read Input/Output (IO) from within the Caché database. The goal of this tool is to drive as many jobs as possible to achieve target IOPS and ensure acceptable disk response times are sustained. Results gathered from the IO tests will vary from configuration to configuration based on the IO sub-system. Before running these tests ensure corresponding operating system and storage level monitoring are configured to capture IO performance metrics for later analysis.
I have a lookup table and record batch Table I would like to do a count on the records stored in that batch by counting the number of records in that batch that have a certain key on the responseKey column.
Is there a way to pull a user name and password from the Credentials list that is kept in Ensemble? Right now I have a LDAP user that I have hard coded into my ZAUTHENTICATE, which I would like to get away from.
Some of our interfaces use globals for lookups, but we are currently looking at putting a groups of (document) interfaces in a separate production with a shared ‘Default Database for Routines’ to reduce code duplication.