【番外編】システムはあくまで問題解決の帰結としてあるべき

　　　　　師にもらった言葉と、35年の要件定義

noteに記事を投稿しました。 https://note.com/mmizuno_mic/n/nc0032a805b00?app_launch=false

「AIが最後に評価したのは、一番古い規律だった」

note記事を公開しました。 https://note.com/mmizuno_mic/n/nb094d7c04b5f

「4D ORDAで実現するデータ中心設計の思想」
note記事を公開しました。 https://note.com/mmizuno_mic/n/n0f852742416d

みなさんおはようございます。
本日は昨日と合わせて２日間関東に出張に来ています。
新規のお客様との打ち合わせと、既存のお客様のメンテナンスとで２日滞在中です。
今思えば午前中のうちに4D社にお邪魔する予定を入れればよかったと後悔しつつブログを投稿しています。また機会はあると思うので次回は先に計画したいと思います。
みなさん今日も一日がんばりましょう。

ただいまお客様のホームページをリニューアル中です。
AdobeのMUSEが終了したこともあってDreamWeaverに切り替えるとともにBootstrapを導入してスマホ対応のレスポンシブなサイトにします。一足先に１ページだけ新しいページページを公開しています。クリスマスツリーのアレンジ例を一覧したページです。フッターにはさりげなく？「Powered by 4DWeb」を入れさせていただいてます(^_^)。
あ、それと「アイコンフォント」いいですね！
タイトルの後ろにあるツリーとかオーナメントはアイコンフォントです。
こんな感じ↓

「アレンジ一覧++」

https://www.doga-corp.co.jp/arrangelist/

やっと目的のサイトにログインすることができました！
今HTTPクライアントのプログラムを初めて開発中です。
多少の試行錯誤がありましたが、サポートのお力も借りつつひとまず大きな山を超えました。
業務効率化のために4Dサーバーからサイトのデータを自動的にダウンロードしてDBに保存します。
写真はログインフォームをコピペしてローカルでどのようなデータが送られるのかチェックしたところです。
ブラウザの動きを確認しながら4Dでそれを模倣して実現します。
これでやっと一気に開発が進むと思います。

ちなみにHTTP Requestで送信するデータのフォーマットを大きく勘違いしていて無駄な時間を費やしました。
HTTP GetとHTTP Requestは対のようなコマンドと勘違いして、Getで受信するデータがHTMLならRequestで送信するデータもHTMLかと思い込んでいました。データのフォーマットが全く違っていました。
ここに気がついたのは4D社のサポートへ問い合わせしてからでした。

理屈はわかっていても未経験の部分はえらい勘違いがあったりしますね。
急いで開発を進めなくてはいけませんが、とりあえずやれやれです。

ただいまYoutubeチャンネルを準備中です！
日本ではちょっとマイナーな4Dを広めるため動画配信を計画してます。
4Dのテクニカルチップスや旬なネタの他にシステム開発の基礎知識も含めて色々と発信していきたいです。
動画をアップしたらまたお知らせしますので、よろしくお願いします。

皆さんこんにちは。久しぶりにブログを更新しています。
最近はやはりバージョンアップの依頼が増えてきました。
そんな中で既存のお客様のシステムがなんと最初の開発が1998年。
それから22年が経過していました。
今回はv13からv17orv18?にバージョンアップします。
こんなに長く使っていただけると本当にありがたいことです。
ちなみにこのシステムはフォークリフトのメンテナンスマニュアルの版下を自動生成するものです。
時代の流れでPDFによる納品が増えてきたようですがまだまだしばらくは活躍してくれそうです。

先日Webシステムをv17にバージョンアップしました。 Webシステムはフォームをほとんど使わないので、その分バージョンアップ工数が少なくてすみます。 しかし印刷フォームは使います。サーバーサイドで印刷処理を行ってPDFファイルを生成しクライアントはそれをダウンロードする形で印刷ロジックを構成します。 今回のバージョンアップで4Dv17_64bitになったわけですが、今まで使っていたサードパーティーの「PDF Creator」を使わなくて済むようになりました。 プリンタードライバーはWindows10標準の「Microsoft Print to PDF」が使われるようです。 これでMacOS同様にOS標準機能でPDF出力ができるようになりました。

CALL WORKERを使うことで処理時間が1/8になった！

昨日v17にアップグレードしたお客様のシステムが不安定なので急遽メンテナンスに行ってきました。
データ保存時クライアント異常終了？（比較的データ量が多い場合？）
詳しい原因はただいま調査中です。それで、これをきっかけに採番処理が原因かもということで見直しをしました。
「CALL WORKERを使ってはいかがですか？」見直しのヒントをくれたのは4D社のサポートです。
早速マニュアルを見るとv15R5で新しく追加されたコマンドでした。
問題はデッドロックを避けるためにトランザクションの外（別プロセス）で採番処理を行っていたため、プロセスの起動・終了が採番が必要なだけ大量に行われることかも？
実は今までこの問題は起きてなかったのですが、今回なんとv17にアップグレードすることで問題となりました。
最近のバージョンで感じるのは4Dもシビアになってきたな〜（細部に注意が必要？）ということです。
急いでCALL WORKERを使ったロジックに採番処理を変更し、というかめっちゃ楽になったやん！
プロセス間通信のために受け渡しのロジックがあったのだけれど、それほとんど必要なくなったわ！
100個の連番を採番してテストしてみると、改良前が24秒、改良後が3秒、はやっ。
それはそうですわ、いちいちプロセス立ち上げなくてもワーカーが常駐してるから。
そして異常終了していた処理をエンドユーザーの方に試してもらうと、サクッと処理が完了しました。
一体どんな処理してたのと気になる方にご説明すると、100点ほどの商品の在庫移動です。
棚の変更になるのですが、在庫データの取引明細を追加するときにデータの連番を付与してます。
連番の振り方も自動とかプライマリキーとか色々ありますが、過去にsequence numberに悩まされた自分は自前で採番する方法を取ってます。
めでたしめでたし、と思ったら「システム終了できません！」、あっ！
終了ボタンに全ての画面を閉じたかどうかのチェックを入れてたので、ワーカーがまだ残っているためチェックに引っかかったのです。
ワーカーはチェックで無視するようにしてシステム終了できました。
そんなCALL WORKERなかなか使えそう。v16(v15R5)以降のお客様に横展開します。

4D社のホームページがリニューアルしてから以前よくみていたページがなかなか見つからないという話をよく聞きます。
そんな中で２つのページについてご案内します。
１）OS対応表
基本的には製品ダウンロードページに動作環境としてのスペックが記載されています。
さらには、ページ下部にある「関連リソース」の下のブラウズをクリックすると互換性というところに対応表のダウンロードがあります。

２）ナレッジベース検索
こちらはアドレスが頭から異なります。下記のURLをクリックして下さい。
http://kb.4d-japan.com

昨日は長野のお客様のところへメンテナンスで訪問しました（道中は雪）。
v17へのバージョンアップ前に確認することの中にシリアルポートの処理があります。
実はv17ではRECEIVE PACKETが使い物になりません。ものすごーく受信に時間がかかります。
対応策としてRECEIVE BUFFERに変更する必要があります。
テストデータベースを作成して現地でRECEIVE BUFFERによるQR読み取りテストを行いました。
問題なくサクサクと読み取りできることがわかりました。
４月のメンテナンスではv17にバージョンアップの予定です。
今後バージョンアップをお考えの場合、RECEIVE PACKETを使っていたらRECEIVE BUFFERに置き換えください。

以上。

先日お客様のスケジュール管理をWeb化しました。
4DWebは１ライセンスで無制限のユーザーが利用できるので、マルチユーザーにはとても有利です。
さてその時利用したのが「FullCalendar」というJQueryのプラグイン（ツール）です。
非常に簡単にカレンダー表示ができるツールです。
ただしスケジュールデータを動的にデータベースとやりとりするには一苦労が必要です。
FullCalendarに渡すデータの型はJSON形式かXMLデータです。
4Dには元々XMLを扱うコマンドが実装されていて自分としては扱いやすかったのでXMLデータを渡す形にしました。
逆にここさえ押さえれば4DWeb+FullCalendarはとてもいい感じでした。
早速私の運営するサイトにも横展したいと思います！

システムのメンテナンスについてお話しします。
お客様のシステムは保守サポートという形でメンテナンスを行なっています。
運用中に起こった問題や、ちょっとした改善なんかも保守の対象になることがあります。
お客様に気持ちよく使っていただくためには、作ったら終わり、ではなく常に改善・改良を行っています。
そうしてお客様のシステムには１０年２０年は当たり前に稼働しているものがいくつもあります。

さて日常の道具で２０年メンテナンスしてくれるものってどうでしょうか？
おおよそ１０年くらいでメンテナンスが難しくなってくるのではないでしょうか？
私の愛車は２０年乗っています。先日車検を受けてタイヤも変えてまだまだ現役です。
ただちょっとエアコンの効きが悪いなーと思っていました。
そこで車検を受けた後に相談に行ったのですが、原因がつかめず、古くなったからということに。
納得できずに今度は有名カーショップに持って行って洗浄して欲しいと頼みました。
３０分くらい待って言われたのは調べたけどできません？その理由もよくわからない？
結局メンテナンスしてもらえませんでした。
しょうがないので、ネットで調べて見ました。やりたいのはエバポレーターの清掃。
だいたいの場所はわかったので分解して見ました。
するとなんと我が家特有の問題が！竹の葉がぎっしりと隙間に詰まっていました。
この初期型のモデル、エアコンにフィルターが無いんです？
これではおそらく空気の流れが悪いのでエバポレーターが過冷却になりコンプレッサーは止まってしまっていたでしょう。
暑いのに冷たいので止まり車内は冷えないという状況に違いありません。
葉っぱをすべて取り除き、エバポレーターはセスキで清掃しました（家の室内のエアコンもそうしてます）。
するとどうでしょうエアコンは元気を取り戻し車内は快適に冷えるようになりました。

システムのメンテナンスに期限はありません。
運用に合わなくなってきたり、より良い改善案がひらめいたりしたらいつでもメンテナンスいたします。

Before

After

先日バージョンアップしたお客様で、画面がフリーズするという現象が起きた。
それを見て自分のハートも凍りついたかどうかはさておき、早速色々と試しながら原因を探った。
しか〜し一向に原因が掴めない。それで4D社のサポートに連絡した。サポートは世の中良くある繋がらないサポートではない。
すぐに原因についてあれこれとアドバイスいただいた。でも決め手がなかったので、デバッグログを取ることになりました。
問題のコードの直前でデバッグを開始して適当なところで終了します。ついでにログフォルダーを開いて問題のログをサポートに送りました。
するとOn Headerでとんでもないことが起きていました。
というかこのイベントの発生タイミングが自分が考えるにどうも不自然だ！
画面上すこ〜しでもどこか書き変わると必ず発生するらしい。
もはやOn Headerの使い道すらわからない？
で、大量のアクセスが起きてしまいには無限ループ的動きになってフリーズする。
とりあえず原因がわかったのでプログラムを修正してフリーズは発生しなくなりました。
ちなみに、ヘッダーエリアに表示中のデータ件数を表示するためオブジェクトメソッドで
self->:=records in selection(current form table->)
なんて書いてたわけですが、これが大量に実行されていたわけです。
今回v12からv16へのバージョンアップだったのですが、本当ならv12でも問題だったはず？？？
若干解せない部分はありますが、ともかく無事に問題解決できてよかったです。
4Dサポートに感謝。

昨日お客様のシステムをバージョンv12からv16にバージョンアップしました。

データサイズが23GBあったので変換時間がどのくらいかかるか心配でしたが、新しいサーバー環境は早かったです。

お客様には是非にと勧めてストレージはSSDにしていただきました。

ストレージ内で大きなファイルをコピーすると500MB/Sというスピードであっという間にコピーできます。

それでデータの変換時間ですが、今回時間のかかるのはインデックスの再構築とプライマリキーの生成です。

インデックスは100万件オーダーのテーブルに相当の数のフィールドに設定してますが、１時間はかかりません。

プライマリキーデータの生成はインデックスより少し時間がかかりましたが１時間強です。

バックアップ時間は30分弱だったのが、10分弱に短縮されました。

クライアントからの使用感は連休明けのお楽しみになりますが、バックアップ・リカバリーの時間が短縮できることはシステムメンテナンスの面から非常にメリットが大きいと思います。

プログラム的には常時メンテナンスしていることもあって大きな修正はありませんでした。

ホッとして連休を迎えています（仕事はしてるけど、）。

皆さん4Dシステムのバージョンアップはお済みですか？
最近は遠方からのバージョンアップのご依頼が増えています。
残念なことにもともと開発された方がバージョンアップを引き受けられない事情があるようです。
私どもではそのようなシステムのバージョンアップもありがたく引き受けさせていただいております。
そんなバージョンアップではバージョンアップと同時に次のような作業も行います。
１）深刻なバグの修正。
２）極力プラグインへの依存をやめる。または4D社提供のものに移行する。
３）シンタックスエラーを０にする。

せっかくお金をかけてバージョンアップするのだから今まで通りではなくちょっと前より良くなったね！と言っていただきたい。
サードパーティーのプラグインに依存しているとバージョンアップの度に神経を使うことになります。
またプログラムが複雑であったりするケースがあるので、なるべくシステムをシンプルにしたいと思います。
最終的に安定した動作を目指すわけですから、シンタックスエラーはやっぱりゼロにします。
もっとも多いエラーは変数のタイプエラーのように感じます。
一つの変数を複数のタイプで使いまわしてしまっていることがあります。
私も最近まで間違っていたのですが、配列タイプのリストBOXとセレクションタイプのリストBOXはタイプが違うのですね。

さて稼働させてからも埋もれていたバグが発生することもあります。
私どもでは納品後システムを稼働してから６ヶ月間は無償で保守サポートいたします。
その後は年間保守またはスポット保守にて継続してシステムのサポートさせていただきます。

先日お客様のサーバーをMacOS High Sierra(10.13)にアップデートしました。
OSをアップデートするとカスタマイズした内容がリセットされたりするので、設定をやり直す部分があります。
それは毎度のことなのですが、macos Serverアプリに「ファイル共有」のタブがなくなっていました。
もともとある環境設定のファイル共有に分離（統合？）されたようです。
それで、Windowsクライアントに対する権限の設定がどこからやり直せばいいのかわからなくなりました。
これを行わないとWindowsからアップされたファイルの所有者以外の権限が消えてしまう（フォルダーの権限が継承されない）のです。
Appleのサポートに問い合わせたり、あちこちググってもなかなかわかりませんでした。
しかし２日目にしてやっと見つけました（ほっ）。
最初はconfファイルをいじるのか、ターミナルからコマンド使うのかと思い探していましたが、なんとGUIからできました。
macos Serverアプリでサーバーを選んでストレージタブでフォルダーに対してアクセス権限を詳細に設定できる事がわかりました。
ここでeveryoneを追加して読取権限を与えるとアップしたファイルがフォルダーの権限を継承して作成されました。
めでたしめでたし。

4Dv16のリリースとともに迷わずv16にアップグレードしたお客様のシステムは２ヶ月以上になりました。
v15よりさらに安定しています。先日はMacOSをSierraにアップグレードしOSと4Dともに最新版で稼働しています。
今までは新しいバージョンがリリースされても「様子見」が基本でした。でもこのところの4DはRリリースのこともあってかリリース時の完成度が高いかもしれません。

iPhoneと4DWebサーバーの連携した出荷３点照合システムを開発中です。

私どものお客様の中で最初の4Dv15が稼働を始めました。4Dv11からのバージョンアプです。
少し前にサーバーが故障し、慌ててサーバーを新しいものに切り替えました。しかし新しいＯＳ上では4Dv11は動きません。そこで仮想環境で旧ＯＳを動かしてその上で既存の4Dv11によるシステムを稼働させていました。なんとか稼働させることはできましたが、どうも仮想環境が完璧ではないのか徐々にシステムが不安定になり再起動を繰り返さなければなりませんでした。もう直ぐにでも4Dのバージョンを上げるしかない、そう思いました。早速バージョンアップと動作テストを始めました。そして2016/1/15に4Dv15.1のシステムに切り替えを行いました。特に大きな問題はなくスムーズに切り替えを終えました。その後細部の調整が多少ありましたが非常に快適に稼働しています。
こちらのお客様のシステムは4D2003でスタートして、今年で１３年目になります。スペックを少しご紹介します。DBのサイズは約５GB、商品点数3.5万、受注件数200万件（12年）
現在はもう一台のサーバーの切り替え準備中です。Webオーダーシステムの4DWebのフロントにApacheが稼働していてProxyPassで動的ページを4Dへパスするようになっています。この部分が新しいＯＳで仕様が変わっているので調査・テスト中です。ちなみに新しいサーバーはCore i7、16GBメモリ、SSDのストレージを２台内蔵したMacMiniです。古いサーバーはXServeだったのでものすごい省スペースになります。Miniでも4Dv15と合わせてパフォーマンスは相当上がりました。
何よりもお客様のシステム環境が快適（安定）になってホッとしています。

2015/9/19のお（ドガ）客様との打ち合わせでのお話です。
こちらのお客様は4Dで基幹システムとWebオーダーシステムを稼働してから１０年になります。
今更ですが、お客様に4DWebの優位性についてお話しました。
4Dは基幹システムとWebサーバーが一体化していますから、Webのお客様に本当にリアルな在庫情報を提示できています。
ドガさん：「そうなんですよ、ドガさんの在庫はすごい正確だねってよくお客様から言われます。」
注文したけど在庫が無かった、そんなのは論外です。最後の最後の１本、１個、１パックまで余さず売ることができる買うことができるシステムです。
「昔は台帳に手書きでよくやってたなあ。繁盛期には１日１本ボールペンが無くなってたからね。」
「4Dで良かった、をもっと増やしていきたいですね！」と再確認した１日でした。

先日起こったお客様のトラブルのことです。
「エラーが出て更新処理ができない？」という連絡をいただきました。早速最新データを弊社のサーバーにアップしていただき、こちらでも試してみました。しかしどうしても現象を再現することができません。原因を特定するためにプログラムを追加してなんとかエラーの出るタイミングを捉えようとあれこれやってみるも結果は得られず。結局現地対応が必要ということになりました。現地でこそできるのはエラーが起こった場合のデータの状態を直接確認できることです。そして処理の先頭のデータを保存するときに重複エラーが起こっていることがわかりました。しかし論理的には重複エラーは起こり得ないロジックになっています。では一体なぜエラーが起こるのか？ある程度現象を確認することができたのでこれからは4D社のサポートの力を借ります。サポートに電話して現象を細かく説明しました。するとすぐにある原因が浮かび上がりました。それは「データのゴミ？」。データにゴミが混入している可能性があるのではないかということです？そのゴミによってデータの重複チェックが正しく行われずに本当は重複していないはずだけど重複と評価されてしまう。ということです。そこで緊急の対処として若干データベースのレスポンスが落ちるものの問題のフィールドに設定されている「インデックスを外す」ことにしました。すると重複エラーは起こらないで処理を完了することができました。ひとまずこの状態で使っていただき、おそらく探すのに時間のかかる「原因のゴミ処理」は持ち帰ることにしました。

先日の4D講習でのことです。
4DWebについて少し説明をしました。
何より驚かれたのは、4DWebサーバーがサーバー機でなくても稼働するということでした。
4Dはデータベースを基盤にWebサーバー機能も搭載しています。
極端に言うと、「余っているPC上にスタンドアロンのWebシステムを稼働できる。」ということです。
そして無制限のユーザーに対してサービスすることができるのです。
もちろんヘビーなシステムにはそれなりのリソース（特にメモリ）が必要になってきます。
しかし、4Dはまさしく「小さく初めて大きく育てる」アプローチを可能にします。

お客様からこんなお問い合わせがありました。
「間違ってデータを一括更新してしまった、なんとか元に戻す方法はありませんか？」
デザインモードでのオペレーションミスによるデータ更新に対して保護策は取られていません。
あとはバックアップデータをたよりにリカバリするしかない！
「バックアップデータからなんとかなると思います。」お客様、「どうすればいいですか？」
データベースと別のドライブに4DBackUpというフォルダがあります。そこに５世代くらいのバックアップファイルがあるので確認してください。
お客様：「今朝の２：００のデータがあります。」
「それです。一対になっているとおもいますが、そのうちサイズの大きい４ＢＫという拡張子のファイルがありますね？」
「それをMOON（もう一台の別サーバー）にコピーして下さい。」
「そしてMOONにも４Ｄがあるので、４Ｄを起動してファイルメニューの復元を実行し今コピーしたバックアップファイルを開いてください。」
「するとフォルダに解凍されたデータベースのファイルができますので、それを４Ｄで開くことになります。」
お客様：「解りました、そこまでやってみて解らないときはまた電話します。」
しばらくするとお客様から：「今データを取出して修正データができました。インデックス作成に時間がかかりましたね。」
数百万件を超えるテーブルがいくつかあるので、バックアップファイルを開いた時にインデックス作成で時間がかかります。
お客様はすでに本番環境のデータを取出してEXCELで開き、そこにバックアップデータから間違えて更新してしまったデータをコピペで修復されていました。
お客様：「これをどうやってかぶしたらいいでしょうか？」
「本番環境のデータを全て削除したのちに修正データを取込めばいいですね。まずEXCELからタブ区切りテキストでデータを保存して下さい。」
「それをデータ読み込みで開きます。開いたらテーブルを選択して下さい。」
「全ての項目が一つ一つのフィールドに割当っているか確認してください。」
「あっ！ちょっとまってください。登録日が全部今日になってしまうので、リモートでトリガの設定を一時コメントアウトします。」
「はい、どうぞ取込んで下さい！」
お客様：「できました。」
今回の問題のデータは約６千件程でした。１件づつ修正なんてとても無理です。
バックアップデータからコピペで修復出来て助かりました。
「では在庫照会から数点確認してみてください。大丈夫だと思います。」
お客様：「はい、なにかあったら連絡します。ありがとうございました。」
１時間半たらずでなんとか無事リカバリできました。

さて今回特にプログラムの作成等の作業は必要としませんでした。
しかもコンピュータには素人のユーザー様が実作業のほとんどを行ないました。
これが他のプラットフォーム（オフコンや他のデータベースシステム）では可能だったでしょうか？
４Ｄの一つの重要な特徴として「運用コスト」が非常に少なくて済むということが上げられると思います。
日々大量のトランザクションを処理する基幹システムでありながら運用のための専任要員を必要としません。
ちなみにこちらのお客様のシステムは４Ｄでシステムを構築してから１０年以上になりますが、大きなトラブルは無く安定稼働を続けています。
来年の１月以降に最新のバージョンv14にバージョンアップし、さらに安心して稼働出来るようシステムリファインを予定しています。

ODBCを使って他のデータベースとデータの送受信を行っている場合があると思います。
4Dには今までODBC Pro等のODBCを利用する為のプラグインがありました。しかし最新のバージョンでは4Dに内蔵されたSQLの機能を使うのが標準です。互換性やバージョンアップ時の開発負荷軽減のために一時的にプラグインで対応することはあっても、今後ODBCプラグインは使うべきではありません。つまりいずれサポートされなくなります。バージョンアップの際にはSQLのプログラムに置き換えることをお勧めします。

最近バージョンアップしたシステムでこんなことがありました。4D6.8 -> v13
どういったシステムかというと、データベースパブリッシングと読んでおります。某フォークリフトのメンテナンスマニュアルをデータを元に印刷（版下作成）しています。
各国後に対応したパターンが存在しており、今回はドイツ語向けのデータ（フィールド）が問題になりました。一旦データを変換するとドイツ語のデータは正しく変換されず「ウムラウト？」の表示がなくなってまったく違う文字になってしまいました。
4Dはv11以降はユニコードで動いています。変換の際にはデータをユニコードに変換しています。その変換処理がうまくいっていないということです。
このような場合には、フィールド単位にキーボードレイアウトを指定する必要があるということです。ストラクチャと同じ階層に「multilang.txt」というファイルを置いて指定します（データ変換前に）。詳しくはアップグレードリファレンスを参照してください。
参考：「4D v11 SQL アップグレードリファレンス」の24ページにある「キーボードレイアウトを指定したデータベースの変換」

先日私どものお客様ではじめて4D Server 64bitの運用を開始されました。切替後数週間経ちますが、まったく問題なく稼働しています。4Dに使われたメモリの数字を見ると最大で５ＧＢ程まで使われていました。32bitの時は２ＧＢちょっとまでしか使えませんでしたので、現在はメモリ資源を有効に使ってパフォーマンスの向上がなされています。
64bit版で稼働するために行ったのは、サーバーサイドで実行される処理の見直し（64bit対応）を行い、32bitのプラグインを使っているものを変更したり、サーバーではなくクライアント側で実行するように変更したりといった対応を行いました。ちなみにサーバーサイドでは定期的に自動的に外部データの入出力を行っています。注意したのはテキストデータのコード変換に使っているコマンド（以前は4D Japan Packを使用）や64bitになったInternetCommandを使ったメール受信処理等です。
残念ながら初回の切替は断念しました。なぜかというと、バージョンアップと同時に導入したFaxサーバーシステムに使う為のPDF Creatorの出力がまっくろになってしまったからです。PDF Creatorのバージョンを変えてみたり色々と試しましたが、解決しませんでした。やむなく32bit版で一旦稼働して、原因追及とテストを繰り返しました。そしてなんとか原因を突き止めました。なんとフォームの極細線がうまくPDFに変換されないようです。線の幅情報が伝わらないのか？ふと〜くなって真っ黒になっているようです。32bit版では問題ないことから4Dの64bit版に問題があるのでは？と想像します。そこで、フォームのデザインを変えることについてユーザーの了承を得て、線の太さを１ポイントに変更しました。根本解決ではありませんが、現在はこれで稼働しています。

図では4Dが使っているメモリは3.32GBですが、稼働している間に5GB超になります（Windows Server は週に１回再起動しています）。
メモリは16GB実装し、CPUはXeonで4コア、8スレッドになります。以前はメンテナンス中に負荷の高い処理が走るとメソッドエディタがフリーズしたように反応しない時がありましたが、今はまったくそのようなことはなくなりました。

4Dの開発の中で起きたことや、関連することについて気ままに？綴っていきます。