EXCEL→桐（Ver．８）日付データの受け渡しについて

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

2274	EXCEL→桐（Ver．８）日付データの受け渡しについて	奥山　純代	1999/7/27-18:30
今回初めて投稿いたします。入力代行業務を請け負っており、お客様が桐（Ver．８）をご使用とのことで、ｃｓｖ形式にてテキストをご提供し、あちらの桐に取り込んでいただきましたところ、以下のような状況が発生いたしました。お客様の方も、原因がわからないようなのですが、どなたかおかわりになりませんでしょうか？（桐に詳しい方のＨＰを発見し、思わず投稿した次第です。）日付に関する入力で、あちらのひな型テーブルでは、平成や昭和の年号になるように指定されているようです。そういうこともあり、当方では年月日を 000000という形昭和53年6月5日なら530605 平成6年6月6日なら060606 としてテキスト提供したところ、平成28613年7月27日というような数字になってしまうようです。（ちなみに月日の方は作成した日付のようですが、皆この日付になるようです。）どなたか助けて下さい。よろしくお願いします。
2275	Re:	Ogo	1999/7/27-18:59
記事番号2274へのコメント >日付に関する入力で、 >あちらのひな型テーブルでは、平成や昭和の年号になるように指定されているよう >です。日付で利用する文字列を先方がどのように和暦・月・日に切り分けているのか、即ち、先方側の桐のデータテーブルの定義が判らないと返答に困ります。先方が関数を使って文字列を日付に直す計算式が間違っていると思われます。今回の情報だけでは、奥山さん側に問題があるとは思えません。なお、予測としては「文字型のデータを受け取っているのに、数値データと考えて計算したために、受け取ったデータは全て数字の 0 と判断している」というような間違った計算式を使用している可能性が上げられます。
2277	Re:	宮城	1999/7/28-00:48
記事番号2275へのコメントまず第一点、元号はお使いにならないほうがよろしいかと。西暦４桁をお使いになるほうが賢明でしょう。ひょっとして官公庁関係ですか。それでは仕方がない。年月日情報を１項目だけでインターフェースするのは無謀と考えています。４桁年、月、日を数値情報としてインターフェースし、桐側で年月日情報を再構築してもらうのがよろしいかと考えます。だめでしょうか、Ogo○○（ある事情により伏字化）
2279	Re:	Ogo	1999/7/28-01:22
記事番号2277へのコメント >まず第一点、元号はお使いにならないほうがよろしいかと。西暦４桁 >をお使いになるほうが賢明でしょう。和暦を使うか西洋暦を使うかはポリシーの問題であり、過去からのデータの継続の問題でもあり、今回の場合は「依頼主からの仕様」でもありますので、外部のものがこの点をどうこう言うわけにはいかないと考えます（ちなみに私は和暦が「好き」です）。 >年月日情報を１項目だけでインターフェースするのは無謀と考えて >います。４桁年、月、日を数値情報としてインターフェースし、桐側で >年月日情報を再構築してもらうのがよろしいかと考えます。これはその通りだと思いますが、あくまでも依頼主側の仕様の詰めの甘さであり、奥山さんの責ではないだろうと思います。また、「項目計算式」という桐の仕様の独自さがあって成り立つ部分が強く、一般のデータベースでは、日付を１項目で持つことは極めて普通ではないでしょうか。この点を有効に使えれば、桐の１大アドバンテージなのですがね。今回の問題点は、依頼主にあって奥山さんにない――というのが、私の認識です。入力作業のみを請け負っている人の側が解決方法を模索するべき内容ではないだろうと。なお、ＭＳが CSV の形式を変更したのも、問題を複雑化させている原因の１つかも知れないですね（エクセルが吐き出す CSV の仕様にはいろんな腹立ちがあります）。
2280	Re:	宮城	1999/7/28-02:04
記事番号2279へのコメントわっはっは。不真面目にみえたらごめんなさい。システムってのは結果得るために何でもやるんです。「うまくいくまでやる」　たーん純なお仕事ですけどねー。
2283	Re:	宮城	1999/7/28-09:33
記事番号2280へのコメントすみません。フラストレーションの蓄積でなんら生産的要素のない酔っぱらいの戯言です。失礼いたしました。
2305	Re:	佐田　守弘	1999/7/30-23:46
記事番号2274へのコメント奥山　純代さんエクセルから桐へのデータコンバージョンですが、私は先方のシステムの問題ではなく、奥山さん側で対処すべき課題と考えます。もちろん先方の協力も必要です。まず、先方の桐ver.８の日付のデータ型は分かりますでしょうか。このデータ型が日時型か、文字列型かで答えが変わって来ます。 ●桐側のデータ形式について【日時型の場合】西暦で表示しようと和暦で表示しようと、保持しているデータは日付型と呼ばれる特殊なデータ形式です。簡単に言えば西暦元年１月１日起算の千分の１秒単位で日付時刻を表現する方法です。この場合には、エクセル側から日付と認識できる文字列を出力すれば、どの様な形式でも正しく読み取ってくれるはずです。「”1999/7/30"」の様な西暦表示あっても文字列型（前後に引用符を付ける）で出力すれば、設定にしたがって和暦として表示されます。【文字列型】文字列型は日付を表示する文字列で日付を表す方式です。先方が和暦であれば和暦の形式でＣＳＶで出力して下さい。ただし、西暦その他の形式で出力した場合でも、後で変換してもらうことは可能です。 ●エクセルからの出力について桐の方はどの様な形でも読めないことはないのですが、できれば日付形式で出力して下さい。特に、区切りなしの「000000」は、文字列として出力できれば構わないのですが、おそらくエクセル側では数値として出力するでしょう。数値として出力すると、桐側では日付とはみなしてくれません。桐の項目が文字列型であり、かつエクセルから「"000000"」の様に前後に引用符を付けて文字列型としてCSV形式で出力すれば、読み込めるはずです。しかしエクセルからこの形で出力することは簡単ではありません。計算式でその様な項目値を作り出し、これを出力します。この場合、桐側で読み込んだ値は「000000」のままになります。後から項目置換を使って日付の表現形式に変換してもらう必要があります。以上の通りで、まずは先方のデータ型を調べてお知らせ下さい。なお、最善の方法は、桐で入力することです。（体験版があると思います。）ちょっと使ってみれば、エクセルよりも入力操作が楽で、入力の生産性が良い事に気がつくはずです。うまく表とフォームを作れば、おそらく、エクセルの２倍かそれ以上の効率で入力できるでしょう。データ入力を請っているなら、入力の生産性がすなわち利益ですから、考えるべきだと思います。桐の場合には、エクセルと違い、入力しやすい表とフォームを設計するのがポイントです。これがうまくできないと、エクセルよりも効率が落ちます。設計のポイントは私のＨＰを参考にして下さい。佐田　守弘追伸：エクセルと桐のデータ交換はおもしろい課題なので、近日中にＨＰにコンテンツを掲載する積もりでおります。しばしお待ち下さい。
2306	Re:	Ogo	1999/7/31-00:26
記事番号2305へのコメント >エクセルから桐へのデータコンバージョンですが、私は先方のシステムの問題ではなく、 >奥山さん側で対処すべき課題と考えます。そうでしょうか？ >以上の通りで、まずは先方のデータ型を調べてお知らせ下さい。　　　　　　　 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ データ型と項目計算式等の定義だと思いますが、こんな指示が出ること自体、桐の定義側に問題があると思います。数字型であれ、文字型であれ、「エクセルのデータを CSV でもらった時に、正常に読み込める桐の TBL 定義になっていない」というだけのことだと。まぁ、現在の CSV ではなく K3 フォーマットなら、どうなのかという興味はありますが、アクセスならば K3 フォーマットとほぼ同じテキストを拡張子 CSV で書き出せますが、エクセルではねぇ（そもそも小数のサンプルデータで受け渡しのテストはしていないんでしょうか？原因はすぐに判りそうなものだが）。ただし「この受け渡しのフォーマットを決めたのは奥山さんである」というなら別ですが。 >なお、最善の方法は、桐で入力することです。（体験版があると思います。） >ちょっと使ってみれば、エクセルよりも入力操作が楽で、入力の生産性が良い事に気が >つくはずです。これは同意します。
2312	Re:	佐田　守弘	1999/7/31-23:48
記事番号2306へのコメント Ogoさん、お久し振りです。さて、 <佐田>エクセルから桐へのデータコンバージョンですが、私は先方のシステムの問題ではなく、　　　 >奥山さん側で対処すべき課題と考えます。 <Ogo>そうでしょうか？ですが、私の意見はOgoさんとやや異なっておりますが、奥山さん側の問題と考えます。詳しい事は、現在関連コンテンツを掲載準備中ですので、それを見て頂くと分かると思います。ここでは簡単にそのサマリーを述べます。原因は、奥山さんが「yymmdd」形式の区切りなし形式で入力されようとしている所にあります。 Excelからこの形をCSV出力すると、数値(整数)として出力されます。特に、平成年号が１桁の場合、「060606」と入力しても、「60606」の数値しか出力されないはずです。奥山さんが引用符付きの６桁数字文字列「"060606"」形式で出力する工夫をしているなら話は別ですが。一般にはExcelでは数字だけを入力すれば数値（整数）となります。また先頭の0はサプレスされます。この様な整数を桐で読み込んだ場合、表の日付の項目が日時値型か、文字列型で挙動が変わります。一応、すべての日付形式で試してみましたが、・日時値型の場合：整数型の値は読み込めません。・文字列型の場合：数字を文字列として読み込めます。しかしその後、yymmdd形式から区切りがある日付文字列ないし日時値型に変換するのは、２桁ごとに分けて間に区切りを入れる計算式が必要になります。おそらく先方の桐の表はその様になっていないでしょう。ただし、 <奥山>平成28613年7月27日というような数字になってしまうようです。の部分は良く分かりません。おそらく、入力した日付の数字の並びをすべて年号とみなしているのだろうと考えます。このあたりの事を知りたいので、受け取る側の項目のデータ型や受け取った値を変換する計算式を聞きたかったわけです。それで、結論的なことを言えば、奥山さんの側では、和暦形式であれば「Hyｙ/mm/dd」形式で先方に提出すべきだったわけです。少なくとも、桐側で「yymmdd」形式から「Hyｙ/mm/dd」に変換する仕組みが用意されてない限り、正しく読み込めないと思います。なお、相手側が日時型であれば、和暦か西暦かの表記は表示形式だけの問題なので、奥山さんの方は西暦でyyyy/mm/dd形式で提出できます。おそらく、奥山さんは、「Hyｙ/mm/dd」形式で入力するのは面倒なので、キー操作が簡単な「yymmdd」形式での入力を考えたのだろうと思います。もちろん、この考え方は間違っていません。しかしながら先に述べた通り、この形式でExcelから出力しても、出力されるデータが整数ですから、桐では正しく読み込めません。特に平成年度が１桁の年号については、出力される整数が５桁になってしまいますから、桐側では日付として読み取る術がありません。もしもどうしてもExcelで「yymmdd」形式で入力したい場合には、たとえば、「060606」と入力した時に、「60606」でなく、「"060606"」と桁数を合わせて、かつ引用符を付けたCSVデータを出力する工夫が必要になります。そう言った意味で、この問題は奥山さんの方で対処すべき課題と思う次第です。 <Ogo>データ型と項目計算式等の定義だと思いますが、こんな指示が出ること自体、 <Ogo>桐の定義側に問題があると思います。仮に桐の定義側に問題がある（問題があるというより、区切りなしの６桁数字を年号に変換する仕組みですが）場合でも、それに合わせて読み込めるデータを提供するのがビジネスのスタンスと考えます。先方のシステムを変更させてもらえるなら別ですが。 <Ogo>まぁ、現在の CSV ではなく K3 フォーマットなら、どうなのかという興味はありますが、確認してみましたが、Ｋ３フォーマットでも全く同じです。区切りなしの数字だけを日付として読み込ませるには、桁数を合わせて出力し、文字列型の項目に文字列として読み込ませた後、桐側で年月日に区切る必要があります。佐田　守弘
2314	Re:EXCEL→桐 CSV日付受け渡し解決編	Ogo	1999/8/1-21:23
記事番号2312へのコメント乗り掛かった船なので、まず、当初、桐側では日付を文字型で持っているという固定観念を持ちました。理由は、数値を入力するだけで勝手に年号を「昭和」や「平成」と判断するような方法は項目計算式を使っているとしか考えられなかったからです（西暦を 1900年代と 2000年代に分配するのとは全く状況が違います）。先方の雛形テーブルが項目計算式を使って入力（ CSV からインポートされた）データを加工する時に >日付に関する入力で、 >あちらのひな型テーブルでは、平成や昭和の年号になるように指定されているよう >です。 >平成28613年7月27日というような数字になってしまうようです。 >（ちなみに月日の方は作成した日付のようですが、皆この日付になるようです。）このような計算式が入っていると考えざるを得ないと思い込み、こちらでどんなデータを渡しても無意味だと考えたのです。本当にその通りならば、解決策（１）は以下の通りです。 >そういうこともあり、当方では >年月日を >000000という形 >昭和53年6月5日なら530605 >平成6年6月6日なら060606 >としてテキスト提供したところ、エクセルでこのようなデータを CSV で渡した場合、受け取る桐側（雛形テーブル）の項目計算式は #条件選択(#int(#数値([日付])/10000)<1,””,1, 　#条件選択(#int(#数値([日付])/10000)>30,”昭和”,1,”平成”) 　　+#文字列(#int(#数値([日付])/10000))+”年” 　　　+#文字列(#mod(#int(#数値([日付])/100),100))+”月” 　　　　+#文字列(#mod(#数値([日付]),100))+”日” ) です（エクセルの CSV のデータが直接入る項目名を [日付]としています。また暫定的に、３０年以下は「平成」・３０年を超えると「昭和」です）。この計算式なら、[日付]項目が数値でも文字列でも問題は発生しません。エクセルのデータ入力時に文字列として入力しても、数値として入力しても両方大丈夫です（数値として入力した場合、060606 は最初のゼロが消えてしまうし、 CSV ファイルにも冒頭のゼロは出力されませんが）。更に言えば、このデータを全角文字で入れていても問題が発生しないようになっています。 - - - - - - - - - と、ここまで書いて佐田さんの投稿を見て、桐側では項目計算式を設けていなくて、単純に日時型の項目の入力欄である可能性があることに気付きました。すると、何も計算式を定義していない日時型項目に >平成6年6月6日なら060606 >としてテキスト提供したところエクセルでこのようなデータを CSV で渡した場合、桐側でこれを読み込みすると、確かに、全部無茶苦茶な日付になることを確認できました。これならば、解決策（２）は以下の通りです。エクセル側では日付を入力する際に >そういうこともあり、当方では >年月日を >000000という形 >昭和53年6月5日なら530605 >平成6年6月6日なら060606 >としてテキスト提供したところ、この様式は不適合。正解は、エクセルで入力するときに（Ａ）　　　　　　　　（Ｂ） S53.6.5　　または　 S53/06/06 H6.6.6　　または　 H06/06/06 と入力するということにつきます（画面表示も CSVテキストの中身も（Ａ）の形式に自動的に変換されると思いますが）。これを CSV で書き出し、桐側で CSV ファイルの読み込みを行えば、正常に日付の受け渡しができる筈です。 P.S. 後者の場合なら、「奥山さんの責任」ということになるのでしょうか…… この「日時型項目のテキストフォーマット」は、桐使いでも気付きにくい盲点ですよね。多分、依頼主からは明確なテキストフォーマットの指示は出されていないんだろうと思われるのですけどね（やっぱり仕様の詰めが甘いと言わざるを得ないと思うゆえんです）。 P.S.2. 前者のようなテキスト文字列を後者のような日時型項目に、項目計算式で適合させるには #条件選択(#int(#数値([日付])/10000)<1,"",1, 　#日時値( 　　#条件選択(#int(#数値([日付])/10000)>30,"昭和",1,"平成") 　　　+#文字列(#int(#数値([日付])/10000))+"年" 　　　　+#文字列(#mod(#int(#数値([日付])/100),100))+"月" 　　　　　+#文字列(#mod(#数値([日付]),100))+"日"))
2316	Re:	奥山　純代	1999/8/2-13:05
記事番号2314へのコメント皆さんお疲れ様です。問題提起者の奥山です。発言が遅れて申し訳有りません。熱いご意見を本当に有難うございます。入力代行業を請け負いながらも、勉強不足を痛感しています。さて、経過を簡単ですがお伝えします（皆さんの御意見に比べたら、本当に少ない＆稚拙なご報告で申し訳ない）。当初、クライアントさんは桐の所有の有無を当社に問い合わせされました。当方は桐を所有しておりませんが、以前にもＣＳＶ形式でテキストを提供した旨をお伝えしましたところ（この時は、先方「桐」に相当詳しい方がおられたように思います。）、それじゃ、ＣＳＶテキストで一度テストをしてみようという話になったのです。先方のテーブルの中には、日付のほかに単価（通貨）の項目もありましたので、私の方も事前にそこのところの定義つけはどうなっているか、先方にお聞きしました。ところが、桐のテーブルを作成された方が今は不在とかで、担当の方もただ分からないようでしたので、私なりに、テストサンプルデータを作った次第です。それから以降は、皆さんご周知のとおり、日付はエラーが出てしまいました。一番最初にOgoさんからご意見をいただいた段階で、もう一度先方に定義つけに関して、問い合わせましたが、とくに回答は得られませんでした。その時に、私の方であらかじめ和暦をいれた（エクセル側で）ｃｓｖテキストを渡したところ、それだと問題なかったようです。（文字型だからだと思いますが。）ただ今、先方さんは夏休みとかで不在にされていますが、この件に関しては、和暦を入れた改訂版のサンプルデータをもって、ＯＫとされているようです。 >P.S. >後者の場合なら、「奥山さんの責任」ということになるのでしょうか…… >この「日時型項目のテキストフォーマット」は、桐使いでも気付きにくい >盲点ですよね。多分、依頼主からは明確なテキストフォーマットの指示は >出されていないんだろうと思われるのですけどね（やっぱり仕様の詰めが >甘いと言わざるを得ないと思うゆえんです）。 > ほんとうに、おっしゃる通りです。恐縮です。

戻る