コンピュータユニオンはソフトウエア技術者の派遣を行っています。
技術者の中には新しい職場で就労したけれど長続きしない人、次の契約更新ができない人が少なからずいます。そんな人たちにアドバイスできる事がないか、 組合員と改めて考えて見ました。
次のような人「一緒に仕事をしたい人かどうか」という意見、感想が出ました。
IT現場で数十年間仕事をしてきた組合員の皆さんからの意見・感想でした。御参考まで。
LANケーブルプラグの爪が折れる事って意外とあります。その爪の状態を放置してパソコンに接続したままだと思わぬ不具合につながってしまいますね。これまでは床に埋設したLANケーブルを交換する事で対応するのですが、その作業は 机を移動したり埃を掃除したり、正直大変です。
無線LAN環境のフロアで仕事をしている人には関係ない話ですが、通信速度を確保するならやっぱり有線 が一番と考えてしまう人間としては有線LAN環境一択です。今回はそんなプラグが折れてしまったら悩みの解決策としてLANケーブルプラグの補修ツールを試してみたので紹介します。
[試した画像]
これで引っ張っても抜けなくなりました。
もう床をはがしてLANケーブルを敷きなおさなくても大丈夫です！
以上
ＩＴ資産にかけるコストを少なくするようになってきている為でしょうか。
OracleからオープンソースのPostgreSQLに変えたいというニーズは昔からあるものの、最近は以前に比べ急増してきているように感じます。
Oracleのソフトウェア費用が高いことに加え、仮想化環境におけるライセンスの考え方により、必要以上に費用が掛かってしまうことが理由とされています。
ところがPostgreSQLに変えたくとも、変えられない場合が多く見受けられます。
PostgreSQLへの移行に関する問題点をいくつか列挙しますので、PostgreSQLへの移行を検討する際の一助となればと思います。
(1) SQL
アプリケーションにて自前のSQL文を使用している場合、Oracle固有のSQL文があった場合、SQL文の修正または新規のSQL文の作成が必要になります。
SQL文の修正または新規のSQL文の作成が多いほど、PostgreSQLへの移行は困難になります。
アプリケーションにおけるすべてのSQL文が対象となるため、対象の把握が困難な場合があります。プログラムで動的にSQLを生成している場合は特に注意が必要です。
(2) ストアドプロシージャ
OracleとPostgreSQLでは、構文、エラーハンドリング、トランザクションの管理などが大きく違うため、大規模な修正や新規ストアドプロシージャの作成が必要になることが度々発生します。
アプリケーションがストアドプロシージャに多く依存している場合は、PostgreSQLへの移行へのハードルが極めて高くなります。
なお、ストアドプロシージャの修正の難易度や修正に要する工数は、ora2pgというプログラムにてある程度は確認できます。
(3) データベース構成
大規模データベースでは、性能や耐障害性を考慮して、Oracle RAC構成を採用しているケースが多いかと思います。
PostgreSQLに移行する場合、どんなクラスタ構成を採用しても、更新処理ができるノードが１つしか存在しない点に留意するがあります。（Oracle RACではどのノードでも更新処理が可能）
また、更新結果が更新ログの転送により他のノードに伝播されるため、タイムラグが発生することにより、別のトランザクションで更新結果が反映されていないデータを読み取ってしまうリスクもあります。
更新処理が多い場合はネックとなるかもしれません。
(4) データベース運用
データベース監視や運用については、Oracleの考え方がほぼ援用できませんし、データディクショナリも全く違うので、運用設計からやり直しとなります。
自前のスクリプトで情報採取を行い監視していた場合ですと、すべて新規作成となります。
(5) コスト
今後のOracleソフトウェア費用よりも、PostgreSQLのソフトウェア費用にPostgreSQLへの移行費用を加えた金額が小さくなることを見込んで、PostgreSQLへの移行を検討するものと思います。
(PostgreSQLへの移行費用は、コンサルティング費用、データ移行とアプリケーションの改修の合計とします)
多くの場合、アプリケーションの改修費用がかさみ、PostgreSQLへの移行費用が大きくなりがちです。
ソフトウェア費用を節約するため、サポート契約なしで素のPostgreSQLを利用することを考えるかもしれませんが、バグデータベースへのアクセスやPostgreSQLのノウハウの提供がサポート契約により得られることを考えると、ある程度の規模以上の企業ではサポート契約なしにPostgreSQLを使用することは必須ではないでしょうか。
そのため、ソフトウェアの利用期間などを考慮すると、Oracleのままでも問題ない、多額のコストをかけてPostgreSQLに移行する利点はないと判断するケースもあります。
以上
table 全件update -> tableのselect権限は不要
table 条件付きupdate -> tableのselect権限が必要
updateやdeleteの対象となる特定の行や列を指定するには、そのテーブルのselect権限が必要になります。select権限がないユーザが、table条件付きupdateを行うと、例えば“権限不足でエラー”になります。
個人的な思い込みで、レコードのupdateができるのであれば、当然select権限が付与されているだろう、update権限を付与すると自動的にselect権限の付与が補完されるだろうぐらいの認識がありました。
[以下が注意したい例]
① oracleの"SQL92_SECURITY"パラメータをfalse ー＞ True に変更した時。 select権限を付与していないテーブルのupdateがエラーになる。
② プログラムで動的にＳＱＬ文を作成している時、where句がある場合はselect権限が必要になる事に注意。select権限のないテーブルのupdateは、where句が無いときは成功しますが、where句がある時に失敗します。
以上
■複合機側でグレースケール印刷を標準設定しているのに、ACCESSでレポート印刷する際、初期設定のカラー印刷に戻っている。そのたびに設定操作が面倒だ。
[ACCESS VBAによる指定方法]
該当レポートのページフォーマットイベントに以下のコードを追加。
Private Sub Report_Page()
Me.Printer.ColorMode = acPRCMMonochrome
End Sub
[説明]
最近はカラーインクの経費削減で、黒インクのみの印刷が多くなりました。複合機ドライバーのプロパティ設定でグレースケール印刷を標準設定にしています。Word文書、Excel文書等の印刷では、グレースケール印刷出来ていますが、ACCESSのレポート印刷では、カラー印刷になってしまいます。ACCESSでは、なぜか複合機の標準設定は反映されないようです。そこで、上記のようなコードを追加すると、グレースケール印刷のコントロールができるようになりました。
以上、ご参考まで。
はじめに
Windows2008R2サーバー、Windows7の2020年1月サポート終了に伴い、自社サーバーのOSアップグレードを検討していたのですが、せっかくなので、Microsoft Azureへの移行を検討してみました。要件としては、現行のC/SシステムにおけるSQLSERVERとAccessクライアントの処理が、 Cloud上のSQLSEREVER – VPN接続 – Accessクライアントで実現できる事、です。 これが出来れば、インターネット経由で自宅パソコンやモバイル端末から接続して仕事ができるので便利です。
Azure移行イメージ
目次
１．無料アカウントを作り、仮想サーバー(Windows2016+SQLSERVER)を構築
２．仮想サーバーでVPN接続設定
３．仮想サーバー内SQLSERVERの外部接続設定
４．クライアントのSSMSで仮想サーバーSQLSERVERの接続確認
５．Access.accdb用のODBC設定
１．無料アカウントを作り、仮想サーバー(Windows2016+SQLSERVER)を構築
自分のようなお試しユーザ向けのAzure無料アカウントを作り、Azureポータルにログイン。
ポータル画面は、直観的に何となくクリックして進めていく事ができます。
よくわからない設定があっても、その都度リンクされたヘルプサイトを見て確認する事ができました。 自分は、仮想サーバーの構築をMicrosoftのDocサイトを参考にしました。
クイックスタート:Azure ポータルでWindows仮想マシンを作成する（Microsoft.comに移動）
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/quick-create-portal
作成後、RDP接続で仮想サーバーに接続。まず、作成直後の仮想サーバーは英語なので、サーバーの日本語化設定をして、 その後、仮想サーバーのブラウザを使ってSQLSERVER2016及び管理ソフト(SSMS)をインストールしました。
２．仮想サーバーでVPN接続設定
仮想サーバーと自宅のパソコンを接続する形態をAzureでは「ポイント対サイトVPN接続」と呼ぶらしい。 設定は、
ネイティブAzure 証明書認証を使用したVNetへのポイント対サイト接続の構成:Azureポータル（Microsoft.comに移動）
【ネットワークトラフィック許可の設定】
受信ポートの追加設定は特になし。仮想ネットワークに接続している事が前提になるので、この設定で問題なし。
パソコンで上記のサイトの説明に従ってVPN構成設定を行い、接続確認。
３．仮想サーバー内SQLSERVERの外部接続設定
仮想サーバーのFireWallで、1433のポートを受信許可。セキュリティが心配なら、ローカルIPアドレス、リモートIPアドレス、 プロファイル指定も行います。
[START]-[セキュリティが強化されたWindowsファイヤーウォール]-[受信の規則]-[新しい規則]
Sql Server Configuration Manager(構成管理)で、以下の設定を行います。
[SQL Serverネットワークの構成]-[SQLEXPRESSのプロトコル]-[TCP/IP]-[プロパティ]
IPALLの設定で、TCPポートに1433を設定します。
４．クライアントのSSMSで仮想サーバーSQLSERVERの接続確認
ここで接続確認できれば、ODBC接続も問題なしです。
４．Access.accdb用のODBC設定
最後にACCESSからSQLSERVERのテーブルをリンク接続する為に必要なODBC接続の設定を行います。
ファイルDSNの設定例
[ODBC]
DRIVER=SQL Server Native Client 11.0
UID=SQLSERVERログインユーザID
WSID=DESKTOP-XXXXXXX
APP=Microsoft Office 2013
SERVER=192.168.1.4,1433
おわりに
とりあえず、VPN接続して動作確認はできました。サーバ―レスポンスも思ったより早いです。
処理にもよるのでしょうが、今後は5G通信も始まるのでレスポンスについては問題にならないと思いました。セキュリティ面は、レンタルサーバーを借りて設定するよりも、はるかに堅牢なシステム構築が簡単に出来そうです。
さて、気になる利用料金ですが、Azure 料金計算ツール
https://azure.microsoft.com/ja-jp/pricing/calculator/
でシミュレーションができます。試しに計算してみると・・・・・・・
うーん、小規模システムで運用するにはちょっと掛かりすぎの利用料金でした・・・・・。費用対効果として「効果」の部分を積極的に考えていかないと割に合いません。結局自社サーバー（オンプレミス）に落ち着きそうです。
ドメイン名にアンダースコアが含まれていると、ブラウザからサーバリクエストをした際に、ドメイン宛てのCookieの送信がブロックされてしまう。
参照：[PRB] Internet Explorer セキュリティ修正プログラム MS01-055 のインストール後、セッション変数が要求間で保持されない
以上はInternet Explorerにおける振る舞いですが、RFC952の仕様ではホスト名の命名規則にアンダースコアは 含まれていないので、使ってはだめでした。
今回はテスト環境でハマったのですが（そもそもテスト環境でしか起こりえない。本番では正式なドメイン名になるので）、テスト環境だからとりあえず「何でもいいや」という気持ちで、分かりやすくしたいからアンダースコアを含めたドメイン名を設定しました。よくプログラムのコーディングで、変数名にアンダースコアを使うのでそんな延長で気軽に付けてしまったが為に、半日悩んでしまいました。
また、例えば"localhost"、"testserver" 等、セカンドレベルドメイン(.coとか)、トップレベルドメイン(.jpとか)が無かったり、いわゆるFQDN形式に沿っていないと、やはりcookie送信がブロックされてしまいました。(Internet Explorer調べ)
架空であってもそれらしい名前を設定しておく事ですね。
確か過去にも同じ痛い目にあったはずなのに・・・。戒めを込めて記録しておきます。
はじめに
ある入力画面フォームで登録ボタンを用意、クリックイベントの処理（イベントプロシージャ）でデータベースに登録する処理を割り当てました。運用になってからしばらくは順調に動作していましたが、複数の担当者の内、ある人が操作した時に、データが２重登録されるケースが出現。
原因について
どうやら、その担当者は登録ボタンをダブルクリックしていて、クリックイベント処理が２回走ってしまったことが原因らしい。
改めてACCESSのヘルプを見直すと、
Form.DblClick イベント (Access)
https://msdn.microsoft.com/ja-jp/vba/access-vba/articles/form-dblclick-event-access
■マウス イベントを受け取るオブジェクトに対しては、次の順序でイベントが発生。
MouseDown ⇒ MouseUp ⇒ Click ⇒ DblClick ⇒ MouseUp
■コマンド ボタンをダブルクリックすると、次の順序でイベントが発生。
MouseDown ⇒ MouseUp ⇒ Click ⇒ DblClick ⇒ MouseUp ⇒ Click
との事。
今回のケースは、コマンドボタンをDblClickした場合なので、Clickイベントが２回発生した。
そもそも、DblClickの時にClickイベントが発生する事など、全く考えていなかったので、この仕様には驚いています。ただ、今回の事を知って改めて考えると、パソコンの設定によってDblClickとClickの判断は難しい場合があるのだと思えば、なんとなく納得しています。
対応方法
２回目のClickイベントを無効にする次の方法で対応します。
DblClickイベントプロシージャの引数に「Cancel」があるので、この引数にtrueを設定して終了すれば、以降のClickイベントは発生しません。
例)
Private sub XXXボタン_DblClick(Cancel As Integer)
Cancel = true
End sub
おわりに
入力画面を設計する際、ＧＵＩの観点からなるべく入力を簡単にできるよう考えます。
例えば、テキストボックスをダブルクリックするとデフォルトの値が設定されるようにするとか。
結果として、クリック操作とダブルクリック操作が混在する画面の操作性の良し悪しは、
判断が分かれるところですが、今回のようなケースでうっかり操作による誤動作の対応はしておきましょう。
なお、Accessのヘルプには、
”一般的には、コマンドボタンをダブルクリックしない事をお勧めします”
とありました。