一括処理から読み込み（会話）？

過去の桐井戸端ＢＢＳ　（桐ver.７）

845	一括処理から読み込み（会話）？	ツタヤ	1998/12/18-11:09
いつもＲＯＭさせていただいて、参考にさせていただいております。さて、今回一括処理で自社の積算プログラムを組もうと悪戦苦闘しております。そんな中、一括処理から表の読み込みをする際に、会話処理と同じ読み込みが出来ず苦慮しております。会話処理なら少々形式の違う表でも対応する項目を指定すれば読み込むことが出来るので、その機能を使いたいのです。一括処理の読み込みでは条件登録にない項目ははじかれてしまいうまく行きません。何か良い手だてがありましたら教えていただけないでしょうか。今までいろいろ作り直しながら会話処理で積算していたので、表の項目名がバラバラの状態で保存されています。積算の際、既存の顧客の積算結果を読み込んで修正しながら新しい見積を作ると簡単なので、何とかしたいと思っています。今までのデータを全て同じ項目名に作り替えるのは大変な作業になりますので・・・怠慢といえば怠慢ですね。よろしくお願いします。そんなことは出来ないよでも結構です。
848	Re:	ikjun	1998/12/18-13:00
記事番号845へのコメント　桐のバージョンが書いてないのと、最終的にどうしたいのかよくわからないので答えずらいのですが、簡単に考えて会話処理でできることなら会話処理で行うのが早いと考えます。　つまり表　"メイン.tbl" メッセージボックス　”読み込み”,”次に旧バージョンのファイルを読み込みます。ファイル(F)の読み込み処理(Y)を使って読み込んで下さい。” 表形式編集　ガイド=”読み込みを行って下さい。” メッセージボックス　”保存”,”あたらしい形式に保存し直します” ・・のようにして表形式編集のなかから、読み込みを会話処理で行うのが簡単だけど、単純すぎますか？そういうことではないような気もします。
855	Re:	ツタヤ	1998/12/18-22:21
記事番号848へのコメント >　桐のバージョンが書いてないのと、最終的にどうしたいのかよくわからな >いので答えずらいのですが、簡単に考えて会話処理でできることなら会話処 >理で行うのが早いと考えます。失礼しました。桐のバージョンは7.1です。表現が難しいですね。作業表と読み込み対照表の項目名が一致してない場合、一括処理の読み込みコマンドで読むことが出来るかと言うことなのです。会話処理だとデータ型が合っていれば項目名が違っても、対象項目を指定してやれば読み込めると思うのですが、間違ってるかな？一括処理から会話形式の読み込み(表)を呼び出して読み込みが完了したら再び一括処理に戻りたいと考えています。上に書いていただいた方法で一括処理に戻れるのでしょうか？ちなみに一覧表形式のフォームのコマンドボタンから実行したいと考えています。僕だけが使うのならすべて会話処理でもよいのですが、誰でも出来るようにしようと四苦八苦しています。現在の所スラッシュメニューを使うようにガイダンスを表示して逃げています。
859	Re:	ikjun	1998/12/19-11:25
記事番号855へのコメント >作業表と読み込み対照表の項目名が一致してない場合、一括処理の読み込みコマン >ドで読むことが出来るかと言うことなのです。　それはできますよね。読み込み　表,【<表ファイル名>\|<表番号>】,編集表=【する\|しない】,終了状態=<変数名>,【{<現在表項目名>【<入力表項目名>】, … }\|*】　という風に、作業表のうしろに読み込み対照表の項目名を書くだけですから？ってこういう意味でもありませんね？ >会話処理だとデータ型が合っていれば項目名が違っても、対象項目を指定してやれ >ば読み込めると思うのですが、間違ってるかな？　間違ってはいません。 >一括処理から会話形式の読み込み(表)を呼び出して読み込みが完了したら再び一括 >処理に戻りたいと考えています。 >上に書いていただいた方法で一括処理に戻れるのでしょうか？　戻れます。表を終了した段階で戻って次の処理にいけます。 >ちなみに一覧表形式のフォームのコマンドボタンから実行したいと考えています。 >僕だけが使うのならすべて会話処理でもよいのですが、誰でも出来るようにしよう >と四苦八苦しています。現在の所スラッシュメニューを使うようにガイダンスを表 >示して逃げています。　根本的な疑問なのですが、今現在表の項目名がバラバラだということですが、それをそのまま使って行くつもりですか？それとも徐々に変換して統一するつもりですか？　バラバラのままだと、結局はどの項目がどれに相当するのか手動で指示する必要があり、ご希望のプログラムができたとしても、会話処理よりはちょっとマシだという程度になってしまうような気がします。　かといって、使うか使わないかわからない過去の積算データをすべて変換するというのも無駄以外のなにものでもないので、古い形式の積算データを使用するときは、その都度新しい形式に変換するように、指示するプログラムを組んだほうが、得策ではないでしょうか？　それで、ここからは考え方の問題なのですが、私なら１年もすればほとんど使わなくなる部分に手間ひまはかけません。　前述のように一括処理から表形式編集に入って会話処理で変換させるようにします。表を終了した段階でまた一括処理に戻りますから、そこできちんと変換されているかどうか、チェックしてＯｋなら次に進む。だめなら繰り返しでもう一度。　次は名前を付けさせて保存、古い積算データは削除する。（ユーザーにはそう説明、実際は拡張子を変えて、見えなくさせるだけ！）という風にすれば徐々に形式は統一されるはずです。　業務の性格上、全社員が使うというわけでもない？と思いますので、読み込みの作業くらい口で説明した上に、説明書でも作れば十分だとおもうのですが？　どうしてもと言うことであれば、#項目属性( num , n )を使って表の項目名を取得して、この項目はここに変換するという指示をさせるようにして、変数を利用して、読み込みコマンドを実行させるという手もあるとは思いますが、手間がかかる割には報われないような気がします。　こんなことでもありませんか？　ところで、なんの積算ですか？あまり建設関係以外では積算とはいわないような気がしますが？（見積もりとはいうけれど！）
865	Re:	ツタヤ	1998/12/20-12:56
記事番号859へのコメント >>作業表と読み込み対照表の項目名が一致してない場合、一括処理の読み込みコマン >>ドで読むことが出来るかと言うことなのです。 > >　それはできますよね。その後引き続いてフォーム編集にはいるのは無理ですよね。一旦保存し直さないと？ >>会話処理だとデータ型が合っていれば項目名が違っても、対象項目を指定してやれ >>ば読み込めると思うのですが、間違ってるかな？ > >　間違ってはいません。安心しました。 >>一括処理から会話形式の読み込み(表)を呼び出して読み込みが完了したら再び一括 >>処理に戻りたいと考えています。 >>上に書いていただいた方法で一括処理に戻れるのでしょうか？ > >　戻れます。表を終了した段階で戻って次の処理にいけます。戻れると言うことは一旦保存してから一括処理に戻って再び先ほど保存した表を読み込むと言うことですね。これも考えてみます。 >　根本的な疑問なのですが、今現在表の項目名がバラバラだということですが、それ >をそのまま使って行くつもりですか？それとも徐々に変換して統一するつもりですか？ >　バラバラのままだと、結局はどの項目がどれに相当するのか手動で指示する必要が >あり、ご希望のプログラムができたとしても、会話処理よりはちょっとマシだという >程度になってしまうような気がします。これは当然統一して行くつもりです。 >　かといって、使うか使わないかわからない過去の積算データをすべて変換するとい >うのも無駄以外のなにものでもないので、古い形式の積算データを使用するときは、 >その都度新しい形式に変換するように、指示するプログラムを組んだほうが、得策で >はないでしょうか？おっしゃる通り、その辺で苦慮しています。 >　それで、ここからは考え方の問題なのですが、私なら１年もすればほとんど使わな >くなる部分に手間ひまはかけません。またまた納得。 >　前述のように一括処理から表形式編集に入って会話処理で変換させるようにします。 >表を終了した段階でまた一括処理に戻りますから、そこできちんと変換されているか >どうか、チェックしてＯｋなら次に進む。だめなら繰り返しでもう一度。ふむふむ、この手に落ち着く感じもします。 >　次は名前を付けさせて保存、古い積算データは削除する。（ユーザーにはそう説明、 >実際は拡張子を変えて、見えなくさせるだけ！）という風にすれば徐々に形式は統一 >されるはずです。 > >　業務の性格上、全社員が使うというわけでもない？と思いますので、読み込みの作 >業くらい口で説明した上に、説明書でも作れば十分だとおもうのですが？そうなんです。一括処理の勉強もかねて、どこまで出来るか試しているところもありますので。 >　どうしてもと言うことであれば、#項目属性( num , n )を使って表の項目名を取得 >して、この項目はここに変換するという指示をさせるようにして、変数を利用して、 >読み込みコマンドを実行させるという手もあるとは思いますが、手間がかかる割には >報われないような気がします。 > >　こんなことでもありませんか？この辺の所になってくると、今の僕の技量ではついていけません。 >　ところで、なんの積算ですか？あまり建設関係以外では積算とはいわないような気 >がしますが？（見積もりとはいうけれど！）設備関係の仕事をしています。給排水衛生設備工事の積算を考え中です。それがそこそこ出来たら。道路工事（土木積算）にチャレンジしようかと思っています。
866	Re:	ikjun	1998/12/20-18:57
記事番号865へのコメント >その後引き続いてフォーム編集にはいるのは無理ですよね。一旦保存し直さないと？　そうですね。出来るかどうかというよりいったん保存した方が無難でしょう。 >戻れると言うことは一旦保存してから一括処理に戻って再び先ほど保存した表を読み >込むと言うことですね。　そうです。 >この辺の所になってくると、今の僕の技量ではついていけません。　可能性があるというだけで、出来るとは保証しかねますし、こんな面倒なことはやる気にもなりません。そんなことするくらいなら、手作業で使いそうなデータから変換していった方がずっといいような気がします。 >設備関係の仕事をしています。給排水衛生設備工事の積算を考え中です。それがそこそ >こ出来たら。道路工事（土木積算）にチャレンジしようかと思っています。　うーーん、既製のソフトを使った方が早いような気がしますが？特に土木積算は、難しいと思います。　オールＮ８８ベーシックで出来た積算ソフトがあります（信じられないことに現行のソフトです）が、ベーシックのソフトだけで、３０Ｍバイトを越えているはずです。ソフトの本数は数千本単位のはずです。　また、既製の土木積算では、本来役所で公開してないはずのデータまで入ってます。（どうやって手に入れたかは？？？）その辺のノウハウまで考えると、実用に値するものを作るのは相当難しいと思います。　それに、毎年積算用のデータが変わります。膨大なデータを毎年全部入れ直すなんてことが現実に出来るのでしょうか？（労務データ、資材データ、機械のリース料・・）　道路工事に限定した話なら、出来るかも知れませんが？今は単純な道路工事って少ないとも聞きますし・・・・・　設備用の積算ソフトも、Ｗｉｎｄｏｗｓ対応で比較的安くていいものがあるはずです。それを越えるソフトを自分で作るのは、かなり難しい気がします。体験版もあるはずですので、取り寄せて参考にしてみるという手もあります。　それぞれの会社の特殊事情があることを考えると、自社用のプログラムを作ることも必ずしも無駄では無いとも思いますが？　アッ、桐に関係ない話になってしまった。オールＮ８８ベーシックで出来た積算ソフトがあるくらいですから、桐なら十分に可能ですのでがんばって下さい。
867	Re:	ツタヤ	1998/12/20-23:33
記事番号866へのコメント >　可能性があるというだけで、出来るとは保証しかねますし、こんな面倒なことはや >る気にもなりません。そんなことするくらいなら、手作業で使いそうなデータから変 >換していった方がずっといいような気がします。一旦既存のデータはあきらめてすべて一から積算しても良いのですが・・・ >　うーーん、既製のソフトを使った方が早いような気がしますが？特に土木積算は、 >難しいと思います。実はそうなんですが、依然桐４で作られているのを見たことがあります。何かの雑誌に付録で付いていていろいろ覗いてみたのですがそのころの僕にはどこをどうしてあるのかわかりませんでした。 >　また、既製の土木積算では、本来役所で公開してないはずのデータまで入ってます。確かに不思議ですが、最近ではほとんどの自治体が狡獪に向けて動き出しています。 >　それに、毎年積算用のデータが変わります。膨大なデータを毎年全部入れ直すなん >てことが現実に出来るのでしょうか？（労務データ、資材データ、機械のリース料・・）これは電子データで、物価調査会社からＣＳＶで出ていますね。 >　道路工事に限定した話なら、出来るかも知れませんが？今は単純な道路工事って少 >ないとも聞きますし・・・・・ >　それぞれの会社の特殊事情があることを考えると、自社用のプログラムを作ること >も必ずしも無駄では無いとも思いますが？会社の特殊性ではなく、各自治体の特殊性が問題なのです。今年法律が変わったので少しずつ、全国統一形式になってくれることを願っているのですが。 >　アッ、桐に関係ない話になってしまった。オールＮ８８ベーシックで出来た積算ソ >フトがあるくらいですから、桐なら十分に可能ですのでがんばって下さい。ボチボチ頑張ります、貴重なご意見をありがとうございました。
869	Re:	ikjun	1998/12/21-02:40
記事番号867へのコメント >実はそうなんですが、依然桐４で作られているのを見たことがあります。何かの雑誌に >付録で付いていていろいろ覗いてみたのですがそのころの僕にはどこをどうしてあるの >かわかりませんでした。　それは、わたしも見ましたが、とても実用になるようなものではなかったような記憶があります。 >確かに不思議ですが、最近ではほとんどの自治体が狡獪に向けて動き出しています。　確かに、そうなんですが、当てになるかどうか？ >>　それに、毎年積算用のデータが変わります。膨大なデータを毎年全部入れ直すなん >>てことが現実に出来るのでしょうか？（労務データ、資材データ、機械のリース料・・） > >これは電子データで、物価調査会社からＣＳＶで出ていますね。　でも、ないものもかなりあるはずですよ。 >会社の特殊性ではなく、各自治体の特殊性が問題なのです。今年法律が変わったので >少しずつ、全国統一形式になってくれることを願っているのですが。　そうなる傾向は確かにありますね。　最初は土木積算のこと、本当にわかっているのかなあ？と思ったのですが、よくおわかりのようですので、がんばって下さい。　よければ、興味がありますので、後ほどの報告していただければありがたいですね。企業秘密になる部分もあるとは思いますが！
871	Re:	ツタヤ	1998/12/21-09:23
記事番号869へのコメント >　それは、わたしも見ましたが、とても実用になるようなものではなかったような記憶が >あります。率上げ計算と、積み上げ計算の複合計算が入るので、その辺に苦労されていたようです。 >>確かに不思議ですが、最近ではほとんどの自治体が狡獪に向けて動き出しています。 > >　確かに、そうなんですが、当てになるかどうか？一度市販の積算ソフト会社のソフトと私の手計算と出正確性を競ったことがありますが私の手計算の方が正解でした。ソフト会社の積算ではかなり開きがあったような？ >>>　それに、毎年積算用のデータが変わります。膨大なデータを毎年全部入れ直すなん >>>てことが現実に出来るのでしょうか？（労務データ、資材データ、機械のリース料・・） >>これは電子データで、物価調査会社からＣＳＶで出ていますね。 > >　でも、ないものもかなりあるはずですよ。それ以外にも地域の特殊性が加味されているので複雑ですね、特に土をさわる仕事は。 >　最初は土木積算のこと、本当にわかっているのかなあ？と思ったのですが、よくおわか >りのようですので、がんばって下さい。 > >　よければ、興味がありますので、後ほどの報告していただければありがたいですね。 >企業秘密になる部分もあるとは思いますが！何時になるやら私自身はっきりしないので期待に添えるかどうか。　徐々にやっていこうと思います。＃その昔管理工学の肝いりで（株）ＤＢ出版という会社からKIRIJURNALという冊子が出ていて、購読していたのですが。　あの会社はどうなったのでしょうね。＃なかなかおもしろかったのですが。　そろそろＤＭが来たりして・・・

戻る