【I love Access】やっぱりアクセスが良い

【I love Access】や� ..

410:NAME IS NULL
08/02/08 01:12:28 XfNQDRfL
アクセス2003を使っていて悩んでいます。
フォームにて(1)大分類(2)小分類を入力する際に、(1)にてA～Dを選択できるリストを表示し、(2)にて(1)で選んだ分類に属する小分類a1～a8、b1～b8・・・といったリストから入力するフォームを作りたいのですが、まったくわかりません。
このような入力方法をするにはどうしたらよいのでしょうか。

せめてこのようなリストは何というのか教えてください。

411:NAME IS NULL
08/02/08 09:18:57
>>410
(1)で選択した値で(2)のリストを抽出してやればいいんじゃないか？
(2)のリストボックスのソースをクエリにして、その抽出条件を(1)の選択値にしてやる。って感じ。

ってことでいいのかな？

412:NAME IS NULL
08/02/08 19:37:57
Access2007を買いたくない。
しかし、下位との互換性が薄いから、将来を見越して買わざるを得ない。

なぜ、Microsoftのご都合バージョンアップに付き合わされなければならないのか。
Access2003で十分。XPで十分。
リボンとか添付ファイル型は必要ない。

買う決心をつけるために、どなたか、Access2007の素晴らしさを説明して欲しい。

413:NAME IS NULL
08/02/08 19:39:33
>>412
桐にしとけ

414:410
08/02/08 23:17:29 XfNQDRfL
>>411サンクスです。

オレにとって難易度が高そうですが、やってみます。

415:404
08/02/09 00:57:17 SKQjl18B
一応普通に加算できましたのでお礼とご報告まで。

Val関数でできたのですが、不思議なのはレコードと関連していない１～３１のテキスト群の
たった一つだけ関数書き込んだだけでできてしまいました。
釈然としませんが、できているので、いじらないことにしました。

ただ一難去ってなんとやらと申しますか・・・・例の１～３１の結果を「来院数」（レコードあり）に反映させ
るわけですが、テキストボックスには加算された日数が入っているのに、レコードにはまったく反映
されません。悩む・・・・。

416:NAME IS NULL
08/02/09 02:08:31
レコードと結びついたフィールドを入力しなかった場合には、書き込まれないはずだが。
すべてのフィールドをレコードと結びつけるようにすれば、あれこれ悩まなくてすむと思う。

417:NAME IS NULL
08/02/09 02:13:45
1 + 1 + 1 = 3
1 & 1 & 1 = "111"
1 + "A" + 1 = "1" & "A" & "1" = "1A1"

このあたりは基本だから憶えておこうぜ。

418:NAME IS NULL
08/02/09 11:05:05 SKQjl18B
みなさん御世話掛けます（汗
結局のところ私みたいな初学者は

＞すべてのフィールドをレコードと結びつけるようにすれば、あれこれ悩まなくてすむと思う

なんですかね、なにか必要のないレコードが増えると心理的に無駄使いしてるような気になってしまって。
考えてみたら、別にリアルに物が増えるわけでもなし、データ量としても微々たるものなんだから
最初からそうすべきでした。

419:NAME IS NULL
08/02/09 21:35:57
>>418
どうも発想がデータベース的ではないような気がしますね。

次はあくまでも個人的発想方法だということで読んでください。

1.フォームで入力用テーブルに入力する。
2.SQLで入力用テーブルから出力用テーブルを作る。
3.レポートで出力用テーブルを印刷する。

もちろん例外もあるのだけど、基本的にはこの発想でやると単純化できます。
Accessは自由度が高いだけに自分なりのパターンをもたないと収拾がつかなくなります。

ここで１と３は問題ないだろうけど、２のSQLで処理するというのに引っかかる人がいると思う。
もちろん、１レコードづつループしながらVBAで処理していく方法もあるけれど、
Accessのレコード移動は遅いようで結局時間がかかります。

結局SQL（クエリー）を使うほうが一般的に早いようです。それも桁違いにです。
かなりのデータ数でも「もう終わったの？」というスピードで処理します。
一見複雑でSQLでは処理できなさそうな処理でも途中でワークテーブルを使ってやればできます。
余計なワークテーブルを使うと遅くなりそうだけど、SQLが高速なせいでそうはなりません。
ワークテーブルを作るのがいやで、複雑なSQL文を書いてもかえって遅くなるだけです。

とまあ、アドバイスになるか反面教師になるかは知らないが、こんな考え方もあるということで・・・

420:NAME IS NULL
08/02/09 22:55:38
データの数がエクセルが扱える以上にならないかぎり
アクセスよりエクセルのほうが効率的じゃないのかな？

アクセス本腰いれたいんだけど
そんな思いが頭を離れない
こんなおれに一言

421:NAME IS NULL
08/02/09 23:08:42
>>420
エクセルが扱える数ってどれくらいを考えているの？
現実に使えるのは数千件がいいところだよ。
データが多くなれば重くて実用的にはとても使えない。
数万件の処理を考えているのならエクセルは問題外。

一言じゃないけどこれでいいか？

422:NAME IS NULL
08/02/09 23:42:09
>>421
まあその数千件がただしいとして(2003なら65536行×256列てことでいいのか)
それ以下ならアクセスを使っても非効率だってことでオッケなの？

423:NAME IS NULL
08/02/09 23:50:50
アクセスとエクセルは製品コンセプトがまったく違うだろ。
エクセルでデータベースらしいものができるかどうかしらんが、
ひとに使ってもらえるようなものは到底むりだ。

424:NAME IS NULL
08/02/09 23:58:44
古いPCだからCPUが遅いのもアルが、
エクセルで３千件で、その遅さに泣いた。
データは普通の住所録

アクセスに移行したら、作業時間が１/４以下になった。

参考に

425:NAME IS NULL
08/02/10 00:07:25
>>423
メーカー側が作ったもんじゃないコンセプトなんて
それよりかは
使う側がある目的を達するために
どれだけ効率的に生産的になれる道具かが重要って発想で

全然わかってないんで見当はずれかもだが

テーブルにためこんだデータを
後でいかようにも出力できるってのがメリットなのか

馬鹿扱いされるんだろうけど
直感的じゃなくねアクセス

426:NAME IS NULL
08/02/10 00:24:25
>>425
>使う側がある目的を達するために
>どれだけ効率的に生産的になれる道具かが重要って発想で
これ重要。
数百件のデータを程度を決まった使い方するなら、紙に印刷したものを
ファイリングした方が効率的だと思う。

エクセルも千～二千件程度のデータなら、いいソフトだと思うよ。
マクロで自動化も出きるし、簡単なUIも作れるし。
なにしろ、開いただけで何が同入っているか分かる。直感的ダネ。

アクセスに移行しようと思ったのは
・二千件超えたあたりで顕著に遅くなった。
・他人が使う可能性が出てきた。
　CSVに吐いてwordで取り込んで差し込み印刷に使っていたんだが
　９xのせいか分からんが、エクセルとワードの連携がうまくいかなかった。
・ボタン一発で楽をしたくなった。

データを色々加工して見せたりする必要が無い、帳票が必要無い、
自分しか使わない、もしくは使う人がある程度エクセルを分かってる
んならエクセルでもいいんじゃね。

エクセルをシラン人が触ると、エクセルの表示データの幅を自分で
動かしておいて「文字が全部表示されない！」って怒る事があるからな。

427:NAME IS NULL
08/02/10 00:29:40
そこまで知らない奴に触らせるならシート保護くらいしとけw

428:NAME IS NULL
08/02/10 00:32:40
>>427
自分しか触らない前提で、フォルダー深く掘って
隠しといたんだけど。

そういう奴に限って、掘り出すんだよ…orz

429:NAME IS NULL
08/02/10 00:50:43
>>424
>>426
参考になりヤス

＞ボタン一発で楽をしたくなった。
書籍を片っ端から読んでますが
その楽をするまでがイバラの道なような

＞データを色々加工して見せたりする必要が無い、帳票が必要無い、
＞自分しか使わない、もしくは使う人がある程度エクセルを分かってる
＞んならエクセルでもいいんじゃね。

ただ知り合いの作った帳票とかを見るにあるいは書籍をみるに
レポートでデザインのいじれる範囲が目標と乖離してそうな気がするんです
作りこんでもエクセルのように好き勝手に思ったように(もちろん手書きに比べ不満の部分もあるのかもしれません)
つくれないような
当方の職場はエクセルの一般的な使い方はみんな出来るようです

430:NAME IS NULL
08/02/10 01:13:44
>>429
帳票は連票形式のリストしかつくって無いから
どの程度の事が出来るのか、良く知らないけど
データの配置は自由だし、単票で作れば何でも出来そうな
気がするけど。
複雑な帳票をたくさんの種類つくらなきゃならんと、ちょっと面倒だね。

帳票のデザインとボタン一発とSQLは別のスキルだねぇ。
帳票やフォームのデザインをする時は頭を切り替えるw

私だったら、アクセスに移行するかどうかは
データ量と帳票レイアウトの変更頻度で判断するな。

しょっちゅう、レイアウトが変わったり、増えたりするなら
なれてるエクセルで帳票作成して、データ件数が増えたら
最悪はバックエンドにアクセス使うってのアリかも。
まぁこのへんは色々意見がありそうだが。

431:NAME IS NULL
08/02/10 02:44:56
>>419
ごもっともだと思うが、それを>>418を相手にに説くのは間違っていると思う。

432:NAME IS NULL
08/02/10 10:57:21
>>412
OOoのBaseでAccess2007のmdb扱えるようになったから
もう2007は要らないと決心した

433:NAME IS NULL
08/02/10 14:11:21
2007の.accdb自体は.mdbのJETデータベースエンジンに毛が生えた程度のもんだから
それは従来のBASEが.mdbを扱えるからACCESSいらないって言ってるのと同じだよ

434:NAME IS NULL
08/02/10 15:15:10
結論的にいらないことには変わりないんだからいいんでね？

435:NAME IS NULL
08/02/10 17:28:11
>>431
まあ確かにそれもごもっともだと思う。
>>418に説いたというより初学者全般に対する指標のつもりだったのだけど・・・
そんなえらそうに言えた義理じゃないんだけど・・・

436:NAME IS NULL
08/02/10 17:30:55
OOoのBaseって実用的に使える程度になったのか？
以前触った時には実験中？ってできだったけど？

437:NAME IS NULL
08/02/10 17:32:06
>>436
使える気がしないです。

438:NAME IS NULL
08/02/10 21:38:47
>>412
Accessはオブジェクトが極限まで増えるとメモリ不足に陥りいろいろ障害がでてくる。
VersionUpは機能が増え一見いいことのように思えるがその代償として
ユーザが使えるメモリ領域が減ってしまう。
結局、32bitというメモリ空間が変わらない限り安易なVersionUpは
ユーザにとってはけっして好ましいこととはいえないのである。

439:404
08/02/11 11:17:26 EwWRkqJM
最後にひとつだけ質問よろしいでしょうか？

フィールドのない３１個のテキストボックスにＶａｌ関数を使い、数値化には成功
その３１の数値の積を【来院数】に出すわけですが、レコードソースに式を書き込むと
レコードに残らないということだったので、「クリック時～」で設定するとこれも成功。

しかし実際には諸事情で「クリック時～」では実用的ではありませんで、「更新後～」にするべき
でありましたので、その欄に書き換えました、問題はここです。
何度やっても反応しません、式が間違っているわけでもなさそうです、なぜなんでしょう・・・・。
毎度くだらない質問で恐縮ですが、最後にご教授ください。

440:NAME IS NULL
08/02/11 11:57:27
更新後ってのは、レコードが書き込まれた後ってことだから
書き込まれない限り実行されない。
別の方法を考えるべきだろう。

441:NAME IS NULL
08/02/11 13:22:24
>>438
> 結局、32bitというメモリ空間が変わらない限り安易なVersionUpは
おいおい、32bitのメモリ空間って言ったら４GBになるんだぜ。
Access2007がどれくらいのメモリが必要なのか知らないが、
４GB使い切るほど肥大化しているわけ無いだろ？

442:404
08/02/11 13:26:57 EwWRkqJM
>>440
ありがとうございます

なるほど「更新後」の意味を履き違えておりました、いまの今まで。
そうなると「更新前」は・・・・いや、あれもだめだった。
いちばんいい方法はなんなのだろうか考えてみます。

443:NAME IS NULL
08/02/11 13:40:50
どうでもいいが来院数の院が病院の院だったら
ちょっと怖くて行けないな・・・

444:NAME IS NULL
08/02/11 13:44:11
桐にしとけよ
良いとこ取りだぞ

445:NAME IS NULL
08/02/11 13:46:41
またお前か。

446:NAME IS NULL
08/02/11 14:06:19
>>444
（笑）

447:NAME IS NULL
08/02/11 14:45:55
>>439=404
31日分の合計(和)を出す電卓を作りたいってことだろ？
入力途中の表示に違和感を覚えるかもしれないが
「変更時」に再計算するようにしておいたらどうよ？

448:NAME IS NULL
08/02/11 14:53:56
>>443
いや、その病院では一番Accessが得意な
若い看護婦さんかも知れないぞ
ここでお近付きになっておいて
その病院へ逝くのも悪くない

449:NAME IS NULL
08/02/12 00:57:22 aoyNE+PV
教えてください。

とある機器のレンタルをしている事業所で勤務しております。
そこで、レンタル代金請求の仕組みを作ることになったのですが、
請求パターンがややこしくACCESSでの実現手順を教えてください。

商品代金の他に、送料と消毒代金も請求しており、
又、通常のレンタルとお試しレンタルもあり、
お試しで借りて、通常レンタルに切替る事があります。
お試しで借りて、気に入らずに返却になる事もあります。

請求ですが、
　　　　　　納品送料　引上送料　　　消毒
通常　　　　開始月　　終了月　　　　終了月　　
お試し　　　終了月に往復　　　　　　終了月

情報には契約番号（切替の場合、契約番号は同じ番号です）、
レンタル開始日、終了日、があります。

例：お試し、通常レンタルともに終了
　　→消毒費とる
　　お試し終了し通常レンタル切替てレンタル中
　　→消毒費とらない（レンタル中なので）

消毒費とる場合は、「1」とらない場合、「0」になるような
式を教えてください。

同じく、送料についても、とる場合「1」、とらない場合「0」
になるような式を教えてください。

450:NAME IS NULL
08/02/12 01:03:43
商品マスタに消毒代とか送料とか登録しとけ

451:NAME IS NULL
08/02/12 01:57:07 aoyNE+PV
>>450
送料、消毒費登録ありますよ。
で、発生する条件を式にできないものかと、

あと補足ですが、
同じ契約番号の場合の見分け方ですが、「行番号」と「レンタル区分」で
通常レンタルかお試しか見分けます。

宜しくお願いします

452:NAME IS NULL
08/02/12 06:17:15
>>449
VBAで関数を記述しないと無理だな。
数式を一行で表わすっていうのはむずかしいんだよ。
VBAなら、どんなに複雑な判定文でも実現可能なはず。

453:NAME IS NULL
08/02/12 17:12:51
>>449
まず、自分の飯のタネの仕事を２ちゃんで他人に只でやってもらおうってむしが良すぎない？

それにこれそんなにややこしい請求パターン？
「通常レンタル」、「お試しレンタル」、「お試しから通常切り替え」の３パターンしか無いように思うけど？
プログラマーならそれほど苦労せずにできることだと思うけど・・・

もしかしてエクセルの延長線でできると思ってない？、
レンタル代金請求の仕組みって請求書発行までするってことでしょう？
プロでも結構苦労することを簡単に出来ると思っている？
繰越処理が割と難しいし、消費税の問題もある。
相手のあることだから意外と例外処理も発生するし、
後から修正することも必要だったりする。

ここで質問に答えてもそのシステム完成しないと思うけどなあ？

454:NAME IS NULL
08/02/12 19:07:49
（質問がよく理解できてない気がするオレだけど）
請求パターンをテーブルにすりゃいいんじゃないの？
パターンごとに1とか0を最初からいれといてクエリ
でつないだら？

455:NAME IS NULL
08/02/12 21:59:21
俺がやったことあるのは不動産の賃貸契約書管理とか
リース資産のリース契約書管理とかだけど、このケースでは・・・

　・契約の開始/終了は年月日ではなく年月で管理（シンプルでいいね）
　・契約開始年月はデータ入力の時点で確定。
　・契約終了年月は契約期間中に変化する(先延ばし)可能性あり。
　・契約区分に通常/試用があり、契約期間中に変化する(試用→通常)可能性あり。
　・請求金額1(納品送料)の請求時期は契約区分が通常なら契約開始年月、試用なら契約終了年月。
　・請求金額2(引上送料)の請求時期は必ず契約終了年月。
　・請求金額3(消毒費用)の請求時期は必ず契約終了年月。
　・どの請求金額も請求するのは契約期間中に必ず1回だけ。

このあたりを踏まえた上で設計するのがポイントになりそうだね。
かなり作りこみしちゃったからもうそんな変更できないよと言われても困るけどw

456:NAME IS NULL
08/02/13 08:20:02
>>429
ACCESSにデータ抱え込んでおいて、
EXCELからADOでも使って呼び出したらいい。

これなら好き勝手に出力形式作れる。

457:NAME IS NULL
08/02/14 09:45:10
>>441
>32bitのメモリ空間って言ったら４GB
理論的には、使い切れないほどの巨大なメモリ空間のはずなんだが、
実際にオブジェクトを増やしていくとすぐに限界にきてしまうのなぜだろう。

458:NAME IS NULL
08/02/14 14:17:31
>>457
そりゃあリソースの話じゃないのか？
いくらメモリがあってもリソースが足りなくなればそれ以上は出来ないよ。
もしかしたら、いまだにWin98系列を使ってない？

459:NAME IS NULL
08/02/14 22:40:04
それはない。

460:NAME IS NULL
08/02/14 23:15:39
Windowsのリソース管理テーブルサイズと
Accessのリソース管理テーブルサイズはべつもんでしょ。
ヘルプとかにリミット書いてなかったっけ？

461:NAME IS NULL
08/02/15 18:13:51
>>460
そうなのか？それは知らんかった。お恥ずかしい。

それはともかく、オブジェクトってフォームとかレポートのことだと思うのだけど、
Accessでオブジェクトを極限まで増やすっていったいどれくらいのこと言ってんだろう？
そんなに増やしたら管理するのが大変だと思うし、それってAccessの守備範囲なんだろうか？
大人数での開発に適してないAccessでそんな開発するほうが無理と違うのかなあ？

462:NAME IS NULL
08/02/15 19:00:25
TableCount=425
QueryCount=263
FormCount=144
ModuleCount=144
MacroCount=0
ReportCount=0

こんな感じだが、特にFormはMemoryを多く消費する。
オブジェクトの管理はうまく工夫すれば、どんなに数が増えようが負担は変わらない。

463:NAME IS NULL
08/02/16 00:39:02
テーブル一覧で毎日死ぬほどスクロールさせてんだろうな。

まあ本人が負担と思ってないんだから別にいいけどw

464:NAME IS NULL
08/02/16 03:26:33
テーブルが多くなるとスクロールで探すのに苦労するってのは初心者だな。
アクセスのレコードソースの入力欄はインクリメンタルサーチ機能があるんだから
それを最大限に活用できるような命名規則をつくるのが肝心なんだよ。

465:NAME IS NULL
08/02/16 08:40:03
>インクリメンタルサーチ機能

テーブル名に漢字を使ってるヤシにはピンとこないんだよね。

466:NAME IS NULL
08/02/16 08:53:56
>アクセスのレコードソースの入力欄

これないんだけど・・・
アホにもわかるように詳しく

467:NAME IS NULL
08/02/16 10:12:13
設計が最適化されてたらフォームにしろレポートにしろ
複数テーブルいくつも連結するだろうに。

インクリメンタルサーチが役立つって、おまえはいつも
単体テーブル一個しか使わないのかよw

468:NAME IS NULL
08/02/16 16:01:22
>>462
うわあ・・・糞の山だあ・・・

469:NAME IS NULL
08/02/16 17:02:42
>>462
> TableCount=425
４２５もテーブルがあるのか？
いったいどういうシステムなんだ？月ごとにテーブルを切り替えているとか？

> QueryCount=263
> FormCount=144
> ModuleCount=144
オブジェクトの話だよね？モジュールが１４４っていったいどんな分け方したらそんなことに？
プロシージャをモジュールごとに分ける意味が無いような気がするが？
それともフォームにはプロシージャーを書かないようにしているとか？

> MacroCount=0
> ReportCount=0
ほんでもってレポートが０？印刷しないのか？
それとも、他の方法でも使っているのか？

随分と謎のシステムだなあ？

470:NAME IS NULL
08/02/16 18:49:37
>>466
俺もなんのことかわからなかったのだけど、
もしかしたら、コードウィンドウのことかな？

用語の使い方といい、オブジェクトの数といい、
随分独創的なシステムの構築をしているらしいなあ？
まあ、それもいいけど・・・・・・

471:NAME IS NULL
08/02/16 18:59:50
>>466
1.フォームオブジェクトを選択
2.右クリックでデザインビューを選択
3.フォームのプロパティを開く
4.すべてのタブを選択
5.レコードソース（1番上)

472:NAME IS NULL
08/02/16 19:34:23
>>471
それを省略して言うと「アクセスのレコードソースの入力欄」になるのか？独創的だなあ？
なんだか良くわからないが、とりあえずいいや。独創的過ぎて参考にならなさそうだし。
だいたいテーブルの管理は印刷でもしておけば問題ないし、特にどうってことはない。
とりあえず、メモリを食うフォームでも１４０まではいけるんだ。
俺はまだ６０もいってないから、当分は大丈夫。これは参考になった。サンキュー！

473:NAME IS NULL
08/02/16 20:13:53
フォームと同様にレポートもメモリ使うみたいだから、それもカウントしなきゃダメだよ。

474:NAME IS NULL
08/02/16 20:57:05
>>473
ああ、それもそうだなあ。するってえとそろそろ限界が近いかもしれない。
基本的に１ファイルで管理するAccessではやはり大規模開発（ってほどでもないけど）は無理かも？
随分前から代替手段を検討しているけれど、とりあえず問題がないのでなかなか踏ん切りがつかない。
一応第一候補はJavaなんだけどなあ？

475:NAME IS NULL
08/02/17 01:26:08
Mac、Linux、Windowsとプラットフォームを問わないJAVAでの開発がこれからの主流。

そんなふうに考えていた時期がぼくにもありました・・・

476:NAME IS NULL
08/02/17 11:04:55
Accessの代替がJavaとかズレてねえ？

477:NAME IS NULL
08/02/17 12:07:16
>>469
アクセスのレポートを使わないのは、他の印刷ツールを使っているからだ。
そのほうがよりニーズに対応したものが作れるということもあるが、
MDBからできるだけ外に出したいという理由がある。（メモり対策、分散作業のため）
その代わり、ワークファイルやモジュールが増大するのは仕方ないと思っている。

478:NAME IS NULL
08/02/17 13:26:35
>>477
アクセスのレポートより良い印刷ツールなんてそうそう無いと思うのだが？
いったいなに使っているんだろう？

479:NAME IS NULL
08/02/17 15:30:36
>>476
じゃあ、他になんかある？

480:NAME IS NULL
08/02/17 15:36:56
VB

481:NAME IS NULL
08/02/17 16:27:22
桐

482:NAME IS NULL
08/02/17 17:46:13
おいおい、Accessより大規模なシステムの開発の話だぞ。
VBや桐じゃ同程度の開発がいいところだと思うけどなあ？
ってまあここで聞くような話じゃないけどな。

483:NAME IS NULL
08/02/17 20:41:54
データベースエンジンの話が抜けてるのがズレてるっぽい

484:NAME IS NULL
08/02/17 21:47:03
エンジンはJetで

485:NAME IS NULL
08/02/17 22:20:57
>>484
なんでAccessの一番の弱点だと思われるJetエンジンをAccessの代替で使わなければいけないんだ。
MySQLあたりを使うのが普通だろう？

486:NAME IS NULL
08/02/17 22:25:51
俺の会社オラクル使ってるけど、レポートと入力は桐でやってる。
レポートは桐が群を抜いてるし、入力も桐の表形式が速くて誤入力がない。
他はオラクル。

487:NAME IS NULL
08/02/17 22:38:21
オラクルと桐しか使ってないやつがなんでこのスレ来てんの？w

488:NAME IS NULL
08/02/17 23:04:14
２ちゃんもDB関係は全部目を通してる。
一応、DBが本職なんで。

489:NAME IS NULL
08/02/18 02:14:37
>>478
アクセスのレポートは作成された帳票にユーザが手を加えられないのが難点。
エクセル形式で帳票作成できるツールであれば、作成されたものはユーザが自由に改造できる。
また、ユーザが作ったエクセルファイルをそのまま流用できるのもいい。

URLﾘﾝｸ(www.adv.co.jp)

ACCESS VBAからでも使用可

490:NAME IS NULL
08/02/18 05:45:35
>>486
桐とオラクル？
初めて聞く組み合わせだ。
確かにワープロを作っていた会社だけあって日本語のレポートは郡を抜いている。
ほとんどどんな印刷物でもできる。
でも、桐の外部データーベース接続は遅いって聞いたのだけど？
それとも、入力と印刷のたびにファイル変換しているのだろうか？
オラクル自体はなんで動かしているの？まさか桐の一括処理？
もし良ければ参考にしたいので教えて下され。

491:NAME IS NULL
08/02/18 08:33:50
入力と印刷のたびにファイル変換してる。

入力は一部だけど、キーパンチャーがバコバコボコボコ入力する部分だけ。
ほんと、入力も桐が効率良いわ。

492:NAME IS NULL
08/02/18 19:07:03
>>491
Accessのフォームも作りこんで複写とか出来るようにすればそれなりに効率は良くなるんだが、
あまり複雑になると遅くなったりするからなあ？
確かに桐を使うってのはひとつの手だとは思うし、
ファイル変換してというのはありだとは思うけど、あまりスマートなやり方ではないなあ？
マネしてやってみようという気には残念ながらならないなあ？

493:NAME IS NULL
08/02/18 20:15:43
お前はJavaでやればいいよ

494:NAME IS NULL
08/02/18 21:15:23
>>492
複写ってどうやんの？

495:NAME IS NULL
08/02/18 22:59:30
・オラクル→桐
・桐→オラクル

通常の運用でこの処理を何度も何度も何度も何度も繰り返してるってことだな。
人間のやることだからバコバコ打った後に桐→オラクルするつもりがオラクル→桐しちゃったとか
年に1回くらい普通にありそうだが・・・

496:NAME IS NULL
08/02/18 23:02:02
Accessの帳票は印刷にはいいんだけど、
データでくれって言われた時にちょっと困る。

前はPDFにして送ったけど。

497:NAME IS NULL
08/02/18 23:17:54
印刷物を画像データで要求されて困るのはAccessのレポートに限ったことじゃないと思うが

498:NAME IS NULL
08/02/19 05:05:58
>>495
普通はプログラム（一括処理？）組んで自動処理するだろう？
オラクルまで導入してそんなところを手作業でしてたらいい笑いものだ。

499:NAME IS NULL
08/02/19 05:07:07
>>497
たぶんエクセルと比較して言っているんだろう？

500:NAME IS NULL
08/02/19 09:45:59
印刷イメージをデータで送るってこと多いのか？レポートのレコードソースをＣＳＶでというのはよくあるが。

501:NAME IS NULL
08/02/19 11:08:13
>>494
> 複写ってどうやんの？
元のデータを変数に格納してその変数を使ってレコードを追加すればいい。
そんなに難しいプログラムではないよ。
使いやすく作るのは難しいかもしれないけれど。

502:NAME IS NULL
08/02/19 12:31:52
>>497
エクスポートで.htmlやら.xlsやら選べるの知ってたから安請け合いしたら、
実際やってみてｳﾎﾞｧということがあった。
まあ俺が間抜けなんだけど。

>>500
実際のレイアウトとか見たいんじゃないかな。

Accessだとレポート使うけど、
こないだHSQL+JavaでやったときはHTML出力にした。
Accessのレポートは印刷設定が時々リセットされるし。
そのたびに呼ばれるのはかなわん。

503:NAME IS NULL
08/02/19 13:17:48
社内で主にデータ閲覧用のデータベースとしてアクセス（ADP）使っているんだけど、
そろそろレポート出力の方もちゃんと勉強しなくちゃと思ってます。
レポートの作り方で参考になるようなサイトってあまりみかけないんだけど、
おすすめあったら教えてプリーズ。

504:NAME IS NULL
08/02/19 18:52:41
そういや、レポートってあんまりなにかを見て覚えたという記憶がない。
トライ＆ゴーでいろいろやって、なんとなくわかった。
基本的にはフォームと良く似ているけれど、
ユーザーインタフェースを意識しなくていいので楽な気がする。
気をつけなくてはいけないのはヘッダーとフッターの使い方。
特にグループヘッダーフッターの使い方で改ページするところが変わってくる。
いろいろやってみればだんだんわかってくるとは思うけど最初は戸惑う。
それと、あまり複雑なレポートを作ると重く遅くなるので、
印刷用のデータをSQLで作ってレポートはシンプルになるように気をつけたほうがいいと思う。

505:NAME IS NULL
08/02/19 19:25:55 zoj3pqPw
ＡＣＣＥＳＳでこのようなデータを入力後下記の形にＶＢＡでしたいのですが
どうすればいいですか？
納品先　　｜商品名　　｜規格　　　｜数量　　　｜
Ａ　　　　｜やさい　　｜２Ｌ　　　｜５０　　　｜
Ａ　　　　｜やさい　　｜３Ｌ　　　｜３０　　　｜
Ｂ　　　　｜衣料品　　｜Ｌ　　　　｜　５　　　｜

変換したい形
納品先　　｜商品名　　｜内容１　　｜内容２　　｜内容３　　｜
Ａ　　　　｜やさい　　｜２Ｌ　　　｜３Ｌ　　　｜　　　　　｜
Ａ　　　　｜やさい　　｜５０　　　｜３０　　　｜　　　　　｜
Ｂ　　　　｜衣料品　　｜Ｌ　　　　｜　　　　　｜　　　　　｜
Ｂ　　　　｜衣料品　　｜５　　　　｜　　　　　｜　　　　　｜

506:NAME IS NULL
08/02/19 20:06:10
あほなことやってると思うけど
あえてやり方挙げるなら
UNIONかな

507:NAME IS NULL
08/02/19 20:09:08
>>505
テーブルでは、たとえ桐つかっても無理だな
レポートでやれ

508:NAME IS NULL
08/02/19 20:43:19
レポート作るとき

フィールドリストからドラッグアンドドロップして
ラベルとテキストのコントロールが連結した状態で出来上がるが

その一方だけをセクションを跨いで移動したいとき

例えばラベルだけをフッターセクション上に置き
テキストは詳細セクション上に置くには
どのようにすればいいのでしょう？

ドラッグしてもセクションをまたげなくないですか

509:NAME IS NULL
08/02/19 20:46:25
またげないお

510:NAME IS NULL
08/02/19 21:02:27
>>508
それほど悩むことかな？
ラベルをカット＆ペーストで持っていけばいいんじゃない？
ラベルだけ作り直したってたいした手間ではないし。

511:NAME IS NULL
08/02/19 21:04:58
Access2007のはラベルのC&Pでも持っていけなかったorz

512:NAME IS NULL
08/02/19 21:12:41
>>510
慣れてる方はそう思われるんでしょうけど
出来うるなら簡素なやり方でやりたい

フィールドが沢山あるもので
オートレポートでもフィールドが多すぎて出来ないと
表示されますし

513:505
08/02/19 21:44:35 zoj3pqPw
>>507
レポートだとどうすればいいですか？

514:505
08/02/19 21:59:36 zoj3pqPw
まちがえました
再度書き込みしなおします

ＡＣＣＥＳＳでこのようなデータを入力後下記の形にＶＢＡでしたいのですが
どうすればいいですか？
納品先　　｜商品名　　｜規格　　　｜数量　　　｜
Ａ　　　　｜やさい　　｜２Ｌ　　　｜５０　　　｜
Ａ　　　　｜やさい　　｜３Ｌ　　　｜３０　　　｜
Ｂ　　　　｜衣料品　　｜Ｌ　　　　｜　５　　　｜

変換したい形

納品先　　｜商品名　　｜規格１　　｜数量１　　｜規格２　　｜数量２　　｜規格３　　｜数量３　　｜
Ａ　　　　｜やさい　　｜２Ｌ　　　｜５０　　　｜３Ｌ　　　｜３０　　　｜　　　　　｜　　　　　｜
Ｂ　　　　｜衣料品　　｜Ｌ　　　　｜５　　　　｜　　　　　｜　　　　　｜　　　　　｜　　　　　｜

515:NAME IS NULL
08/02/19 22:03:12
>>512
オートレポートってアメリカならいざしらず罫線を使った複雑な帳票を要求される日本では使い物にならない。
ラベルとテキストの連結は便利なようで実際はじゃまにしかならない。

レポートって最初からレイアウトが一発で決まるということはまず無くて、
結局修正修正の繰り返しになることがほとんど。
経験上、簡素なやり方だと後で手直しする手間がかえってかかる。
複雑な帳票になるほど一つ一つコントロールを配置していくほうが結局近道になる。
複雑な帳票といっても良く見ると似たようなコントロールが多いので、
一つ作ってそれをコピーしてから修正すれば意外と手間はかからない。

まあ、意にそぐわない答えだと思うけど正直そう思う。

516:NAME IS NULL
08/02/19 22:07:04
似たようなものがいっぱいあるとき
全部のプロパティいじるの面倒で仕方ないんですが
コントロールの配列みたいなことは出来るんですか？

517:NAME IS NULL
08/02/19 22:37:59
>>516
> 似たようなものがいっぱいあるとき
> 全部のプロパティいじるの面倒で仕方ないんですが
いったいいくつあると言うのかな？
似たようなものならいじらなければならないプロパティはそんなにないと思うのだけどね。
例えば３１個のフィールドがあるならば最初にData01を作ってコピーした先をData02とすれば１を2に変えるだけ。
最初からそういうことを念頭においてテーブル設計しておけば面倒なことはないと思う。
それからコピーしてペーストしたコントロールを移動してからさらにペーストすれば、
移動した方向にいくつでも並べられる。これを使うと配置も便利。
工夫次第でこれくらいのコントロールは簡単にできるよ。
そのくらいことで面倒なんて言っていたらVBAなんてとてもできないし、
VBAを使わないAccessなどクリープの入ってない・・・・・・(w

３１個よりはるかに多いというのならそれは根本的に考え直したほうがいいと思う。
３１個の例でもプレビューするのに何分もかかりました。
それよりはるかに多いのなら使い物にならないだろうし、
ハングして動かなくなる可能性も高い。

> コントロールの配列みたいなことは出来るんですか？
コントロールの配列ってまったくイメージがわかないんだが、出来ないだろうと思うよ。

518:NAME IS NULL
08/02/19 22:42:08
>>515
いや、参考になりやす
アメリカ文化の日本文化の罫線　
バカヤローです。

ただofficeの浸透力、シェアにあきらめて
やるしかないですね

519:NAME IS NULL
08/02/19 22:52:21
>>518
ここで出てきそうな言葉が「桐にしとけ」なんですが、
確かにこういう分野は桐が得意でいいんですが、
桐には桐の問題点があるんでね。
Accessでも工夫次第で大抵のことはできるんでがんばってください。

520:NAME IS NULL
08/02/19 23:05:07
>>517
コントロール配列はVBでは基本テクニックっすよ。

521:NAME IS NULL
08/02/19 23:24:24
　VB6 では、実行時に配列を振る必要はないのですが、デザイナで 1 つ、コピー元になるコントロールを配置しておく必要があります。
また、そのコピー元の Index プロパティを画面デザイナから 0 に設定しておいてください。(実行時の設定はできません)
新しいコントロールを追加するというよりは、コントロールを複製するという動きになります。
そのコピー元は Index プロパティが 0 のコントロールで、Load ステートメントを使用することで複製されます。
この時、Visible プロパティは False になっていますので、True にする必要があります。

522:NAME IS NULL
08/02/19 23:24:56
URLﾘﾝｸ(jeanne.wankuma.com)
' Load イベントで配列を動的に作成してフォームに加える
Private Sub Form_Load()
　　 Dim i As Integer
　　 For i = 1 To 9
　　　　 ' Load ステートメントを使用してコントロールを作成する
　　　　 Call Load(Me.Text1(i))
　　　　 ' ここで、プロパティなどを必要に応じて設定します
　　　　 Me.Text1(i).Text = "Text" & CStr(i + 1)
　　　　 Me.Text1(i).Top 　= Me.Text1(0).Top + (240 * i)
　　　　 ' 初期値で False になっているので True にする
　　　　 Me.Text1(i).Visible = True
　　 Next i
End Sub

523:NAME IS NULL
08/02/19 23:28:14
VBAでは使えないサンプルソース乙

524:NAME IS NULL
08/02/19 23:34:43
>>516
桐には初めからファミリってのがあって、コントロールをグループ化して一括で設定できるど

525:NAME IS NULL
08/02/19 23:35:54
URLﾘﾝｸ(www.h3.dion.ne.jp)
URLﾘﾝｸ(www.moug.net)
URLﾘﾝｸ(okwave.jp)

526:NAME IS NULL
08/02/20 11:29:28
>>504
アドバイスありがとう

527:NAME IS NULL
08/02/20 12:09:20
>>525
アドバイスありがとう

528:NAME IS NULL
08/02/20 20:58:58
>>514
エクセルならいざしらず、まずデータをコード化しないとどうにもならないと思いますよ。
このままコード化しないまま処理しようと思っているのなら、エクセルでやったほうがいいでしょう。

それはともかく考えかたとしてはこういうことでいいと思います。
規格によって書き込む位置が変わるわけですからその規格がどの位置になるかの情報が必要です。
この場合２Ｌは１の位置、３Ｌは2の位置、Ｌは１の位置ということになります。
この位置情報をテーブルで保存しておきます。

そしてあらかじめ変換したい形の空白のデータベースを用意し、そこに商品マスターからデータを流し込みます。
そのテーブルに元の形式のテーブルと位置情報のテーブルをリレーションして更新をかけます。
これはSQLをつかうのが簡単で早いでしょう。

とはいうものの本当にこんなやり方でいいんでしょうか？やさいというのは単なる例なのでしょうが、
規格がある一定の範囲で収まるとは思えないのですが・・・・
印刷サイズを越えたらどうするのでしょう？
根本的に考え方を変えたほうがいいように思うのですが？

529:NAME IS NULL
08/02/20 23:10:49
衣料品の規格Lは常識的に推理できるけど野菜の2Lとか3Lとかが
どんなものかまるで想像つかないな。
もしかしたら4Lとか5Lとか99Lとかたくさん種類があってそれを50音順に、
あるいは入力順に左詰めで並べたいということだろうか？
順番は関係なく、とにかく3つが横並びになっていればいいのか？
同じ野菜で同じ規格が複数行入力されたら数量は合計するのか？
4つめの規格が入力されてしまった場合は捨てるのか？数量4を用意するのか？
それとも4つめの規格については絶対入力されない保証があるのか？

もうちょっと要件定義が必要だとｵﾓﾀ

530:514
08/02/20 23:49:11 DCQNrO7Q
>>528
レスありがとうございます

詳しい説明文もかかずすいませんでした
全然説明不足でした

DATAというテーブルに下記の形で入力します
納品先｜商品名　　｜規格　　｜数量　　｜
-------------------------------------
Ａ　　　　｜やさい　　　｜２Ｌ　　　｜５０　　　｜
Ａ　　　　｜やさい　　　｜３Ｌ　　　｜３０　　　｜
Ａ　　　　｜やさい　　　｜　Ｌ　　　｜１５　　　｜
Ａ　　　　｜やさい　　　｜　M　　　｜２０　　　｜
Ａ　　　　｜やさい　　　｜　S　　　｜３３　　　｜
Ａ　　　　｜やさい　　　｜等外　　｜４０　　　｜
Ｂ　　　　｜衣料品　　　｜Ｌ　　　　｜　５　　　｜

変換後というテーブルを作成しておき以下のように
VBAなりの方法で以下のように追加したいと思います
納品先　　｜商品名　　｜規格１｜数量１｜規格２｜数量２｜規格３｜数量３｜規格４｜数量４｜
--------------------------------------------------------------------------------
Ａ　　　　　｜やさい　　　｜２Ｌ　　　｜５０　　｜３Ｌ　　　｜３０　　｜L ｜１５｜M ｜２０｜
Ａ　　　　　｜やさい　　　｜S 　　　｜３３　　｜等外　｜４０　　｜　　　｜　　　　｜　　　　｜　　　　｜
Ｂ　　　　　｜衣料品｜Ｌ　　　　｜５　　　｜　　　　　｜　　　　｜　｜　　｜　　　　｜　　　　｜

規格で位置が決まってるわけではありません
規格、数量とも１～４まで交互にあり
その商品ごとの規格、数量ははかならず１からはじまります
仮にやさいで規格が６つ存在したら
次のレコードの規格１の所に入る形でやりたいです

うまく伝わりましたでしょうか？

よろしくお願いいたします

531:514
08/02/21 00:04:34 Wq3um4ha
>>530
かなりずれてしまいました

>>529

>衣料品の規格Lは常識的に推理できるけど野菜の2Lとか3Lとかが
>どんなものかまるで想像つかないな。
>もしかしたら4Lとか5Lとか99Lとかたくさん種類があってそれを50音順に、
>あるいは入力順に左詰めで並べたいということだろうか？
>順番は関係なく、とにかく3つが横並びになっていればいいのか？

　　やさいに限らず規格は無限と考えてもらえると助かります
　　並ぶ順番などは特にないです
　　上にあるものからでかまいません

>同じ野菜で同じ規格が複数行入力されたら数量は合計するのか？

　　集計に使う予定で考えてますので
　　クエリをつかって日付で抽出し、納品先ごとで合計します
　　

>4つめの規格が入力されてしまった場合は捨てるのか？数量4を用意するのか？
>それとも4つめの規格については絶対入力されない保証があるのか？

　　530を見てもらえると助かります

532:NAME IS NULL
08/02/21 00:32:42
レポートならこんな感じにサブレポートの列数を指定してやるといい。
URLﾘﾝｸ(nullpo.vip2ch.com)

533:NAME IS NULL
08/02/21 02:30:27
'ADO参照追加
Private Sub hoge()
Dim cn As New ADODB.Connection
Dim rstKey As New ADODB.Recordset
Dim rstData As New ADODB.Recordset
Dim rstTrans As New ADODB.Recordset
Dim count As Integer
Dim flg As Boolean

Set cn = Application.CurrentProject.Connection
cn.Execute "DELETE FROM 変換後"

rstKey.Open "SELECT 納品先,商品名 FROM DATA GROUP BY 納品先,商品名", cn, adOpenForwardOnly, adLockReadOnly
rstTrans.Open "SELECT * FROM 変換後", cn, adOpenForwardOnly, adLockOptimistic

Do While Not (rstKey.EOF)
w = 0
flg = False
rstData.Open "SELECT * FROM DATA WHERE 納品先='" + rstKey.Fields(0) _
+ "' AND 商品名='" + rstKey.Fields(1) + "'", cn, adOpenForwardOnly, adLockReadOnly
Do While Not (rstData.EOF)
If w = 0 Then
flg = True
rstTrans.AddNew
rstTrans.Fields(0) = rstData.Fields(0)
rstTrans.Fields(1) = rstData.Fields(1)
End If
rstTrans.Fields(w * 2 + 2) = rstData.Fields(2)
rstTrans.Fields(w * 2 + 3) = rstData.Fields(3)

If w < 3 Then
w = w + 1
Else
rstTrans.Update
flg = False
w = 0
End If

rstData.MoveNext
Loop
rstData.Close
If flg Then
rstTrans.Update
End If

rstKey.MoveNext
Loop
rstKey.Close
rstTrans.Close

Set rstKey = Nothing
Set rstData = Nothing
Set rstTrans = Nothing
Set cn = Nothing

End Sub

534:NAME IS NULL
08/02/21 10:56:56
規格、数量とも１～４までって限度が決まってるなら、桐でやれば簡単じゃん

535:NAME IS NULL
08/02/21 15:05:24
>>531
>　　クエリをつかって日付で抽出し、納品先ごとで合計します

Pivot使えばテーブルの変換不要
元テーブルから直接集計汁

536:NAME IS NULL
08/02/21 15:10:18
>>534
だれもそんなこと聞いてないよ。空気読めないというか、読む気が無いアホは引っ込んでろ。
俺はVer1からの桐ファンなんだけど、桐の評判落とすようなことはするな！
桐を使うか？Accessを使うかはケースバイケース。
だいたいの場合、手軽にやるなら桐、アプリケーションを作るつもりならAccessを使う。
桐しか使えないアホがなんでも桐が一番なんていうのは良い恥さらしだ。

537:NAME IS NULL
08/02/21 15:14:43
変なの来たわ

538:NAME IS NULL
08/02/21 18:04:05
>>530
上のテーブルはいいけど、下のテーブルはもはやリレーショナルデータベースである意味がない。
もちろん、VBAを使って無理矢理やればどうとでもそういうデータを作成できるけど、
それはVBAを勉強しろとしか言えない。

VBAでやるきがあるなら「レコードセット」がわかればできると思うよ。

>>　　集計に使う予定で考えてますので
>>　　クエリをつかって日付で抽出し、納品先ごとで合計します

ならば、上のデータを直接クエリやVBAで集計することを考えた方がいいのでは？

539:514
08/02/21 19:28:23 Wq3um4ha
>>533
できました
ありがとうございました
使わせていただきますね
自分ももっと勉強しなければ...

>>535
基本は複数行入力しないように心がけてるので大丈夫です

>>538
人から頂いたコードをカスタマイズする程度ならできるんですけど
一からとなるとちょっと自信ないんです....

　　

540:NAME IS NULL
08/02/21 20:31:59
>>539
そういう　なまいきな発言をするから、周りの人に教えてもらなくなって、ここで聞いているんだね。

541:NAME IS NULL
08/02/22 00:47:15
つか、こんなレコード作ってなんに使う気なんだ？

542:NAME IS NULL
08/02/22 05:22:45
いっぱい釣れたのでもういいです

543:NAME IS NULL
08/02/22 09:47:34
>>541
上のほうで出てた印刷イメージのデータを作るってことじゃないか？

544:NAME IS NULL
08/02/22 20:40:56
>>543
まあ、そうなんだろうけど正直あまり良いやり方ではないと思う。
そのまま印刷したんじゃやたら縦に長い表になるからって、
わざわざこんな面倒なことをするんだろうけど、
それなら段組印刷でもすればいいと思う。
そっちのほうがずっと見やすいしシンプルだ。
これもそう簡単に実現はできなさそうだけど
同じ努力するならそのほうが良いと思う。

545:514
08/02/23 14:47:52 BrdEtbtD
>>540
気にさわったのであればすいません
そんなつもりはありませんでした

>>541
543さんの方が言われるとおりです
今までエクセルでこの形で印刷してたんですけど
アクセスに移行しても見慣れたこの形がいいといわれまして

546:NAME IS NULL
08/02/23 15:24:51
>>545
> アクセスに移行しても見慣れたこの形がいいといわれまして
見慣れてない俺からしてみると不自然なんだけどね。
まあしょうがないか？現実にはすべて合理的ってわけには行かないものなあ。

547:NAME IS NULL
08/02/24 22:20:07 +jC5teAM
>>514
印刷目的ならテーブル(or クエリ)レベルで変換するより複数列レポート使うのがお奨め。
たぶん今後も開発や修正が出てきそうな雰囲気だから、作るなら柔軟性や汎用性を持たせておいたほうがいいと思うよ。
「見慣れた形がいい」程度の理由で決めてる相手なら、今後も「列数変えろ」とか「伝票印刷もしたい」とか言い出す可能性があるからね。

548:NAME IS NULL
08/02/25 07:56:12
要するにこういうこと。
URLﾘﾝｸ(www.nurs.or.jp)
実際に作って見せればこっちのほうが見やすいっていうと思うよ。

そうしてきっとこう言うんだよ。
「俺が言っていたのはこういうことだよ。やっとわかったか？」
「嘘つけ！」
ｗｗｗ

549:NAME IS NULL
08/02/28 17:48:38 Tzp8hxPl
アクセスのコンソールクライアントを探してたのですが、ベクター探しても無かったので
WSHの練習を兼ねて作ってみました。
うっぷします。
詳細は同梱のREAME.txtを読んでくだされ。
pass:ac
URLﾘﾝｸ(www-2ch.net:8080)

・ac.wsf
　ＭＳアクセスのコマンドラインクライアント
　使い始めは"/c"スイッチで環境ファイルを作成してください。
　起動すると"AC>"とプロンプトを表示するのでSQL文を入力して下さい。
　画面の表示の整形はCSVです。
　※標準入力を使用してるので、CScript経由で無いとエラーになります。

使い方：/h (ヘルプ) /b (bachモード) /c:MDBへのパスまたは /d:dsn名 (最初のみ)
　　　　/u:ユーザ名 /p:パスワード環境ファイル名(省略時はdefault設定)

※AC>プロンプト内のコマンド
AC>プロンプト内では次のコマンドが使えます。
　　　　AC>help;
　　　　　 help;　　　　　　 :この表示
　　　　　 quit;　　　　　　 :コンソールの終了
　　　　　（SQL文）;　　　　:SQLの実行
　　　　　 @(ファイル名);　　:ファイルの実行
　　　　　 !(コマンド名);　　:コマンドの実行

　　　　　注）文末記号(;)の後にリダイレクト記号(>)とファイル名で
　　　　　　　出力先をカレントディレクトリのファイルにします。
　　　　　例）select * from TEST;>data.csv

※元々CSVを取得、投入するスクリプトを改造したので、CSVを投入する
　スクリプトも同梱します。
・acm.wsf
使い方：/h (ヘルプ) ( /i or /u:キー項目名　挿入 or
　　　　/t:テーブル名環境ファイル名(省略時はdefault設定)

次ページ