公司需要统计数据，需要使用python连接数据库查询，请问一下如何使用python连接cache2016数据库

InterSystems 是一家已经深耕数据库平台领域达44年的公司，成立于1978年，现在已经在全球的80多个国家开展相关业务，每天有超过10亿患者的电子病历数据都跑在以我们的数据库平台构建的应用系统之上。

我们的客户遍布国内外，国内的大几百家三甲医院客户，中国复旦排行榜上超过1/3的顶级医院都在使用我们产品（包括北京协和医院，华西医院，湘雅等等），我们的技术合作伙伴，如东华医为，嘉和，和仁等也都是国内医疗信息领域的著名厂商。

   而在国外，我们也有非常多的顶级客户，仅仅以美国举例，美国最顶级的排名前20的所有医院，无一例外全部都是使用的interSystems公司的数据库平台产品。

 美国排名前20的所有顶级医院

2020-2021《美国新闻与世界报道》(U.S. News & World Report)最顶级医院名单（前20家医疗机构）均应用InterSystems公司的数据库平台：

Mayo Clinic, Rochester, Minnesota （明尼苏达州罗彻斯特市梅奥诊所）
Cleveland Clinic（克利夫兰诊所）
 Johns Hopkins Hospital, Baltimore（巴尔的摩约翰霍普金斯医院）
(tie).

HL7（Health Level 7）是一套技术规范，用于医院信息系统（HIS）之间临床、财务和管理数据的计算机互交换。这些规范被不同程度地被纳入美国（ANSI）和国际（ISO）正式标准的语料库中。

HL7的L7表示它是在OSI模型的第7层，换句话说，在应用层运行的标准。这意味着HL7不需要考虑交换的安全性，也不需要考虑信息传输的安全性（这一点由较低层次的层来保证，例如用于安全的SSL/TLS或用于数据传输的TCP）。更准确地说，第7层支持终端用户进程和应用的通信，以及面向用户的软件应用的数据展示。作为OSI模型的最高层，也是最接近最终用户的层，第7层提供特定的应用功能，如识别通信伙伴和它们之间的服务质量，确定资源可用性，考虑隐私和用户认证，以及同步通信，并将应用与OSI模型的较低层连接起来。

回到HL7标准，HL7第二版标准（也称为Pipehat）最初创建于1989年，但目前仍在使用并定期更新，形成了2.1、2.2、2.3、2.3.1、2.4、2.5、2.5.1、2.6、2.7、2.7.1、2.8、2.8.1、2.8.2和2.9版本。v2.x标准是向后兼容的（例如，基于2.3版本的信息将被支持2.6版本的应用程序所理解），在更高的版本中，你会看到一些字段是专门为它而留的。

        安装InterSystems IRIS数据库的ODBC驱动，在Windows系统中配置数据源后，可以使用Microsoft Visual Studio 开发工具 中的服务器资源管理器很方便地连接到InterSystems IRIS数据库服务器，利用数据库连接的可视化视图，可以非常方便快捷地进行连接到InterSystems IRIS数据库的应用开发。本文将展示一个利用以上方式实现的例子，开发工具为Microsoft Visual Studio 2019，开发语言为C#，10分钟快速开发实现一个连接到InterSystems IRIS数据库的C#应用，在本例子中，可以通过选择日期和科室，查询指定日期和科室的就诊日志。

1、在成功安装InterSystems IRIS数据库的ODBC驱动后，从Windows的“控制面板”中选择“管理工具”，在“管理工具”中选择“ODBC数据源”。

2、在ODBC数据源管理的“用户DSN”标签下，选择“添加”，在随后弹出的“创建新数据源”窗口中选择“InterSystems ODBC”，点击“完成”进入下一步。

3、在弹出的“InterSystems ODBC数据源设置”窗口中，为数据源命名，填写连接数据库的信息，访问用户名和密码，点击“测试连接”，成功后点击“OK”保存。

Caché 字符编码自动判断

先说几个场景：

1. 使用文件字符流打开一个文本文档，但是我不确定是以UTF8编码的还是GB18030,所以就无法准确设置TranslateTable，就导致了中文乱码问题。
2. 有一个文件下载的csp,其中文件名参数可能是中文，如果在一个UTF8编码的界面直接调用时，后台取到的文件名就会是乱码。
3. 接收到字节流后需要转成字符流读取内容，但是无法确定编码格式，就无法准确的转成字符。

以上几个场景虽然大多都可以提前做好约定解决，但是可能有历史原因或者种种情况，需要我们自己能够解决，于是就有了下面的故事。

基础

首先我方系统使用GB18030编码，然后碰到的情况大多都是对方可能是UTF8编码，所以主要来解决识别字节流是不是UTF8编码的。

0. 算法概述

SM4算法是一种分组密码算法。其分组长度为128bit，密钥长度也为128bit。加密算法与密钥扩展算法均采用32轮非线性迭代结构，以字（32位）为单位进行加密运算，每一次迭代运算均为一轮变换函数F。SM4算法加/解密算法的结构相同，只是使用轮密钥相反，其中解密轮密钥是加密轮密钥的逆序。

1. 密钥及轮密钥

密钥长度为128比特，表示为MK=(MK(0),MK(1),MK(2),MK(3)),其中MKi(i=0,1,2,3)为字。 轮密钥表示为(rk(0),rk(1),...,rk(31)),其中rk(i)(i=0,...,31)为32比特字。轮密钥由秘钥生成。

2. 消息填充分组

首先，将明文转化为字节，由于SM4加密算法按照128个位进行分组，所以很大几率会出现最后一个分组不够128位的情况，需要进行填充，填充方式有很多，比如ZeroPadding、PKCS7Padding、PKCS5Padding，不管使用哪种方式，最后每个分组都是128位。每个分组按照32位一个字分成四个字。

ECB模式与CBC模式

• ECB模式 电子密码本模式，最古老，最简单的模式，将加密的数据分成若干组，每组的大小跟加密密钥相同。不足的部分进行填充。 按照顺序将计算所得的数据连在一起即可，各段数据之间互不影响。

  优点：简单，有利于并行计算，误差不会

0. 算法概述

SM3密码杂凑算法是中国国家密码管理局2010年公布的中国商用密码杂凑算法标准。该算法于2012年发布为密码行业标准(GM/T 0004-2012)，2016年发布为国家密码杂凑算法标准(GB/T 32905-2016)。

SM3适用于商用密码应用中的数字签名和验证，是在[SHA-256]基础上改进实现的一种算法，其安全性和SHA-256相当。SM3和MD5的迭代过程类似，也采用Merkle-Damgard结构。消息分组长度为512位，摘要值长度为256位。

整个算法的执行过程可以概括成四个步骤：消息填充、消息扩展、迭代压缩、输出结果。

1. 消息填充

SM3的消息扩展步骤是以512位的数据分组作为输入的。因此，我们需要在一开始就把数据长度填充至512位的倍数。具体步骤如下：

1、先填充一个“1”，后面加上k个“0”。其中k是满足(n+1+k) mod 512 = 448的最小正整数。

2、追加64位的数据长度。

2. 消息分组扩展

将填充后的消息m′按512比特进行分组：m′ = B(0)B(1)...B(n−1) 其中n=(l+k+65)/512。

SM3的迭代压缩步骤没有直接使用数据分组进行运算，而是使用这个步骤产生的132个消息

在Cache数据库建表的时候，在定义字段长度的时候，长度设置为1000和长度设置为2000在存储一个长度为1000的值的时候占用的存储空间是否一致。是否在建表的时候建议把字段长度设置为MAXLEN=""

谁没有 Library.SQLCatalogPriv

日常工作中，我们使用xml 应该是比较多的，早期的ensemble或者cache，对JSON的支持不是很好，但是对xml支持比较好。因此早期的接口方式中，webservice+xml的方式很常用。而对象导出为xml最简单的方式就是类继承 %XML.Adaptor。继承该类后，就可以使用很多xml的特性，以满足各种需求。虽然看不到对象转为xml的具体实现，但是配置了参数，就可以实现更多的效果。那么想自定义一些参数呢？如果有人打开过它的定义，可以看到类上面有个 “ PropertyClass = %XML.PropertyParameters”，那么我们其实在需要xml参数的同时，又要自定义参数，就可以自己写个属性类，继承于%XML.PropertyParameters。

这里，我姑且定义一个类，用于说明使用场景。

Class TEST.PropertyParameters Extends %XML.

第二十五章 CSP Session 管理 - 选择策略时的注意事项

组的注意事项

本节包含创建身份验证组时要考虑的一些要点。

1. 仅当决定必须通过会话对象共享数据时才使用会话共享。 By-ID 和登录 Cookie 共享更加强大和可预测。
2. 创建组时，尽可能保持一致，以便为目标用户创建统一的行为。不要将应用程序同时放在 By-ID 组和 By-Session 组中。使用不同的身份验证策略可能会导致意外行为。 By-ID 优先于 By-Session。因此，如果一个应用程序两者都有，它会保持同步 By-ID。
3. 对组的所有成员使用相同的身份验证类型。特别是，如果组中的某些应用程序允许登录 Cookie 而其他应用程序不允许，则通过用户名/密码进入组会验证整个组，而通过登录 cookie 输入只会验证部分应用程序。这可能会导致用户对为什么有时需要登录而有时不需要登录感到困惑。
4. CSP 服务器认为每个应用程序都在一个身份验证组中。会话中的一个单独的应用程序形成一个单实体 By-Session 身份验证组。）
5. 尽量不要将未经身份验证的应用程序放在 By-ID 组中。
6. By-Session 组很脆弱；使用 By-ID 是一种更稳健的方法。由于有关组的所有信息（包括其共享数据）都包含在单个会话中，因此该组很容易丢失。这是因为会话可能会超时，即在特定时间后会话会自动销毁。

第二十四章 CSP Session 管理 - 认证架构

认证架构

安全上下文和粘性登录

应用程序在会话中运行。会话需要运行应用程序的安全上下文。安全上下文包含身份验证状态。

By-Sessions 和 By-ID Groups 有一个粘性登录，它会记住会话或组中使用的最后一个应用程序的安全上下文。如果组应用程序中的用户以其他用户身份登录，则会更新粘性登录。 （如果用户登录到未经身份验证的应用程序，则粘滞登录不会更新。）

在会话中跳转到应用程序时，会话会尝试使用适合目标应用程序的粘性登录。如果粘性登录与会话的当前安全上下文不匹配，并且应用程序可以接受粘性登录中的身份验证方法，则会话的安全上下文切换到粘性上下文中的安全上下文。

会话结束时，会话的粘性登录会丢失。当包含该组的任何应用程序的所有会话都结束时，该组的粘性登录将丢失。

初始登录后，组有一个关联的粘性登录对象，它在进入组的一个应用程序时尝试使用该对象。当组中的应用程序输入为 UnknownUser 时，粘性登录不会更新，因为这会将组中的所有其他应用程序移动到未经身份验证的安全上下文中。

如果粘性登录包含经过双重身份验证的用户，则该双重身份验证用于非双重身份验证应用程序，只要用户名身份验证在两个应用程序中匹配即可。

级联认证

CSP 服务器在尝试获取应用程序的身份验证信息时使用优先级。

操作系统： CentOS Linux release 7.9.2009 (Core)

1.查看数据相关信息

1）查看Caché数据库实例信息

[root@TestServer /]# ccontrol list

Configuration 'CACHE'   (default)
	directory: /opt/cache
	versionid: 2016.2.3.907.11.20719
	conf file: cache.cpf  (SuperServer port = 1972, WebServer = 57772)
	status:    running, since Tue Oct  4 12:54:05 2022
	state:     ok

2）查看Caché数据库私有apache版本信息

[root@TestServer /]# /opt/cache/httpd/bin/httpd -V
Server version: Apache/2.4.12 (Unix)
Server built:   May  6 2015 13:42:21
Server's Module Magic Number: 20120211:41
Server loaded:  APR 1.4.6, APR-UTIL 1.5.1
Compiled using: APR 1.4.

cache数据库自身带有系统监控Portal界面，但需要运维人员定期主动查看才能获取监控信息。当系统故障发生时，容易出现由于没有及时获取故障信息而不能及时处理，从而导致造成的影响扩大。本文研究通过解析cache数据库控制台日志（cconsole.log）进行监控信息获取并主动推送微信或短信实现cache数据库主动实时监控。

cache数据库在运行时会将所有控制台消息包括一般消息、系统错误、某些操作系统错误和网络错误都会发送到控制台日志文件，通过操作员控制台工具从其他系统远程启动的作业的成功或失败等信息也会写入控制台日志，因此通过对控制台日志的解析即可获取所需要监控信息。具体步骤方法如下：

解析控制台日志

控制台日志默认存储在install-dir\mgr路径下。

根据cache版本不同，使用的读取方法也不同。对于cache2016版本以上，系统提供了EnsLib.SQL.Snapshot类，可以直接获取日志的行和列信息，非常方便。对于cache2010及以下版本则无此方法，需要使用%File文件读取方法。

随着系统运行时间增加，控制台日志也会不断增大，造成每次检索时间加大，且不容易找出最近的监控信息，作出有效监控。较好的方式是每次解析时均从上次的节点继续进行，以便获取新的有效的监控信息。可以使用指定global来记录每次执行的最后一行ID，下次执行时从ID+1行开始解析来达到目的。

第二十二章 CSP Session 管理 - Private Pages

CSP 提供了私有页面的概念。只能从同一 CSP 会话中的另一个页面导航到私有页面。私有页面对于想要限制对某些页面的访问的应用程序很有用。

例如，假设有一个名为 private.csp 的私有页面（CSP 示例页面之一）。用户无法直接导航到 private.csp（例如，通过输入其 URL）。用户只能从另一个 CSP 页面中包含的链接导航到 private.csp。引用 CSP 页面中包含的链接不能是绝对 URL，以 http:// 开头。只有相对于引用页面的路径才被私有页面方法正确加密/标记。即：下面的前两个链接将相同的令牌传递给目标私有页面 test2.csp。

<A HREF='test2.csp'>Link to private page - relative path</A> <BR>
<A HREF='/csp/samples/test2.csp'>
       Link to private page - full application path</A> <BR>

此链接的散列方式不同，无法访问。

<A HREF='http://myserver/csp/samples/test2.

使用Cache的两个痛点问题：

一、Cache作为后关系型数据库，使用其提供M语言操作Global数据结构。可以达到极快的查询速度。M语言的set赋值和初始化没有区分，加之是弱类型，非常容易出现死循环，就算你是多年老手也一个不小心就踩坑。我就经历过改代码即使很小心还是出了死循环把数据库tmp撑满的事故。

二、M语言作为完备的编程语言，结合cache数据库操作数据实在是不要太方便。同时一个复杂的业务提交到数据库通过一个M逻辑全部处理完成，极大的减少了app和数据库交互次数。复杂业务的事务就是一方面，通过TSTART、TROLLBACK 、TCOMMIT，前台一次数据库交互后台就可能做了几十张表的更新操作。直接使用事务是容易，但是极易引入开放事务锁表（你自己就算很小心，也难保调别人接口别人事务不完善，而你又没检测事务层级），锁表之后结束进程导致数据回滚。

解决办法：

据我观察出现上面两个问题的原因，第一个是M语言弱类型和没单独的初始化命令导致，就算你是老手、工作细致也难以避免。第二个不是Cache特有的，通用关系库也有事务写的不完整的问题，事务问题对开发要求高或者从框架设计可以解决。

可以基于AOP切面设计一套死循环和开放事务避免体系，从架构上解决死循环难以发现引起的数据库崩溃和开放事务问题。

首先要求程序框架有统一的调入数据库入口，才方便在入口统一实现死循环监测和开放事务监测。

第二十一章 CSP Session 管理 - 身份验证和加密

身份验证和加密

在发送到 HTTP 客户端的页面上放置状态信息是很常见的。当从这些页面发出后续请求时，会将状态信息发送回服务器。很多时候，重要的是将状态信息放置在网页上，以便 a) HTTP 源的查看者无法确定状态信息的值，并且 b) 服务器可以验证返回的信息是，实际上，从同一服务器和会话发送出去。通过其加密服务，CSP 提供了一种易于使用的机制来实现这一点。

Session Key

CSP 可以使用加密密钥对服务器上的数据进行加密和解密。每个 CSP session 都有一个唯一的会话密钥（可通对象 Key 属性中的 %CSP.Session 访问），用于加密会话数据。这种机制是安全的，因为会话密钥永远不会发送到 HTTP 客户端；它作为 %CSP.Session 的一部分保留在 CSP 服务器上，位于对象中。

可以在类中使用 %CSP.Page的 Encrypt 方法手动加密服务器上的值。可以随后使用 Decrypt 方法解密此值。

加密 URL 和 CSPToken

在某些情况下（如下所述），从 .csp 文件生成的类会自动加密发送到客户端的 URL 值（对于手动创建的类，必须在类中调用 %CSP.Page的 Link 方法才能执行此操作）。

例如，假设 .

CORS请求Request携带Cookie失败占用License解决方案

起因

1. 因为是前后端分离的项目，前端使用的vue2，后端iris。需要获取cooike的sessionid，每次请求时携带cookie，防止每次请求都占用一个license。

2. 登录认证，保持会话期间全局变量，超时退出。

现象

下图是如果不携带cookie每次请求都会新建一个session并且占用一个license。

解决过程

所以基于上述情况，需要每次获取响应response的cookie，保存下来，下次请求request再携带保存下来的cookie。

如图Set-Cookie内容:

• CSPSESSIONID - 为SessionID的CSPSessionCookie
• CSPWSERVERID - 服务器ID，负载均衡时会用到，如果ID不对应，则会报错。

后端方法为%CSP.Response的WriteHTTPHeaderCookies()：

Method WriteHTTPHeaderCookies()
{
	#Dim c,cookie,port,cookiepath
	s ^yx("yx","UseSessionCookie") = %session.UseSessionCookie
	s ^yx("yx","CSPSessionCookie") = %session.

第二十章 CSP Session 管理 - 状态管理

状态管理

因为 HTTP 是无状态协议。为 Web 编写的应用程序必须使用特殊技术来管理应用程序上下文或状态。 CSP 提供了许多用于状态管理的机制。这些中的每一个都可能适用于特定情况。

请求之间的跟踪数据

Web 应用程序中状态管理的基本问题是跟踪连续 HTTP 请求之间的信息。有许多可用的技术，包括：

• 使用隐藏的表单字段或 URL 参数在单个页面上存储数据
• 将数据存储在客户端的 cookie 中
• 将数据存储在服务器上的对象中的 %CSP.Session中
• 在 Caché 数据库中存储数据

在页面中存储数据

要将状态信息存储在页面中，必须放置它以便来自该页面的后续请求包含该信息。

如果页面通过超链接发出请求，则数据应放置在超链接的 URL 中。例如，这是一个包含在 .csp 文件中定义的状态信息的超链接：

<a href="page2.csp?DATA=#(data)#">Page 2</A>

当 CSP 为包含此链接的页面提供服务时，表达式 #(data)# 将替换为发送给客户端的文本中的服务器变量 data 的值。当用户选择这个指向 page2.csp 的链接时，CSP 服务器可以通过 %request 对象访问 DATA 的值。如果需要，CSP 可以对此类数据进行编码。

ObjectScript是一种面向对象的编程语言，它是InterSystems公司的Caché和Ensemble数据库的核心语言之一。ObjectScript语言的语法类似于MUMPS语言，它支持面向对象编程、过程式编程、函数式编程等多种编程范式。ObjectScript语言主要用于开发Caché和Ensemble数据库应用程序，它可以访问数据库中的数据、调用数据库中的存储过程、触发器和事件，还可以与其他编程语言进行交互。

Cache使用的语言是ObjectScript简称COS，下面展示的是其基本语法，也是我个人的COS字典：

1 系统指令

SET           缩写 s ，赋值命令，样例 - s hello ="Hello World"；

WRITE      缩写 w ，向当前设备输出，样例 - w hello （特殊用法：w ! 换行、w # 清屏 ）

DO            缩写 d ，执行函数，样例 – d ##class(%SYSTEM.License).ShowSummary();

Kill            缩写 k ，从堆栈中清楚变量 x，慎用（不加参数调用时候将清楚内存中的所有变量!

第十九章 CSP Session 管理 - %CSP.Session 对象

对象中的 %CSP.Session 包含有关当前Session的信息以及以编程方式控制会话各个方面的方法。

User Session Data — Data Property

可以使用其 Data 属性将 %CSP.Session 中的应用程序特定信息存储在对象中。数据是一种多维数组属性，可让关联多维数组中的特定信息。该数组的内容会在会话的整个生命周期内自动维护。

可以像使用任何其他 ObjectScript 多维数组一样在对象 Data 属性中使用 %CSP.Session。

例如，如果在 OnPage 方法中执行以下代码：

 Set %session.Data("MyData") = 22

然后对同一会话的后续请求（无论哪个类处理请求）在对象中的 %CSP.Session中看到此值：

 Write $Get(%session.Data("MyData")) // this should print 22

注意：理解为全局变量。

在%CSP.Session 中存储应用程序特定数据的能力是一项非常强大的功能，但应该正确使用。进一步讨论请参阅“状态管理”部分。

设置用户Session数据 - 设置命令

要在对象的 %CSP.

第十八章 CSP Session 管理 - 与 CSP.Session 的Sessions

`` 是一种无状态协议；每个请求都不知道以前的请求。虽然这适用于为用户提供简单静态内容的网站，但它使得开发交互式动态 Web 应用程序变得困难。为了解决这个问题，CSP 提供了所谓的Session 管理。

与 CSP.Session 的Sessions

Session 话表示在特定时间段内从特定客户端到特定应用程序的一系列请求。

CSP 自动提供会话跟踪；无需执行任何特殊操作即可启用它。 CSP 应用程序可以通过对象中的 %CSP.Session 查询和修改其会话的各个方面。 CSP 服务器通过 ObjectScript %session 变量使该对象可用。

Session 会话创建

当 HTTP 客户端向 CSP 应用程序发出第一个请求时，会话开始。

创建新session时，CSP 服务器会执行以下操作：

1. 创建一个新的会话 ID 号。
2. 酌情执行许可检查。
3. 在对象（持久）中创建 %CSP.Session的新实例。
4. 调用当前session事件类（如果存在）的 OnStartSession 方法。
5. 创建一个 session-cookie 以便在会话过程中跟踪来自 HTTP 客户端的后续请求。

第十七章 CSP 中的 HTTP 请求 - %CSP.Response 对象和 OnPreHTTP 方法

%CSP.Response 对象和 OnPreHTTP 方法

可以使用对象中的 %CSP.Response 控制将哪些响应标头发送回 HTTP 客户端。 CSP 服务器自动创建此类的一个实例，并将对它的引用放在变量 %response 中。

由于 %response 对象控制 HTTP 标头，因此通常在类中的 %CSP.Page 的 OnPreHTTP 方法中设置其属性。例如，要重定向传入的 HTTP 请求，请定义以下 OnPreHTTP 方法：

Class MyApp.Page Extends %CSP.Page
{
// ...

ClassMethod OnPreHTTP() As %Boolean
{
    Set %response.ServerSideRedirect = "C:\CacheSys\csp\samples\redirect.csp"
    Quit 1
}
}

如果使用 CSP 类创建 CSP 页面，请使用以下代码设置标题值：

Class MyPage Extends %CSP.

第十六章 CSP 中的 HTTP 请求 - %CSP.Request 对象

%CSP.Request 对象

当 CSP 服务器响应 HTTP 请求时，它将有关传入请求的信息打包到对象中的 %CSP.Request 实例中。可以使用变量 %request 来引用此对象。

URL 属性

要查找传入 HTTP 请求的 URL（不包括查询字符串），对象中使用 %CSP.Request 的 URL 属性：

 Write "URL: ", %request.URL

数据属性和 URL 参数

URL 可能包含参数列表（也称为 URL 查询）对象中的 %CSP.Request 通过其 Data 属性使这些可用。

例如，假设传入的 URL 包含：

/csp/user/MyPage.csp?A=10&a=20&B=30&B=40

可以使用以下命令在服务器上检索这些参数：

 Write %request.Data("A",1)    // this is 10
 Write %request.Data("a",1)    // this is 20
 Write %request.Data("B",1)    // this is 30
 Write %request.

第十五章 CSP 中的 HTTP 请求 - 处理 CSP 错误

处理 CSP 错误

%CSP.Error是默认的 CSP 错误页面。将其用作创建的任何错误页面的超类。可以使用 %CSP.Error中提供的功能从错误中提取信息。

在授予许可证之前处理 CSP 错误

如果已经有一个现有会话并且用户尝试转到一个未找到的页面，CSP 将显示标准错误页面，因为该会话已经有一个许可证。

如果 CSP 应用程序还没有许可证，并且发生以下任何错误，则 CSP 默认显示标准 Web HTTP/1.1 404 Page Not Found 错误消息。可以通过在错误页面（通常是 %CSP.Error的子类）上为应用程序设置以下参数来更改在授予许可之前遇到错误时显示的页面。

LICENSEERRORPAGE

如果生成以下错误，CSP 会查看 LICENSEERRORPAGE 参数的值：

Cannot grant license.

LICENSEERRORPAGE 可以有以下两个值：

• "" — 返回 HTTP/1.1 404 Page Not Found 错误（默认）

• 静态 HTML 页面的路径 — 显示命名的静态页面，例如 /csp/samples/static.html。

第十四章 CSP 中的 HTTP 请求 - CSP.Page 类

在 CSP 服务器上，所有 HTTP 请求都通过调用由类中的 %CSP.Page 定义的方法来处理。类中的 %CSP.Page 从不直接处理请求本身；它只是定义了处理 HTTP 请求所需的接口。实际的事件处理的 %CSP.Page 的子类完成（手动创建或作为处理 CSP 源文件的结果）。

%CSP.Page 的子类永远不会被实例化；也就是说，不会在对象中创建 %CSP.Page。 %CSP.Page 定义的方法都是类方法，不需要对象即可调用。正如我们将看到的，这些方法所需的任何状态信息都由 CSP 服务器管理的其他对象（例如%CSP.Request 和对象中的 %CSP.Session）提供。

Page 方法

在 CSP 服务器确定类中的哪个 %CSP.Page 应该处理请求后，它会设置适当的处理上下文，然后调用该类的 Page 方法。设置处理上下文包括重定向标准输出设备 ($IO)，以便将所有输出（使用 Write 命令）发送回 HTTP 客户端并创建任何所需对象的实例（例如 %request、%response 和%session 对象）或局部变量。

Page 方法处理对 HTTP 请求的完整响应。它通过按顺序调用回调方法 OnPreHTTP、OnPage 和 OnPostHTTP 来做到这一点。

第十三章 CSP 中的 HTTP 请求 - CSP 服务器事件流

当 CSP 服务器收到来自 CSP 网关的请求时，它会确定该请求是针对静态页面还是针对 CSP 类的。如果是静态页面，它会立即将页面发回。如果是针对 CSP 类，它会执行以下操作：

1. 确定此请求属于哪个会话。如果没有，它会启动一个新会话。
2. 确保在正确的 Caché 命名空间中处理请求。
3. 确保对象中正确的 %CSP.Session可用，并根据 HTTP 请求中包含的信息在对象中创建 %CSP.Request 的实例。如果需要任何解密，它也会这样做。
4. 构造 %CSP.Response 对象以允许应用程序修改响应标头。
5. 确定应由哪个类处理请求并调用其 Page 方法（该方法又调用 OnPage 回调方法）。

CSP 服务器 URL 和类名称解析

CSP 服务器通过解释其 URL 来确定将 HTTP 请求分派到哪个类。 CSP 将 URL 分解为以下组件：

协议和服务器地址由 Web 服务器处理，与 CSP 服务器无关。

简单分享下在医院实际业务过程中%Dictionary.CompiledClass的一些应用。
一，Query查询出来的数据直接存表。
       我们经常会遇到一些突如其来的检查，如：飞行检查，审计检查等等，往往一下子要查询几年的各种数据，每种数据涉及字段还非常多，数据之间还要求对上，查询耗时长，数据对比难度大，此时，我们需要把查询出来的数据直接存到临时表，数据核对和修改直接在临时表中完成，核对好的数据直接在sqldbx或者水滴等查询工具中整表导出，效率会高一些。
       具体实现：按照数据要求，把表建好，Query输出字段和表字段顺序一致，按日期每天调用Query查询和插入，记录异常数据，后续单独处理。
       优点：效率明显提高，数据核对和修改、导出很方便，避免了数据量大，多次查询耗时长问题。
       缺点：数据量大会占用存储，记得删。
// W ##CLASS(lizw.CloseCycleData).insertDayByDay("2022-01-01","2022-06-30")
ClassMethod insertDayByDay(sd, ed)
{
    k ^tmplzw("insertFromQyeryTestpara",$j)
    S classOBJ=##class(%Dictionary.CompiledClass).%OpenId("lizw.

背景

Cache起源于没有SQL的1970时代，当时各种高级计算机语言才刚刚诞生，其中M语言较为独特，它的诞生就是为了在没有操作系统的机器上，进行数据存储。别忘了，Unix在1971年才发布。M语言别具一格地采用了Global多维数组，统一了复杂的内存操作和文件读写，使之成为了1970年代数据库的事实标准，特别是在医疗行业。而后Intersystems在1978年接过M语言的旗帜，在M语言上添加了SQL兼容层和ObjectScript层，前者顺应了时代的潮流，后者不仅为M语言提供了强大的OOP和各种便捷的语法糖，还让数据能以对象形式进行访问，让数据和代码更加紧密。

本文将简述多维数组、SQL、对象这3种数据操作方式，提供实例代码片段，并在运行效率、开发效率、管理效率、实用性方面讨论它们的优缺点。 为方便讨论，以学校与学生为例。对每种操作方法，都列举3种典型的用例，分别为，访问某特定ID的学生（即数据库ID索引）、访问某特定studentID的学生（即遍历唯一索引）、和访问某学校的所有人（即遍历非唯一索引）。

第十二章 CSP 中的 HTTP 请求 - CSP 运行时环境

CSP 的主要任务是提供动态内容以响应传入的 HTTP（超文本传输协议）请求。本节介绍 CSP 如何处理 HTTP 请求的基础知识。

HTTP 是一种简单的协议，其中客户端向服务器发出请求。 HTTP 是一种无状态协议；客户端和服务器之间的连接只持续为服务请求所需的时间。每个 HTTP 请求都包含一个请求标头，该标头指定请求类型（例如 GET 或 POST）、一个 URL 和一个版本号。请求还可能包含附加信息。 CSP 自动确定它应该处理哪些 HTTP 请求，将它们分派到运行在 Caché 服务器上的适当类，并将请求信息打包成易于使用的对象（例如对象中的 %CSP.Request）。

CSP 运行时环境

下图显示了 CSP 和 HTTP 请求的架构：

CSP 应用程序的运行时环境包括以下内容：

• HTTP 客户端（例如 Web 浏览器）
• HTTP 服务器（Web 服务器，例如 Apache 或 IIS）
• CSP 网关（Web 服务器的 Caché 插件）
• Caché 服务器（CSP 服务器在其上运行请求的 CSP 应用程序）

HTTP 请求处理

下图说明了 CSP 处理 HTTP 请求时的事件流：

1. 浏览器（或类似的 Web 客户端）发出 HTTP 请求。