SE?のお仕事 論考

#SE 今回、Accessの"Dsum関数"を初めて使った。 先にリンクテーブルを張りなおした！、という案件での事。 明細項目に商品毎の金額があるのだが、その合計をフォームで表示してほしい、というものだった。 最初は明細用のサブフォーム内で、明細レコードに金額を合計したレコードをUnionで一緒に表示しようかと考えていたんだけれど、明細サブフォームのレコード数表示は明細件数を確認するから、そこに影響する方法はダメとなったので代替手段をとった。 これまでならユーザー定義関数を書いて、その中でDAOでSQLを書いて帰ってきた値をテキストボックスに与える、という方法をとっていたんだけど、まあ、他にも方法はないかな？という事で勉強感覚でMSの関数リファレンスを眺めてたら、上記の"Dsum関数"を見つけた、というわけ。 書式 ：DSum( フィールド名, テーブル名若しくはクエリー名, 条件 ) 戻り値：指定したレコードのセット (定義域) に含まれる値の合計 "条件"はSQL文でのWhere句。ただし"Where"は含まない 要は、既にACCESSで定義済みのテーブルやクエリーに規定されてるフィールドの合計値をもとめる、ということ。一応条件付けも出来る。 確かにお手軽やね。 今回は、特段条件づけは必要が無かったので簡単に済ますことが出来た。 この関数は既に存在するリソースをそのまま使える場合には都合がいい。 ただ、この目的のためだけに新たなクエリーを規定する必要があるのだとしたら、それはやめて、ユーザー関数でSQLを書いた方がいいと思う。

なんてことはない、備忘みたいなもの。 会社がモバイルPCで仕事できるように、とVPNで社内ネットワークに接続するサービスを提供している。 会社の表向きの説明では、ファイルサーバへの接続だったり、Notes（モバイルPCでは不可）の利用のため、という説明。だから普通の従業員はモバイルにオフィスソフトをいれ、Notesをいれ、社外用のメーラー（Notesは社内専用）をいれてそれをモバイルPCで稼動させている。 しかもこの仕組み、出来が悪くて、VPN接続時には社外専用のメーラでメールを送受信できない。だから社内メールを使うときはVPN接続してローカルのノーツを利用し、社外とやり取りが必要な場合には、いったんVPNを切って、社外用メーラーでやり取りする、というなんとも面倒な仕組み。一応PVNで入らずとも社内メールのやり取りを出来るように、とCACHATTOを使えるようにしてあるが、CACHATTOはアドレス帳が使いづらいうえ、その他のNotesアプリのほとんどが使えない。 よくあるのが、メールにNotesの文書リンクを張ってある事が非常に多いのだが、肝心のリンク先が読めないケースがほとんど。 まあ、家のインフラは従業員の事をどれほどまじめに考えているのか？自分たちがほとんど使うことがないから、こんな中途半端な仕組みで『ちゃんと仕事してます』と知らん連中にアピールしてるんだな。知らん連中は『セキュリティ』という単語で怖気づくからな。でもその実情は穴だらけだ。 それは置いておいて。 で、VPNでアクセスしたとき、社内ネットワークのほぼすべてのリソースにアクセスできる。こんなことをしてみた。 オフィスのデスクトップPCをリモート接続可能な設定にして、それをVPN経由でモバイル経由でログオンする、というもの。 あまり社外に出ることも無く、休みの日に家で仕事する意思もないが、それでも出張先で『あ、あのファイルPCの中だ』というケースはたまにある。そんなとき用に。 オフィスPC 一応よりセキュリティの高いアカウント設定にして、ユーザーも自分以外は接続できないようにしてある。 で、モバイルからはこうやって接続するのね。 後はモバイルのデスクトップにでも設定ファイルを保存しておけばO...

先の投稿で『拾い出しシステム』の明細情報を読むために、リンクテーブルを都度張りなおす、という方法について書いた。 今日はその関連で起きた事を書き留めておく。 物件管理番号はメインフォームで指示され、その指示された物件管理番号の明細レコードをサブフォームで表示する、という構造だ。そこで物件管理番号が変わったら、リンクテーブルを張りなおす、という処理を行ったわけ。 最初の内はそれだけでなんら問題なかった。 サブフォームの項目のコントロールソースはリンクテーブルのデータ項目に設定していて、リンクテーブルを張りなおしした後、サブフォームをリクエリーするだけでうまく表示内容が切り替わった。 ただここからが問題だった。 明細レコードには品目コードがある。品目のコードは規格コードと色コードの組み合わせで構成されていて、『拾い出しシステム』ではこの二つは分離して管理されている。 一方基幹システムの品目コードは規格コード+色コード。つまりこのままでは基幹システムに突っ込めない。 そこでサブフォームのレコードソースをクエリーに変更して、基幹システム用の品目コードを演算（規格コード+色コード）するように変更した。 そうしたら、” #NAME?”です。非演算項目は問題なく表示されるんだけれど、演算項目はだめ。メインフォームを開いた一発目はちゃんと演算項目も表示するんだけど、管理ナンバーの変更を行うと演算項目は表示できない。 結局、どう落ち着けたのか？というと、リンクテーブルを更新した後、サブフォームのソースオブジェクトを再定義する方法で安定した。 "sub_meisai"というサブフォーム用のフォーム定義があり、メインフォームでこれまた”sub_meisai”というサブフォームが定義されている。 サブフォーム”sub_meisai”のソースオブジェクトをフォーム”sub_meisai”に定義しなおしている。 =========================================== Me.sub_meisai.SourceObject = "sub_meisai" ===========================================

今回の事案は初めてのケースだった。 ある事業で、顧客に対してある種の設計サービスを行っている。 住宅関連なのだが、ハウスメーカーが、こういう設計の住宅、といった図面をよこしてきて、その図面からうちの商材をパーツごとに必要な数を拾い出しして見積もりを行い、販売する、というものだ。 住宅、という事でまあ『物件』と称され、上記のサービスを実現しているのが『物件拾い出しシステム』と呼ばれている。 で、この『物件拾い出しシステム』、全物件のヘッダー情報はファイルサーバー上の.mdbファイルに保管されているのだが、どの商材をいくつ、あの商材をいくつ、という『拾い出し』した結果の明細情報が、物件の管理ナンバーをファイル名とした別の.mdbファイルに格納されている、という構造なんだ。 今回受けたオーダーは、この『物件拾い出しシステム』の情報を使って、SAPScriptで受注伝票を突っ込む、というもの。開発プラットフォームはAccess。 で、タイトルのとおりの事をしないといけない破目になった。 各物件別の明細情報はファイル名以外はテーブル構造やテーブル名は共通。ファイル名は先に書いたとおり物件管理番号で、配置されるディレクトリもルールで決まっている。 そこで、ヘッダーファイルから管理番号を選択すると、明細情報を呼び出すためにリンクテーブルの接続先ファイルを各明細別mdbファイルに切り替える、という処理をした。 具体的にはこう。 =========================================== Const conmyDbPath = "\\サーバー名\物件データ" '明細ファイルへのパス生成文字列 Const conmyTbName = "T_拾い数量合算"          '明細情報へのリンクテーブル Dim dbsSys   As DAO.Database 'データベースオブジェクト Dim myDb As DAO.Database '明細用データベース Dim meisaiTb As DAO.TableDef 'テーブル（T_拾い数量合算） Dim pKanriNo As String '物件管理ナンバー pKa...