Hi Denny,

I think the most common cause of a refused connection is OS firewall blocking the superserver port of IRIS, which is used by JDBC connections. You can try close the firewall or open the superserver port in firewall settings.

I remember that SqlDBx is using ODBC to connect to DBs, so it will use a different connection.

Hi Kevin,

I think it is better if we refine the requirement for some details so that we can refer to a set of configurations to achieve what you want.

1. The user can only visit specific DBs instead of all DBs.  Therefore, we will use specific resource to protect specific DB.

2. The user can use SQL from third party tools to visit the DBs through ODBC and JDBC connections, therefore, he need not only DB access but also specific SQL privileges. 

Reference：https://docs.intersystems.com/irisforhealthlatest/csp/docbook/Doc.View.c...

We can make the user a READONLY one by assigning only Select SQL privilege to him.
We can also use portal to define the privileges:

3. If the user can only use SQL and should not use portal to visit IRIS, the simplest way is not to assign roles such as %Operator, %Manager to the user, he then can only visit portal but can not use menus to perform action and we will Never refer to %All from a user expected to have limited previleges.

Hi, how about tick the application option?

Hi 

According to the document 

https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI...

The fourth parameter should be application name instead of dispatch class name

Hi, Dongsheng,

Setting on pool size could be a little tricky. 
Planning pool size before the implementation is good but it depends on whether we can predict the actual throughput of a business host and the performance of it.
As for my own experience, the more effective way to use pool size is to use it as a performance tuning approach.
Say, we deploy a business host online and perform test run for several rounds with actual or estimated loads. During the test, we'll need to observe the queue. For example, if a queue is increasing much faster than the others, it usually means the underlining business host is a performance bottleneck and we'll need to either optimize the business host or simply increase it's pool size as long as there are spare CPU cores to be used. 

Before a project goes live we usually try it out for a period of time, during which we gradually determine the pool size of each business host to achieve the required performance.

__________________________________________________________________________________

pool size的设置并不会对每一个应用都一样。
在实施之前规划好池大小是好的，但这要看我们是否能预测business host的吞吐量和它的性能。
就我自己的经验而言，将pool size作为一种性能调整的方法比较有用。
比如说，我们在线部署一个business host，在实际或预估负载的情况下，进行几轮测试运行。在测试过程中，我们需要观察队列的情况。例如，如果一个队列的增长速度比其他队列快得多，通常意味着对应的business host是一个性能瓶颈，我们需要对它进行优化，或者，只要有空余的CPU核心可以使用，增加它的pool size通常就会带来可观的性能提升。

在项目上线之前我们通常会试运行一段时间，期间逐步确定每一个business host的pool size以达到所需的性能。

Hi Scott, I'm not sure whether I captured your question exactly. Say, if you want two fields to be taken at the same time to compose a key field, it can be done by combine the two fields into one "virtual" field then use it as the key field. For example

SELECT HQ_ORG_CODE||'|'||ORDER_PROJ_CODE||'|'||FORM_DATE As OID,* FROM tableX WHERE FORM_DATE >= ?

In this SQL, we concatenated the three fields with the splitter "|" into one "virtual" filed OID, then we can directly use OID as the key field because it will exist in the result set. Also, we can use SQL function to concatenate the fields, as below

SELECT STRING(HQ_ORG_CODE,ORDER_PROJ_CODE,FORM_DATE) As OID,* FROM tableX

Hope that helps

Hi Botai, 如大家已指出的，Https是实现服务器与客户端通过http访问时通信安全的推荐实现。

当我们采用自己编程实现的客户端加密 - 服务器端解密解决方案时，需要注意和控制以下的若干问题：

1. Base64是一个编码手段而不是加密手段，其编码的结果可以被反向解码。 如果客户需要的是通信被加密，那么需要应用的是DES、RSA等加密算法避免引入信息安全缺陷。

2. 如果采用修改登录页的方式来处理数据的加密和解密，需要对开发结果进行全面的测试，包括非功能测试，避免因开发和部署新的代码引入缺陷

3. 应用Https将对服务器与客户端的所有http请求进行加密，只改登录页的处理逻辑将只能处理登录请求，其他的客户敏感信息，例如REST、SOAP等请求的明文也仍然暴露在网络上，因此并不是个能解决安全性问题的手段