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

【I love Access】や� ..

321:NAME IS NULL
08/01/17 15:36:07
ＳＱＬＳｅｒｖｅｒが効果あるのは５ユーザぐらい以上じゃないか？

322:NAME IS NULL
08/01/17 18:03:22
そうだ
MDB用のラッパーを開発しよう

323:NAME IS NULL
08/01/17 20:21:38
・接続ユーザーは３～４人
・更新系はテーブルに直接連結しない
　クライアントのワークテーブルに読み込んで編集し、INSERT,UPDATE,DELETEで更新
・更新時はトランザクションを使う。

ファイル共有でできる限界はこれくらいかな？

324:NAME IS NULL
08/01/17 20:35:15
ワーク使うと同じレコード更新したとき困らない？

325:NAME IS NULL
08/01/17 21:17:28
>>324

自前の排他制御をする必要はある。

326:NAME IS NULL
08/01/18 14:54:25
>>324,325
どう考えてもマルチユーザーで共有しない方が実装がシンプルだろ。
面倒なことは全部RDBMSに任せられない時点で、
共有するのが間違ってるってこった。

接続ユーザーが２名を超えた時点で、
MSDEに移行するかSQL Serverに移行するのが正しい。

327:NAME IS NULL
08/01/18 17:59:01
マルチユーザー＝企業ユーズと考えればアクセスで作ったシステムを
使っているのは圧倒的に中小規模。
売上等の入力用のＰＣが１台と偉いさんが売上や在庫の状況を
見るための閲覧専用ＰＣが数台という構成も少なくない。
この程度ならば使い方次第ではアクセスで十分。

328:NAME IS NULL
08/01/18 20:12:50
>>327
だとしてもMSDEは最適化しなくても容易にファイル破損しないから。

329:NAME IS NULL
08/01/18 21:18:56
２件で　８年以上 ACCESS2 --> ACCESS2000 と変えながら　４，５人で利用する
システムを作りましたが、ACCESS のみ作成して、ＤＢがだめになったことはありません。
２件とも１日５００件ぐらいの伝票入力だけで；閲覧、出力がおおいですが；
難しいシステムだと壊れるんでしょうか？
VBA での処理はいっぱい書いていますが;

330:NAME IS NULL
08/01/19 09:56:17
うちはSQLにどっさりデータを置いて、Accessで閲覧だな。
入力はないな。

331:NAME IS NULL
08/01/19 10:52:35
>>330
SQLって何よｗ

332:NAME IS NULL
08/01/19 16:44:41
↑SQLserverね。しかもいまどきODBCｗｗｗｗｗｗｗｗｗｗ
すまんこ

333:NAME IS NULL
08/01/20 01:08:35
>>326
ADPはローカルにワークテーブルを作って、それをもとにクエリをつくるといった手法がやりにくくないか？
ＡＤＰとＭＤＢが統合されたようなものが理想だと思うんだか・・・

334:NAME IS NULL
08/01/20 09:17:41
#テーブルとか##テーブルは確かに使いにくいな

335:NAME IS NULL
08/01/21 14:26:59
>>329
意外に強固なんですね。
てっきり壊れまくるもんだと思ってました。

うちは排他書くのがめんどうだったんで、
規模は小さいけどSQLServer使ってます。

336:NAME IS NULL
08/01/21 14:37:00
>>330
似たようなもんだけど、うちは閲覧はexcelかIIS
出力はexcelで欲しがることが多いのでVBAばっかり書いてる

データ入力用にADP使っている。
入力のインターフェイス作成の楽さから抜けられなくて困っている。

337:NAME IS NULL
08/01/21 19:08:38
よくこわれてたのはAccess2000以前
2000は安定してると思う
それでもたまにこわれる

338:NAME IS NULL
08/01/21 19:09:23
SQLServerだから排他書かなくていいってことにはならないと思いますが

339:NAME IS NULL
08/01/21 22:14:04
いや、SQLServer使ってるのに排他を自前でゴリ書きはないだろw

340:NAME IS NULL
08/01/22 00:14:45
馬鹿ですか？

341:NAME IS NULL
08/01/22 16:38:44
レコードを読む時点で誰かが編集中かどうか知りたい場合には、
自前の排他が必要になるだろう。

342:NAME IS NULL
08/01/22 16:57:33
Accessでも排他できるのに

343:NAME IS NULL
08/01/22 17:31:06
Anusでも排泄できるのに

344:NAME IS NULL
08/01/23 14:35:36
>>341
低レベルな質問で申し訳ないが、
編集中を判別するためにはどんな処理をするのが一般的でしょうか？
一時テーブルに編集中のレコードIDかなんかをぶち込んで
それをチェックすればいいのですかね？

345:NAME IS NULL
08/01/23 18:11:25
[ロック制御用テーブルの作成]
field1:TableName
field2:RecordD
field3:UserID

[編集開始時]
レコードを読込前に他者が追加したレコードがあるか無いかをチェックし、
あれば、警告する。なければ、自分のUserIDで追加する。

[編集終了時]
自分が追加したレコードを削除する。

346:NAME IS NULL
08/01/23 22:47:19
>>345
警告してからどうする？

１．後から編集しようとしたPCも編集を許す場合
　　後から編集したPCが先に編集しようとしたPCより先に編集を終了した場合
　　先に編集（レコードを追加した方）は編集されたことが分からない

２．後から編集しようとしたPCは編集を許さない場合
　　先に編集を始めたPCの操作者は編集終了までPC入力以外のことができない。
　　例えば先に編集を始めた操作者が入力中に電話がきて電話に出たりすると
　　電話が終るまで他のPCから編集ができなくなる

あと、ロックをかけたPCがフリーズした時のためにロック制御テーブルのクリア処理を
作っておかないと面倒なことになる。

　　

347:NAME IS NULL
08/01/23 23:41:11
DB本体　　　　Access
入出力画面　　Excel(ADO DAO　VBAで接続)
レポート印刷　Access

エクセル画面から操作　この方がユーザーに馴染んでもらえそうな気がしてきた。

348:NAME IS NULL
08/01/24 08:45:59
>>346
他のＰＣが使用中であることを検知したならば、編集できなくすべきでしょう。
排他制御の目的は、データベースの一貫性を保持することだから。

349:344
08/01/24 15:17:18
なるほどね。参考になります。
排他制御つくったことがなかったもので・・・

350:NAME IS NULL
08/01/24 19:27:09
誰が占有しているかさえ判明すれば、良いのかな。
占有時間が長くなった場合、そのユーザーに”直接”声を掛けて、
占有を解除するなり、そのユーザーのＰＣを”直接”操作する。
もともと小規模な使い方を想定しているるのだから、こうゆう対処で
十分かも。

351:NAME IS NULL
08/01/24 20:06:37
その機能ならエクセルにもなかったっけ

352:NAME IS NULL
08/01/25 12:08:40
スレの流れを参考にAccessのみでの小規模クライアント・サーバー型DBを作り始めました。

質問です、よろしくお願いします。
クライアント側からDB本体のテーブルを外部データへのリンクのをVBAで
設定しようと思ってます。

Access2000で、外部テーブルへのリンクを貼るVBAの書き方を教えてください。

353:NAME IS NULL
08/01/25 12:22:55
>>352
URLﾘﾝｸ(www.ruriplus.com)

354:NAME IS NULL
08/01/25 14:11:07
>>353　レスありがとうございます。
DAOを参照して試してみましたが、どうもうまくいきませんでした。

ちょっと352の日本語がおかしかったですね。
「DB本体のテーブルをクライアント側にVBAで作る方法」
URLﾘﾝｸ(msdn.microsoft.com)
↑　ここを見て解決できました。ADOXの参照設定しました。

いろいろありがとうございました。
クライアント側にDB本体のパス名を保持。
　→毎回、起動設定でリンクを貼ること。　→クライアント終了時　リンクテーブル削除
できるようになりました。

355:NAME IS NULL
08/01/25 22:29:44
質問

下記のようなＳＱＬ文でテーブルを作成したいのですが、フィールドのデフォルト値がNullになってしまいます。
特定の値をデファルト値にしたいのですが、記述方法がわかりません。
できる方法はあるのでしょうか？

CREATE TABLE T11 (Field1 Long,Field2 Long,Field3 Long");"

356:NAME IS NULL
08/01/26 07:49:29 g67kGDTI
教えてください
ACCESS２００３なんですが、
メインのフォームから単票形式のレポートをプレビューで表示しておいて
メインからフォームのタイマーイベントでプレビュー上のコントロールに値を表示できないでしょうか？
もちろん、プレビュー上のコントロールはTBとは関係ない物を置いてあります。
こんな感じで
DoCmd.SelectObject "レポート1",acNormal,False
Reports![レポート1]![テキスト1].setFocus
Reporｔs![レポート1]![テキスト1].Text = "1234"
これを実行すると、現在のビューでは設定できません、と言われてしまいます
レポートなんだから、当たり前だとは思うのですが
そんなのレポートじゃなくてフォームでやれよって言われそうなんですが
上司がフォームじゃなくてレポートでって言うので・・・・・
あるいはレポートにタイマーがあればそれでもいいいのですが、ないみたいですね
ACCESS２００７ではレポートにもタイマーがあるらしいですが

357:NAME IS NULL
08/01/26 13:04:11
それはムリ。
なぜにタイマー？
レポートはPrintが済んじゃったら変更効かないよ。
Format時かPrint時にレポート側で設定するのがふつうだと思うけど。
すなおにフォームでやった方が幸せになれるような。
あと「TB」ってなんですか？サンダーバードしか思い浮かばないんだけど。

358:NAME IS NULL
08/01/27 08:56:26
>>355
ADOXで作った方が楽。

359:NAME IS NULL
08/01/27 15:24:21
>>355
NOT NULL制約付けてもいいのかはっきりさせてくれ。

360:NAME IS NULL
08/01/27 15:44:39
つか、JETのSQLでCREATE TABLE文にDEFAULT句設定できたか？
NOT NULLとWITH COMPしかないだろ？

361:NAME IS NULL
08/01/27 17:28:21
DAO 又は　ADOX でつくらないと無理でしょう。

362:NAME IS NULL
08/01/28 11:11:11
>>356
>>357に書いてあるとおり無理なので、
ﾚﾎﾟｰﾄを描画しなおさないとだめ

363:総務課ヒラ
08/02/02 13:56:55 ixlIASXO
すいませんド素人なんですが、今度勉強しながら仕事で使うデータベースを
作らなければならなくなりました。
作ったファイルをサーバーに置いて、各部署で共有してデータの変更や照会を
行うのですが、将来、各部署のaccessがバラバラのタイミングでバージョンアップ
した時に問題が起こりますか？
また複数の部署が同時に同じテーブルの内容を変更した時、問題が起こりますか？
ご指導願いますです。

364:NAME IS NULL
08/02/02 14:09:53
問題が起こります。

365:総務課ヒラ
08/02/02 15:37:06 ixlIASXO
＞364
やっぱダメなんですか
そうですか。他の方法を考えます
ありがとうございました。

366:NAME IS NULL
08/02/02 15:42:16
分割してバックエンド（データ部分）のみ共有する分には、大した問題は起きないでしょ。
自分も問題なかったし、事例はたくさんあるから。
フロントエンド（GUI）が2000だろうが、2002だろうが、2003だろうがOKのはず。
ただし2007は分からない。フロントエンドに2003以前と2007が混在するようなら、
経験者にきいてみないと（自分は経験ない）。
あと、VistaみたいなOSのバグで共有できないケースもあるけど、それはAccess側では
どうしようもないね。

たぶんこの後、コンテクストを無視してSQL鯖がどうとかASPがこうとか言い出す輩が
出てくると思うが、Accessはド素人だけど鯖に滅法強いとかならそちらでどうぞ。

367:366
08/02/02 15:47:51
データ部分のみね

368:NAME IS NULL
08/02/02 16:57:04
>>363
勉強しながらとのことなので、
そうそうすぐに全部署共有でガシガシデータ入力/変更ということにはならなそうだから、
>>366の言うようにデータテーブルだけのmdbを共有して
運用したらいいんじゃないかな？
すごくたくさんの人間が同時にアクセスする、とかなってきたらまた考えたらいいんじゃないでしょうか？

369:NAME IS NULL
08/02/02 17:54:53
その前にいったいどれだけの規模なのか聞かんと答えようがない話のような気がする。
どだいAccessでは無理って規模かもしれないし・・・・・

370:NAME IS NULL
08/02/02 18:18:07
>>366
分割したバックエンドの方がデータに画像とか貼ってあって500MBくらいあるのですが
みんな開くときに遅い遅いと言うので困っています

371:NAME IS NULL
08/02/02 18:51:38
>>370
そりゃサイズでかすぎる。

372:総務課ヒラ
08/02/02 21:28:32 ixlIASXO

みなさんありがとうございます。
そのデータ部分だけ共有というやりかたに兆戦してみます。
部署は１０程しかないし、アクセスもそれほど頻繁ではない
と思います。

浮かんだイメージは、テーブルだけのファイルをサーバーに
置き、そのテーブルにリンクを張った操作用ファイルを各ＰＣ
に置くという感じですが、それで良いのでしょうか？
とにかく勉強します。

373:NAME IS NULL
08/02/02 22:07:36
>>372
それで良いよ。

374:NAME IS NULL
08/02/02 23:16:47
とりあえず、勝手なバージョンアップの禁止を通達しておくんだね。
それでもやるやつはいるだろうけど、それで動かなくなったらそいつのせい。

375:NAME IS NULL
08/02/03 03:14:56
>>370
画像はデータベースに保存せずJPGなどに外部ファイル化しておき、
表示するときだけ読みにいく方法なら遅くはならない。

376:NAME IS NULL
08/02/03 10:06:43
>>375
それはどうやって、やるのですか。
設計図面を画像データを取り込んた800MBくらいになったＤＢがあります。
かねがね、なんとかしたいと思ってました。

377:NAME IS NULL
08/02/03 10:12:38
>>376
Access2007なら画像も元データの形式で保存できるから、余り肥大しないし、もちろん画質劣化もなし

378:NAME IS NULL
08/02/03 10:35:49
フィールドにはパス\ファイル名でテキスト形式で突っ込んでおいて
アプリでそれを拾いに行くようにするとか？

379:NAME IS NULL
08/02/03 11:23:32
>>376
新規のファイルはjpg　なり　pdf で保存する。
すでに、MDB化されているものは、VBAで外部ﾌｧｲﾙに書き出す

URLﾘﾝｸ(homepage.mac.com)

↑VB用だが、僅かの修正でVBAでも使える

380:NAME IS NULL
08/02/03 11:25:39
パス変わったときに面倒ですよね
なんでAccessとかExcelとかの貼り付けって
相対パスにしてくれないんだろう

381:総務課ヒラ
08/02/03 12:17:00 LYNLjY3V
＞373･374
ども。
できそうな気がしてきて、今少しほっとしてます。
明日から時間を見つけて作成にとりかかります。

382:NAME IS NULL
08/02/03 14:30:29
>>377
Access2007を使うことにしても、既にAccess2000MDBの中に
OLE オブジェクト型で取り込んである分を、新MDB移行させる必要がありますよね。
1.Access2000MDB　OLE オブジェクト型のエクスポート
　↓
2.Access2007MDB Attachment型として取り込み

それが379さんの「すでに、MDB化されているものは、VBAで外部ﾌｧｲﾙに書き出す」
なのかな？
「OLE オブジェクト型　エクスポート」で調べてみましたが、ちょっと難しそうです。

>>379
ソース読んでみましたが、自分の能力ではわからないことが多いです。
少しずつ勉強してみます。

皆さん、ありがとうございました。

383:377
08/02/03 14:46:28
>>382
オブジェクト型にしちゃったのは、ビットマップになってるから、JPGやPDFに圧縮しなおすと劣化するど
ビットマップのまま、出して、そのまま2007の添付ファイル型で入れただけで、LZH圧縮かかるから、ZIPなみにサイズ減る

384:377
08/02/03 14:49:00
ああ、

×　LZH圧縮
○　LZ圧縮

385:NAME IS NULL
08/02/03 15:25:18
おいおい、2007のAttachment型って、画像ファイルじゃなくOLEオブジェクトを
そのまま認識してくれるのかよ？
本当なら革命的に賢いな。

386:377
08/02/03 15:34:07
ビットマップは画像ファイル

387:NAME IS NULL
08/02/03 22:17:10
添付ファイル型は複数値型と同じで扱いが面倒だけど
.xlsと.docと.pdfを放り込んで使ってるよ。

388:NAME IS NULL
08/02/03 22:30:10 F3bGJrY2
型番　　日付
A　　　 2008/02/03
B　　　 2008/02/04
C　　　 2008/02/05
D　　　 2008/02/06
E　　　 2008/02/07
F　　　 2008/02/08

エクセルで上記のような表があるとします。
クエリに関数を入れて本日～4日後の2008/02/06までを”全て”
抜きとって表示したいのですが関数わかる方おられませんか。

2008/02/07と2008/02/08は不要としたいのです。
自動的に毎日4日間を抜き取ることはできますか？

389:NAME IS NULL
08/02/03 22:56:32
マルチすんな死ね
ｽﾚﾘﾝｸ(tech板)

390:NAME IS NULL
08/02/04 02:19:12
>>377
「ビットマップは画像ファイル」だけど、OLEオブジェクトは画像ファイルじゃねーよｗ
>383 の手順は、本当に実際にやってできたことなのか？　それとも空想上の話か？
とりあえず、そこはっきりさせてほしい。
いままで、画像ファイルをそのまま突っ込んでいたならまだしも、いったんOLE
オブジェクトに変換されたものをそのまま書き出して画像として認識できるなんて
話は一度も聞いたことがない。 >379 のリンク先の方法も、画像ファイルをそのまま
書き込んだ場合に限られる話で、OLEオブジェクトに変換されたものは対象外。

誰か2000とかで画像ファイルをOLEオブジェクトに変換して格納してあるのを
そのまま書き出して、2007で実際に取り込んだ話をしてくれ。
それで出来るっていうならたしかに朗報。2007万歳。

391:NAME IS NULL
08/02/04 09:02:33
あああ、OLEで埋め込んだ画像データはMDB内部でビットマップで保存されてるから、、
ビットマップで取り出して、そのまま、ビットマップで添付すれば良いんじゃね

392:NAME IS NULL
08/02/04 10:33:34
図面データを管理するデータベースを構築しようと思っています。

ACCESSに図面データへのパスを格納した場合、
パスに変更があったときは、sqｌか何かで簡単にデータ変更を
できるものでしょうか？

393:NAME IS NULL
08/02/04 13:08:41
>>388
不等号でいんでね？

394:NAME IS NULL
08/02/04 23:37:01
>>392

出来るだろうけど、簡単かそうでないかは
392のファイルの置き方しだい。

395:総務課ヒラ
08/02/05 20:15:25 nk3nkSEO
おじゃまします。また質問なんですが、ＶＢＡとか全く知らなくても
対処する方法があったら教えていただきたいのです。

①アクションクエリーを多用したファイルを共有して使うと、その実行
　確認メーセージについて「なんだこりは？」と頻繁に問われます。
　そのたび、「ツールのオプションの編集/検索」で確認メッセージが出
　ないように設定してもらうのですが、ファイル自体に、開くと強制的
　に「確認メーッセージ不要になる」という設定を組み込めないでしょ
　うか？

②フォームでメニュー画面を作成していますが、不要なフォームは最小
　化されて邪魔にならないようにしていても、タスクバーに表示された
　オブジェクト名の所を誤ってクリックしてしまいメニュー画面の順番
　をぐちゃぐちゃにする使用者がいます。これも「ツールのオプション」
　でタスクバーに表示させないようにできるのですが、質問①と同様に
　ファイルに強制的な設定力を組み込めないでしょうか？
　アクティブフォームを規制する方法でも良いです。
　よろしくお願いします。

>388
dateadd 関数（だったっけ）と不等号でダメ？
今、ネットカフェだからためせないんだけど。

396:NAME IS NULL
08/02/05 22:50:38
VBAを知って対処しろ

397:NAME IS NULL
08/02/05 22:50:56
MDBファイルにADO経由でアクセスして
SQLを発行しているのですが
書き込みのときはロックした方が良いとか
トランザクション作るべきだとかいわれますよね
ACCESSのSQLは文法が違うみたいなのですが
なんとかならんもんでしょうか
MSSQLとか他のSQLサーバーに城とかいうのはなしで
ご存知のかた教えていただけると幸いです

398:NAME IS NULL
08/02/05 22:55:16
MSSQLとか他のSQLサーバーに城

399:NAME IS NULL
08/02/06 08:36:56
>>395
①VBA を使った方法になるけど
　1. 警告を止めるモジュールを用意する
　　Function WarningOff()
　　　DoCmd.SetWarnings False
　　End Function

　2. 自動実行マクロから 1. を呼び出す
　　Autoexec という名前のマクロを作成し
　　プロシジャーの実行－プロシジャー名に WarningOff() を設定する

　SetWarnings の使用には注意が必要なのでヘルプを良く読んで

②操作可能なフォームを１つに限定する事はできるけど、それでいいのかな？

　フォームプロパティ－その他　作業ウィンドウ固定

400:総務課ヒラ
08/02/06 19:55:42 MFZ8If4M
>399
レスありがとうございます。
総務課員でも、やっぱ初級レベルのＶＢＡの知識は必要だと思い
始めています。勉強するつもりですが、今回は何もわからないま
まで書き込まれた方法を使わせてもらいます。
初めての体験、うまくできるか心配。

401:NAME IS NULL
08/02/06 22:46:56 zjHg3ehW
>>400
仮にも総務課なんてものがある規模の会社で、部署跨いでの運用前提なら
外注も考えた方がいいんじゃないかと老婆心。
社内に相応の作り手(とか管理者)がいるとか、使い手のレベルが確保できるなら別だけどね。

402:NAME IS NULL
08/02/07 00:12:11
URLﾘﾝｸ(soumubu.sigoto.jp)

でも社員数11人なんだぜ

403:NAME IS NULL
08/02/07 12:05:45 EaJqlF2t
私はこれのせいで、リストラされました、勉強しようとしても自学では難しかった、学校に行こうとしたが試験に落ちた、後はどうにもならなかった。後はどうにもならなかった。後はどうにもならなかった

404:NAME IS NULL
08/02/07 17:35:48 Xa53OaUG
すいません気が狂うほど初心者質問ぽくてあれなんですが・・・

フォームのテキスト群に数値の[1]か[0]を表示させて、別のテキスト（レコードあり）にその加算をだすように
そのコントロールソースに　=[テキスト○○+[テキスト○○]+[テキス・・・・などと書き込んでフォームを
開けてみると、加算されず「00110100011000・・・・」などとなってしまいました。
なぜなのかわかりません、どうかお教えください。

405:NAME IS NULL
08/02/07 19:06:04
>>404
まず、基本的にテキストつまり文字列は計算できません。
これはAccessに限らずコンピュータの初歩の初歩です。
"国道１号線"と"国道２号線"を足したら"国道３号線"になりますか？ならないでしょう？
Accessでは"国道１号線"＋"国道２号線"は"国道１号線国道２号線"となりますが、
これはAccessではそう決まっているというだけのことです。
この場合の解決策はフォームのテキスト群をすべて数値に変えるか？
それともテキストを数値に直してから計算するようにするかです。
初心者ということですが、数値とテキストの使い分けができないとAccessはとても使いこなせませんよ。

というようなことでいいのか？

406:NAME IS NULL
08/02/07 21:26:09 Xa53OaUG
>>405
早速のお返事ありがとうございます

文字列の問題・・・・やはりそうですよね、そうではないかとおもっていました
初心者といえ、ここまで顧客管理と役所に申請するソフトを作り上げて
最後の部分なのに、あまりといえばあまりな基本ですね・・・恥ずかしい。

一応、テキスト群のほうの書式は「数値」というふうに設定したのですが
根本的にわかっていないっぽいですね、わたし。

407:404
08/02/07 22:06:50 Xa53OaUG
もしかして・・・・

テキスト群はフィールドのないフォーム上だけのテキストボックスだから
「数値」としての認識はできないのでしょうか。

408:NAME IS NULL
08/02/07 22:13:57
a = CInt(form![hoge].caption)

409:404
08/02/07 23:17:04 Xa53OaUG
>>408
CInt関数ですね

って調べてみたけど、まだ私のスキルではうまく理解して使いこなせなさそう

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
入力と印刷のたびにファイル変換してる。

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

次ページ