IRISではCSPタグベースの開発は、非推奨(Deplicated)になっています。

非推奨とはいえ、いますぐ使えなくなることはないと思います。

が、CSP機能に含まれるHyperEventの#server()#呼び出しは、かなりやばいということがわかってきました。

これはChromeを始めとするメジャーなブラウザーが提供しているSynchronous XMLHttpRequestという関数を呼び出しています。

この関数をGoogleは10年前くらいから非推奨機能としていて、いつか完全に機能をドロップすると宣言しています。

Stackoverflowの該当記事

インターシステムズのドキュメントにもさりげなく記載されています。

HyperEventCallメソッド

とはいえ、10年もそのままなので、希望的観測をすれば、今後も使える可能性は高いかもしれません。

しかし、ある日突然なくなるリスクはゼロではありません。

ですので、#server()#呼び出しをお手元のコードからなるべく早く取り除くのが賢明です。

それでは、どうすれば良いのか？

ということですが、今のご時世で考えれば、REST APIに変えましょうというのが美しい世界ですが、おそらく書き換えのコストは、半端じゃないでしょう。

ということで、現実的な解は、#Call()#に置き換えることだと思います。

しかし、#call()への書き換えも一筋縄ではいかな

MacOS(Linux)とWindows両方で動作するObjectScriptプログラムを開発する際に、よくやらかしてしまうミスを共有します。

WindowsとUNIX系のファイルシステムの１つの違いは、ディレクトリのセパレータです。

UNIX系は、/（スラッシュ）

Windows系は、\（バックスラッシュ）

です。

ファイルを読み書きするプログラムでセパレータをOS別に選択するという以下のようなコードをよく書くのですが、

if ($system.Version.GetOS() = "UNIX") {
    set sep = "/"
}
else {
    set sep = "\"
}

ここでこのバックスラッシュをキーボードで入力すると、日本語キーボードの場合、バックスラッシュの代わりに¥（円マーク）が入力されてしまいます。

ソースコードがSJISの場合は、これでも問題ないのですが、クロスプラットフォームで開発する場合は、UTF8で通常作成するので、Macで動かすと問題ないのにWindowsで動かすとエラーになるということがちょくちょく起こります。

そして、これは意外に間違いに気づきにくいです。

ちなみにPythonでは、どちらでも/を使っておけば問題ないので、こんな問題は起こることはないと思います。

これは InterSystems FAQ サイトの記事です。
 

WebSocketは、リアルタイム双方向通信を可能にするプロトコルで、Webアプリケーションの動的な操作性を向上させるために広く活用されています。

この技術は、TCP上で動作し、HTTPプロトコルを介して接続を確立します。

一度接続が確立されると、持続的な接続が維持され、サーバーとクライアントが効率的にデータを交換できるのが特徴です。

通常のHTTP通信の場合、クライアントからのリクエストに対してサーバーが応答するというのが基本的な動作になるため、サーバーから非同期にデータを送信することが難しいですが、WebSocketを利用することでそのような機能を簡単に実現できます。

一方で、サーバーからの一方向の非同期通信が実現できれば良いという要件であれば、SSE (Server-Sent Events)を使用することもできます。

一般的にWebSocket通信が最も適していると考えられるのは、クライアント・サーバー間で双方向にデータを交換する必要がある場合になります。

双方向の接続を維持する必要があるため、状況によって、サーバー上のコンピュータ資源の消費（メモリー、CPU、IRISライセンス使用量など）に注意する必要があります。

ネット上にもWebSocketに関する様々な情報（メリット・デメリットを含む）がありますので、インターネット上で

これは InterSystems FAQ サイトの記事です。
 

PythonからIRISにアクセスするためのNative SDK for Pythonと呼ばれるインタフェースが用意されています。

Javaや.Net用に用意されているNative SDKと同等な機能が提供されています。

（一部異なる機能があります）。

また、Python用にはEmbedded Pythonと呼ばれるIRISと密に連携した機能があります。

IRISから最大限の性能を得るためには、Embedded Pythonが適していますが、以下のような場合、Native SDKが適しているケースもあります。

1. 異なるサーバーでIRISとPythonプログラムが連携する必要がある。
2. 同一サーバー上でIRISとPythonが稼働するが、システムが異なる（サブシステム間連携など）
3. システムを別々の開発ベンダーが構築するなど、明確な境界を設けたい場合

Native SDKを利用することで以下のようなことを実装することができます。

1. ObjectScriptやEmbedded Pythonで作成したメソッドの実行
2. IRISオブジェクトの操作
3. IRISグローバルデータの操作
4. DBI-APIによるデータベースアクセス

以下からこれらのサンプルプログラムを取得することができます。

Native SDK for

これは InterSystems FAQ サイトの記事です。
 

.NETからIRISにアクセスするためのNative SDK for .NETと呼ばれるインタフェースが用意されています。

JavaやPython用に用意されているNative SDKと同等な機能が提供されています。

（一部異なる機能があります）。

Native SDKを利用することで以下のようなことを実装することができます。

1. ObjectScriptやEmbedded Pythonで作成したメソッドの実行
2. IRISオブジェクトの操作
3. IRISグローバルデータの操作
4. ADO.NETによるデータベースアクセス

以下からこれらのサンプルプログラムを取得することができます。

Native SDK for .NETサンプル1

Native SDK for .NETサンプル2

.NETに様々な手段でアクセスするサンプル

詳細は、以下のドキュメントをご参照ください。

InterSystems Native SDK for .NET

CSPでWebアプリケーションを開発する方法は今では推奨されていませんが、既存資産が膨大にあって、他の手法への書き換えには相当の時間がかかりそうな方々はたくさんおられることでしょう。

そういう方々は、しばらくはそれらCSPファイルのメンテナンスの必要性があるかと思います。

IRISではVSCodeが主たるIDEとなっていますが、開発環境がWindowsのみであれば、CSPファイルをSJISでメンテナンスしておけば、問題は起こりません。

ところが、それらのファイルをUNIX環境(LinuxやMac)に持っていって、VSCodeで編集作業を開始すると、文字化けの嵐となってしまいます。

これは以前にポストしましたが、UNIX環境のIRISは何も設定しないとロケールがenuw（英語）となっているためです。

さらにこれを日本語専用ロケールに変えても、unix環境ではロケールがjpuwの場合、ファイルの読み書きのエンコーディングが、utf8となっているので、cspファイルのエンコーディングがSJISのままでは都合が悪いです。

従ってCSPファイルのエンコーディングをUTF8に変更する必要があります。

しかし、プラットフォームの切り替えのたびにエンコーディングを変更するのも面倒です。

そこで推奨の方法は、ファイルのエンコーディングをUTF8のBOM付きに変更することです。

そうすることでプラットフォームがUNIX

これは InterSystems FAQ サイトの記事です。
 

ルーチンやメソッドを実行した際に以下のような<FRAMESTACK>エラーが発生する場合、DOコマンドの発行の入れ子数が多すぎて、それ以上スタック情報を保持できなくなったことを示しています。

<FRAMESTACK> error is reported when the routine has too many nested calls to DO command. You can check the current stack with $STACK value.

可能性として高いのはプログラミング上のミスで再起的なメソッド/ルーチン呼び出しがループしている場合などです。

以下のようなプログラミングを行い、$STACK変数の値を確認することで、スタックのレベルがどのように変化しているのかを確認できます。

main() {
  write"main 1: ",$STACK,!
  do l1
  write"main 2: ",$STACK,!
  quit
}
 
l1() {
  write"l1 1: ",$STACK,!
  for i=1:1:5 {
    do l2(i)
  }
  write"l1 2: ",$STACK,!
  quit
}

l2(x) {
  wr

これは InterSystems FAQ サイトの記事です。
 

%String型のプロパティをOrder Byの条件にしてクエリーを発行した際のデータは以下のような順番で並べられます。

SELECT * FROM Shop.Order orderby StatusFlag

null
-1
-2
-99
0

これは%String型（文字列型）のプロパティの照合順として正しい振る舞いです。

文字列照合の並び順

文字列プロパティに対し、+ をつけることで、数値照合と同じ照合順を得ることができます。

SELECT * FROM Shop.Order orderby +StatusFlag

null
-99
-1
-2
0

これは InterSystems FAQ サイトの記事です。
 

SQLアクセス( ADO含む)を行う場合は、SQLトランザクションを使用して、トランザクションを制御します。

一方オブジェクトアクセス（ObjectScript）ではtstart / tcommit / trollbackコマンド 
(Native SDK for .NETでは IRIS の TStart(), TCommit(), TRollback() メソッド)
によってトランザクションを制御します。

この２種類のトランザクションモードを混在させて使用することはサポートされていません。

詳細は、以下のドキュメントをご参照ください。

トランザクション管理

また関連するメソッドの以下ドキュメントの注意事項にも

「このメソッドは Native SDK トランザクション・モデルを使用し、ADO.NET/SQL トランザクション・メソッドとは互換性がありません。

この 2 つのトランザクション・モデルを混在させないでください。」

と記載をしております。

Native SDK for .NET のクイック・リファレンス

これは InterSystems FAQ サイトの記事です。
 

$System.Encryption.Base64Encodeに指定するデータは、UTF8にエンコードして渡す必要があります。

日本語が含まれるローカル変数をこのメソッドの引数として指定すると<ILLEGAL VALUE>エラーが返ります。

以下のようにUTF8に変換後引数として渡す必要があります。

　set wLineData=$ZCONVERT(wLineData, "O", "UTF8")

詳しくは以下をご参照ください。

ドキュメント: $System.Encryption.Base64Encodeの説明

これは InterSystems FAQ サイトの記事です。
 

何の設定も行なっていない場合、GROUP BYやDISTINCTで指定したフィールドは大文字小文字を区別せずに全て大文字として処理されます。

これはGROUP BYやDISTINCTのグループ化がフィールドに対して定義された照合タイプに基づいて行われ、その文字列照合の既定値がSQLUPPERになっているためです。

以下のドキュメントに説明がある通り、DISTINCT は、フィールドに対して定義された照合タイプに基づいて、文字列値をグループ化します。

大文字/小文字の区別と DISTINCT の最適化

これを変更する方法は、以下の3種類になっています。

(A) %SQLSTRING または %EXACT照合関数を使用する
(B) フィールドの文字列照合を SQLSTRINGに変更する
　また、フィールドにインデックスが設定されている場合には、インデックスの文字列照合も SQLSTRINGに変更する
(C) 管理ポータルで設定を変更する 

※(B)について補足
・文字列照合をEXACTに設定しても動作しますが、一般的にはSQLSTRINGの使用が推奨されています。
・フィールドの文字列照合とインデックスの文字列照合は、同じ設定にすることが推奨されています。

※(C)の設定手順

システム > 構成 > SQL  - (構成設定) 
GROUP BY と

これは InterSystems FAQ サイトの記事です。
 

ダイナミックオブジェクトの%ToJSONメソッドを利用することで簡単にJSONデータを送信することができます。

但し、標準的な方法では、出力するJSONのデータがIRIS文字列の最大長（約32万文字　正確には$SYSTEM.SYS.MaxLocalLength()が返す値）を超えると<MAXLENGTH>エラーとなります。

これを回避するためには、文字列として返すのではなく、%ToJSONメソッドの出力先としてStreamを指定し、その結果作成されたそのStreamデータを順次読み取って、出力先に書き出すようにする必要があります。

以下のように処理できます。

ClassMethod bigjson() As%Status [ ProcedureBlock = 0 ]

{

   setx={}

   for i=1:1:100 { 

       set cmd=" set x.a"_i_" = ^a ";; ^aのサイズは1MBxecute cmd

   }


   set tmpStream = ##class(%Stream.GlobalCharacter).%New()

   dox.%ToJSON(tmpStream) 

   while

これは InterSystems FAQ サイトの記事です。
 

JSON利用の普及に伴いインターシステムズは、JSONに関連する様々な機能強化をIRISに対して行なっています。

その一環として、SQLのJSON_OBJECTのサポートがあります。

この機能に関して現時点より（2025年6月）古いバージョンでは残念ながら制限や不具合が存在しています。

今後も機能強化やバグフィックスを継続していく予定となっているため、この機能の利用を検討および既に利用している方は最新バージョンでのご利用をお勧めします。

ここでは、現時点でわかっている制限事項／不具合についてお知らせします。

• VIEW経由でJSON_OBJECTを利用した場合にエラーとなる場合がある 以下のようなクラスとVIEWを定義します。  

Class User.test Extends%Persistent
{

  Property p1 As%String;Property p2 As%String;
}

Class User.myview [ ClassType = view, ViewQuery = { select p1 as v10, p1 as v11, p2 as v12 from test } ] { }

この定義に対してデータを登録後、以下のようなSQL文を発行すると、<UNDEFINED

以前はMac上でDockerを動かす場合は、Docker for Macを使用していましたが、ある時点でマルウェア判定されてしまい、削除されてしまいました。

以下の記事によれば、最新版では解決しているようです。

Docker Desktop for Macがエラーで起動できない件(#7527)についての情報

そこで他の選択肢はないか調べてみるといくつか選択肢がありました。

その中でColimaというのがあり、設定してみました。

Colima で Docker と Docker Compose を使ってみた

設定も非常に簡単であり、実際のdockerやdocker composeの動かし方はほとんど変わりません。

一つColimaの方が良いと感じたのは、Docker for Macの場合、IRISのスクリプトの実行の結果として出力されるメッセージは、スクロールされて、Dockerコンテナの起動が終了すると、痕跡が残らないため途中でエラーが発生してもその場で確認できませんでしたが、Colimaの場合、ターミナル上で垂れ流されるだけなので、そのターミナルのスクリーンをロールバックすることで出力メッセージを確認できる点です。

前回、macOS上でLibreOfficeからODBC経由でアクセスするためのセットアップについて記事を書きました。

今回 .Net経由でODBCにアクセスする方法を試したので報告します。

LibreOfficeの場合、iODBCでしたが、.Netの場合は、unixODBCを使用します。

従来のバージョンでは、IRISのunixODBCドライバーはUnicode対応（ワイド）でなかったため、.NetのODBCでは日本語を正しく処理できませんでしたが、2025.2よりワイドドライバーが追加されたため正しく処理できるようになりました。

今回.Net経由のアクセスを試した理由は、ODBC版Cache DirectエミュレータをMacで動かせないかと考えたからです。

ODBC版Cache Directエミュレータ

こちらのリポジトリにも設定方法の詳細を記載していますが、Mac上でunixODBCドライバーを設定する方法を紹介します。

• IRISバージョン

unixODBCのUnicode(ワイド)版のドライバーが必要なため、IRIS 2025.2以降のバージョンが必要です。

• unixODBCのインストール

Homebrewを使用してインストールします。

brew install unixodbc

• 必要なunixodbc関連ライブラリをコピーする

cp

これは InterSystems FAQ サイトの記事です。
 

JDBCクライアントからのアクセスでエラーが発生した場合、返ってきたエラーメッセージやコンソールログ上の情報だけでは原因がよくわからない場合があります。

そのような場合にJDBCドライバのクライアントログを取得することで、エラーについての詳細情報を取得することができます。

JDBCログの取得方法については以下をご参照ください。

JDBCのログ

ログを指定する際に、ディレクトリ名を含まずに直接ファイル名を指定した場合、そのアプリケーションのディレクトリにその指定したファイル名でログが出力されます。

ODBCログの様にPID毎に取得する方法は用意されていません。

JDBCログが正常に取得できている場合、以下の様な内容が書き込まれます。

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
	Started At:     2025/03/27 11:52:16
	Driver Name:    com.intersystems.jdbc.IRISDriver
	Jar File Name:  intersystems-jdbc-3.9.0.jar
	Client Version: 3.9.0.0
	Compiled At:    3

これは InterSystems FAQ サイトの記事です。
 

ODBCクライアントからのアクセスでエラーが発生した場合、返ってきたエラーメッセージやコンソールログ上の情報だけでは原因がよくわからない場合があります。

そのような場合にODBCドライバのクライアントログを有効にすることで、エラーについての詳細情報を取得することができます。

ODBCログの有効化については以下をご参照ください。

ODBCログの有効化

UNIX系のシステムの場合、上記に記載されている通り、２種類のログが取得できます。 

• クライアント・ドライバ・ログの取得方法 以下の環境変数でトレースのオンと出力するファイルを指定します。

export IRISODBCTRACE=1
export IRISODBCTRACEFILE=/Users/user1/work/odbcclient.log

•  ドライバマネージャのログの取得方法 ドライバマネージャのデータソース設定ファイル(ODBC.ini)に以下の様にトレースをオンにする設定とログファイルの場所と名前を指定します。

[ODBC Data Sources]
IRIS ODBC User = IRIS iODBC Driver

[IRIS ODBC User]
Driver      = /opt/iris/bin/libirisodbc35.so

これは InterSystems FAQ サイトの記事です。
 

ダイナミックオブジェクトの%FromJSONFileメソッドを利用すると簡単にJSON形式のファイルの内容をダイナミックオブジェクトにコピーすることができます。

以下の形式のJSONファイルをそのメソッドを使用して取り込む例は以下のようになります。

{
    "ShipTo": {
        "City": "Tokyo",
        "Street": "Ginza",
        "PostalCode": "160-0001"
    },
    "CustomerId": 1,
    "Items": [
        {
            "ProductId": "MNT001",
            "Amount": 2
        },
        {
            "ProductId": "PC001",
            "Amount": 2
        }
    ]
}

set tempobj = {}.%FromJSONFile("c:¥temp¥sample.json") 
 set customerid = tempobj.CustomerId           
 set iter =

これは InterSystems FAQ サイトの記事です。
 

ODBCクライアントからのアクセスでエラーが発生した場合、返ってきたエラーメッセージやコンソールログ上の情報だけでは原因がよくわからない場合があります。

そのような場合にODBCドライバのクライアントログを有効にすることで、エラーについての詳細情報を取得することができます

ODBCログの有効化については以下をご参照ください。

ODBCログの有効化

Windowsの場合は、上記に記載されている通り、２種類のログが取得できます。

• クライアント・ドライバのログを有効にするには、ODBCデータソースアドミニストレータで使用しているDSNの「ODBCログ」チェックボックスをチェックします。 

• ドライバー・マネージャのログを有効にするには、[トレース]タブをクリックして[トレースの開始]ボタンをクリックします。

変更の反映にはODBCクライアントアプリケーションを再起動する必要があります。

既定のODBCクライアントログファイル名は IRISODBC.log で、既定の場所は C:¥Users¥Public¥Logs です。

既定のトレースログ名は、SQL.logで、既定の場所は、c:¥Users¥<ユーザー名>AppData¥Local¥Temp¥です。

（すべてのユーザーIDのコンピュータ全体のトレースをチェックしない場

これは InterSystems FAQ サイトの記事です。

「Maximum/Minimum_Server_Connections」の設定で、ApacheのMPM(Multi Processing Module)設定が、prefork になっている場合、Apache ワーカープロセスあたり２つ以上の IRIS/Caché コネクションを設定しても意味がないために、設定自体出来なくなっております。

※　preforkでは1つのプロセスが1つのスレッドを持ちます。

preforkの詳細は以下をご参照ください

MPM prefork/worker/eventの違い

.pyファイルの中でIRISのEmbedded Pythonを動作させる際にirispythonコマンドで実行する方法はドキュメント上で紹介されていましたので、以前より使用していました。

しかし、普通のpythonコマンドを使用するとうまく実行できなかったのですが、最近その謎（原因）が解けたので紹介します。

これは、Mac特有の問題である可能性が高くWindowsやLinuxでは何の問題もなく実行できるのかもしれません。

エラーは以下のようなエラーです。

  File "/opt/iris/lib/python/iris.py", line 34, in <module>
    from pythonint import *
ImportError: IrisSecureStart failed: IRIS_ATTACH (-21)

このエラーの原因は、シェルの実行ユーザーとirisのオーナーが異なることが原因とのことです。

Macで普通にIRISをインストールするとそのオーナーはrootです。

従ってpython3コマンドを実行する時にsudoコマンドでrootになる必要があるということです。

そして以下のような環境変数の設定も必要です。

export IRISINSTALLDIR=/opt/iris
export LD_LIBRARY_PATH=$IRISINSTALLDIR/bin:

その１で設定したODBCのシステムDSNを使って、LibreOfficeからアクセスしてみたいと思います。

ここでLibreOfficeをデスクトップから起動すると、詳細は不明ですが、日本語の表示がうまくできません。

（ロケール情報が正しく取得できていない様です）

なので、少し面倒なのですがターミナルから起動する必要があります。

起動する前にロケールが正しく設定されているか確認する必要があります。
一般的には、LC_ALLは設定されていないので、この環境変数に値を設定してエクスポートします。

 % locale                                              
LANG="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_CTYPE="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_ALL=""
% export LC_ALL="ja_JP.UTF-8"
% locale                     
LANG="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_CTYPE

Mac版のIRISにSQLを使用して他ツールからアクセスするケースはそもそも少ないと思いますが、DBeaverにJDBCを使用してアクセスできることはこのコミュニティの住人であれば、知っている人は結構いるかと思います。

しかし今回ちょっと理由があってMac上のIRISにODBCを使ってアクセスする方法についてトライしてみました。

ここではその備忘録を書き留めておこうと思います。

実際の所、Mac上のクライアントツールでODBCでアクセスできるツールもそんなにないのですが、

候補としてMS-Excel(MS-Query経由)またはLibreOfficeがありました。

まず結論としてExcelは色々とトライしましたが、原因不明ですがうまくつながりませんでした。

（どうもExcel(MS-Query)が拒絶している感じです）

LibreOfficeは何とか接続でき、データの取得はできる様になりました。

まず、前準備としてODBC Driver Managerというものをセットアップする必要があります。

細かくいうとこれにもiODBCとUnixODBCの２系統があるのですが、ExcelおよびLibreOfficeはiODBCにしか対応していない感じです。
（これは正確な情報ではない可能性はあります）

iODBC用のDriver

これは InterSystems FAQ サイトの記事です。

Content-Typeにcharset 情報が含まれていない場合、IRIS/Cachéは文字コードを判断できず文字コード変換が行われません。

そこで、以下のように、「自動的な文字変換を行わず、UTF-8に変換する処理を記述」することで、その指定がある無しに関わらず、対応することができます。
 

// requestオブジェクトは以下のように生成　// 詳細処理は省略// set request=##class(%Net.HttpRequest).%New()// リクエスト時に、文字変換を行わないように指定set request.ReadRawMode=1do request.Send("POST",URL)

 // 受取ったデータを、UTF-8に変換してから、JSON変換set response = request.HttpResponse.Data
 set data = response.Read()
 set data2 = $zcvt(data,"I","UTF8")
 set response = {}.%FromJSON(data2)
 write response.%ToJSON()

長い文字列が想定される場合には、一度のReadで読み込めない可能性があるため

これは InterSystems FAQ サイトの記事です。

ネームスペースを管理ポータルで作成する際に、デフォルトでは、『相互運用プロダクション用にネームスペースを有効化』にチェックがついているため、そのチェックを意図的に外さない限り、新規作成したネームスペースは、インターオペラビリティ機能が有効になっています。

この機能が有効であることによる実用上の弊害（パフォーマンス等に影響する）は、特にありませんが、管理ポータル上のクラス表示にこの機能に関連するクラスが先に表示されて、ユーザー作成クラスの表示に余計な操作が必要になる等の操作上の余分な手間が発生する場合があります。

管理ポータル上でこの設定を無効にするメニューは用意されていませんが、以下の手順で無効化することができます。

- 相互運用性ネームスペースの無効化  

USER>set$namespace = “%SYS”

%SYS>write##class(%EnsembleMgr).DisableNamespace("FAQ",1)

1

- 管理ポータルより該当のネームスペースの削除

- 管理ポータルより該当のネームスペースの再作成

再作成の際に「相互運用プロダクション用にネームスペースを有効化」のチェックを外す 

- 相互運用性ネームスペースの確認

%SYS>w##class(%EnsembleMgr).IsEnsemble

これは InterSystems FAQ サイトの記事です。

8192文字を超える文字列をODBC経由で取得した場合に特定のODBCクライアントとの組み合わせにおいて文字列が途切れて取得されるケースが報告されています。

このような状況が発生した場合、該当するODBCデータソースの設定画面でUnicode SQLタイプをチェックすることで問題が解消されることがわかっています。

これは InterSystems FAQ サイトの記事です。

大量のレコードが含まれるテーブルに対して、select count(*) from テーブル名の応答が遅い、または応答がタイムアウトする場合には、ビットマップ・エクステント・インデックスを追加することで問題を解消することができます。 

ビットマップ・エクステント・インデックスを追加する方法は、以下をご参照ください。 

ビットマップ・エクステント・インデックスの追加方法

クラス定義に以下のような定義を行うことで、ビットマップ・エクステント・インデックスを追加することもできます。

Index IndexName [ Extent, Type = bitmap ];

これは InterSystems FAQ サイトの記事です。
 

ObjectScriptの%Netパッケージのライブラリクラスを利用して、ファイルを他のサーバーにアップロードすることができます。

以下のCurl コマンドと同じことを ObjectScript で実現する方法を紹介します。

curl -X POST "http://localhost/api/upload/csv?a=123&b=999" -F file=@"C:/temp/a.csv":/temp/a.csv"

クライアントのObjectScriptコードを以下の様に作成します。

Class User.MyRestClient Extends%Base
{

ClassMethod readMimeData() As%Status
{
    // form-data (for CSV)set msg= ##class(%Net.MIMEPart).%New()

    set msg.ContentType = "multipart/form-data"set inputstream=##class(%Stream.FileBinary).%New()
    set sc=inputstream.LinkToFile("c:¥temp¥a.csv")
    If$$$I

これは InterSystems FAQ サイトの記事です。
 

計算プロパティを定義する際に利用可能なキーワードが複数あります。

詳細は、以下をご参照ください。

計算プロパティの定義

実際のこれらのキーワードの関連性は、少々複雑ですので具体的なコードを作成して動作を確認してみます。 

以下のようなクラス定義を作成します。(プロパティとインデックス定義のみ表示します)

完全なクラス定義は以下より、ダウンロードできます。

サンプルクラス定義

Class Sample.Person Extends%Persistent [ ClassType = persistent, ProcedureBlock ]

{

Property FirstName As%String;Property LastName As%String;Property DOB As%Date;Property Age1 As%Integer [ Calculated, SqlComputed, Transient ];Property Age2 As%Integer [ Calculated, Transient ];Property Age3 As%Integer [ Calculated, SqlComputed ];Property Age4 As%Integer [

これは InterSystems FAQ サイトの記事です。
 

IRISには、データ項目の値を実体として持たずに、何らかの演算処理の結果として提供する機能があります。

これを計算プロパティまたは計算フィールドといいます。

計算プロパティを定義するためには、最低限以下の手順を実行します。

プロパティ定義にSqlComputedキーワードを含めます。

プロパティ定義にSqlComputedCodeを含めて、値を算出するための処理ロジックとして含めます。

または、SqlComputedCodeを含めずに、代わりに<プロパティ名>Computationという名前のクラスメソッドを記述します。

以下は、Age（年齢）プロパティを計算プロパティとして定義した例になります。

Class Sample.Person Extends%Persistent　{　　　　　　　　　

　　Property FirstName As%String;　　　　　　　
　　Property LastName As%String; 　　　　　　
　　Property DOB As%Date; 　　　　
　　Property Age As%Integer [ SqlComputed ];　// ...ClassMethod AgeComputation(cols As%Library.PropertyHel