何をいまさらなのですが。開けてびっくり玉手箱。.net版(対応)でカスタマイズ可能と銘打っている某パッケージ。
.net版といってもピンキリあることを痛感した次第。.net版というからには、基底クラスやInterfaceクラスを公開していて、プロパテイ経由や継承で構築していくものだと勝手に想像してました。ところがぎっちょんちょん。
システム本体との連携は共通インターフェースモジュールを介してやり取りする、IO-Interface方式。...ちっともOOP的でない...それはさておき。
やりとりするメソッドは call 連携IO(種類 as enum , Head_RS as ADODB.Recordset, Detail_RS as ADODB.Recordset)となっている。
DataSetやTableSetではありません。ADODB.Recordsetです。これで.net対応? 質問したら、.netからデータ登録できるし、.netへデータ吐き出しできるから .net対応版です。と言われた。本体は旧VB製のままでCOM製品とのことでした。
広義の.net版と言えないことはない.....netが世にでて8年。個別アプリでは過去のしがらみでCOMが残っているのは理解してます。しかし、汎用ソフトで.net版を謳っていて中身が旧VB製でCOMというのはどうでしょうね。
この連携IO() なるメソッドはHeaderとDetailに必要な項目をすべてRecord Setに格納してやり取りします。これは方式なので良いでしょう。
問題なのはその後処理です。
親子式の業務伝票では、得意先、商品、社員など複数のマスター連携項目が存在します。
Head_RSが親を表し、明細データは子伝票であるDetail_RSで表します。これをSetして呼だすことになにります。
このときマスター存在Errorがあると例外が起こるのですが。 問題は例外が単純で、メッセージが 「マスター未登録のコードがあります。」これだけです。......せめて「yyは xxxマスターに未登録です」位は出すものでしょうブツブッ。(この製品は私のなかでは落第です。...秘密ですが)
「数値に誤りがあります。」だけでは、何の項目がどのように誤っているいるのがチンプンカンプンです。
カスタマイズ可能な製品なのではお客様は開発者(若しくは準ずる人)でもあります。開発が容易な仕組みにするのが使命だと考えます。
問題が起こったときは、単に例外を起こすのではなく。考えられる要因を併記することが望まれます。
いまどき、社内システムでもコレは無いでしょう。愚痴はこの辺にして。
ADODB.Recordset って、DB非結合状態で使うときも RS.OPEN して Open状態でないと使えなかったんですね。すっかり忘れてましたが、Open/Closeの概念と レコードポインタの概念が強いので、使い難くさ満点です。
それでも当時は、疑問や不便を感じず、当たり前に使ってたものです。それだけ ADO.NETが進歩したということでしょう。
一度進化したものを使うと、旧には戻れません。 ジェネリックのない FrameWork1.xには戻れません。まして旧VSは言わんかな。
推論型の宣言文は、お気に入りで、C#3.0/VB9.0 になじむと、 C#2.0/ VB8.0 が色あせて見える自分が怖い。
仕事では当分 FrameWork2.0なのにね。