SE?のお仕事 論考

はじめに、と後から、というくらいの違いは知ってはいるけど。 改めてどう違うのか？を調べてみた。 書式の違いはこう（VBA） ・アーリーバインディングの例 Dim myApp as Excel.Application Set myApp = Application ・レイトバインディングの例 Dim myApp as Object Set myApp = Application もう一例 Dim myApp as Object Set myApp = CreateObject("Excel.Application") まあ、CreateObjectで書く事が多いよね。 でも、やっぱりアーリーバインディングで書く事には相応の違いがあるそうな。 一つは、たとえばメソッドの存在チェック。 アーリーバインディングでは、"myApp"内に当該メソッドが存在するかはコンパイル時にチェックされる。 一方レイトバインディングではプログラムが実際に実行されるまではチェックがされない。 つまり、動かしてみないと判らない、という事。 開発やテストの事を考えるとアーリーバインディングのほうがやっぱりいいんだろう。

前にAccessの Dsum 関数について書いた。 それと同類の、Dfirst 関数を今回使った。 Dfirst はレコードセットの最初のレコードの値を取る、というもの。 基本的な記述方法は Dsum も Dfirst も同じ。 関数名（"項目名", "テーブル名 or クエリー名", "条件式"） ※条件式は省略可 で、今回なんでわざわざ書いたか？というと、前回 Dsum では使用しなかった条件式を与えたから。これはちょっとメモっておきたかったので。 今回 Dfirst をこういう風につかった。 フォームのテキストボックスオブジェクトのコントロールソースに以下を既定 =DFirst("顧客CD","M_顧客マスタ","受注先CD= [p_jyutyusaki_cd] ") 内容としては、同一フォームにある「p_jyutyusaki_cd」というオブジェクトの値を”受注先CD”という、"M_顧客マスタ"テーブルのフィールドのセレクト条件にして、これまた同テーブルに既定されている”顧客CD”の最初の値を返す。 言ってしまえばこれだけなのだが、この『テキストボックスオブジェクトのコントロールソース』として書く際のパラメータ指定の書き方がMSのリファレンスにもあんまり書いてない。 結論から言えば、"受注先CD= [p_jyutyusaki_cd] "という標記になるのだが、最初はVBAでSQL文字列を書くようにテキストの変数をシングルクォートとアンパサントで囲うのか？とかいろいろ書いてみたのだが、通らない。関数の実行結果がエラーになるんだよね。 で、幾度か書き方を変えて試してたどり着いたのが"受注先CD= [p_jyutyusaki_cd] "という書き方でやっとエラーなく通った。 ただし、ここで書いている方法はあくまで、”オブジェクトのコントロールソース”として書くときに、同一フォーム上のオブジェクト値をパラメータにする、という限定された条件である事は改めて記しておく。 これをVBAで書くときなどは多分別の書き方になるはずだ。

今回のお題は、ディレクトリの特定の仕方について。 Accessで処理するファイルを、ある場所、具体的にはユーザープロファイルの”ダウンロード”フォルダからアプリのディレクトリに移動したい。 ただ、”ダウンロード”フォルダはログインしているユーザーによって絶対パスが変わってくる。それをどうするか？ 今回の場合、ユーザーのリテラシーがそれほど高くなく、ネットからダウンロードされたファイルを、ユーザー自身がファイル選択ダイアログから選んで指示するのは避ける、という判断となった。 一応、ネットからダウンロードされるファイルの保存先はユーザー別の”ダウンロード”フォルダ、という事は保障される前提。 ダウンロードされるファイル名は名前付けルールにそって、識別子のお尻にタイムスタンプが付く。 ただ、Access側での処理のタイミングの問題で、同時に複数のダウンロードファイルを処理するケースも想定された。 個人的には、バッチファイルを同期でアクセスから実行して…、で良いんじゃない？と思った。 それなら環境変数でユーザープロファイルのパスが取れるから。 でも他からの判断でアクセス内で完結させる方法をとる事となった。 で、結局はWSHの ExpandEnvironmentStrings メソッドを使う事にした。 このメソッドは環境変数（%XXXX%）文字列をあたえるとそれの展開結果を返してくれる。 なんで、ExpandEnvironmentStrings（"%userprofile%"）とすると、ログインユーザーのユーザープロファイルパスが帰ってくる。 なお、これをAccessで使うには参照設定として「Windows Script Host Object Model」 を追加しないといけない。 また、オブジェクトを使うにはアーリーバインディングで書く必要がある事に注意。 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>...

#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" ===========================================