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

>>930
はい出てきません。

それならInStr関数を使って　[　と　]　の位置を調べれば出来ると思うけど。
複数回でてくるからループさせなければいけない。

>>933
なるほど、　複数回実行が面倒ならVBAで、
]　が含まれる間、ループさせればいいですね。
参考になりました、>>923様、皆様ありがとうございました。

>>934
おいおい>>923様って・・・・・

>>933様の間違いでした；失礼しました。

アクセスはとぐろうんこだ、桐はまぐそだ　に汁

【汎用のAccess】アクセスは誰でも使えるデータベース！【孤高の桐】

>>919
同感。問題点はどのソフトにも有るが、最終的な決め手は情報量。わかりやすい参考書がいくらでも有る。
他のメーカーが新しいソフトを普及したいなら、良い参考書を沢山出版する事を真似よ。

パソコン販売
http://www.fujishoweb.jp/luckyworks_web/

>>919
なるほど。とりあえずAccessでググれってことですね。
やってみます。
ありがとうございます。

>>939
あえて逆に言うと、そういう情報がないとAccessは使い難いソフトとも言える。
特に突然壊れて開けなくなったりするのが何回か続くとこりゃ使えないってことになる。
初心者はプログラムとデータを分けたりしないだろうから、これは辛い。

まぁ、Accessほどバッドノウハウが溢れてるアプリもないだろうとは思うよ。

ACCESSってスタンドアロンで使ってても
壊れたりするのですか？

>>944
するよ。桐だって壊れる時は壊れるのだけど、Accessは１ファイルにまとまっているから被害が大きい。
まあ、そうならないためのノウハウはあるんだけどね。

Accessの長所はなんと言っても帳票ですな
慣れのせいかも知れんけどこれ以上楽に帳票作れるツール
あったら教えてほしい

>>946
桐の信者じゃないけど、これはやっぱり桐なんだよなあ？
なんたって日本で初めてパソコン用ワープロを作ったところだけあって
痒いところに手が届くようなところがある。
だから、入力と計算処理は他でやって結果をCSVで桐に渡して
印刷だけ桐でやろうかなと思ったりした。
まあ、それもちょっとなんだかなあということで止めたのだけど、
可能は可能。

>>946
桐使ってみたことないの？

>>948
そういう言い方が桐と桐ユーザーのイメージを悪くしているのだが、わざとやっているのか？
桐も使っている一ユーザとしては非常に不愉快なんだけど。

桐って何よ？
俺、使ったことないよ。

桐について語るスレ？
http://pc11.2ch.net/test/read.cgi/db/1057318214/

専用スレあるんだからそっちでやってください。
営業熱心なのはいいけど、ほとんどの人は見たことも触ったこともなく買う気も全くないのですから。

>>951
つうかこいつら本当に桐ユーザーなの？
桐のこともろくに知らないって気がするけど？
ただの基地我意じゃないのか？

桐といえば箪笥

>>947
>だから、入力と計算処理は他でやって結果をCSVで桐に渡して
>印刷だけ桐でやろうかなと思ったりした
入力と計算処理は何で？アクセスで？
入力や計算処理でアクセス(その他?)が優れている点でどのあたりですか？

自分は桐からの移行を考えているので教えてください

いやＡｃｃｅｓｓが良いのは連携機能だけだし

>>954
Accessの利点は汎用性。ドキュメント豊富、ネット上でのノウハウも豊富。ついでにバグも豊富ｗ
ユーザも豊富だから、おまえがいきなり死んでも誰かが引き継げるぞｗ

桐だと使える奴探すのがまず難しい。普通の会社じゃまずいないなｗ

> ユーザも豊富だから、おまえがいきなり死んでも誰かが引き継げるぞｗ
データベースとしては、最も重要な点だ。

>>956
自分がいなくても十分運用はされていけます
改造は厳しいでしょうけど
あなたがいないと運用もできないの？

桐って超簡単だから、誰でも引き継げるよな

>>958
>改造は厳しい

この時点で仕様変更ができないんだがｗ
通常運用の話じゃなくて、改修、メンテナンス、バージョンアップ、サーバ移行等々
どうするつもりなんだ。おまえ、システム系の人間じゃないだろ？

Accessなら、たいていの技術者なら大丈夫。桐ならあえて使える奴を探さなきゃならない。
潜在的に桐が使える奴は死ぬほどいるだろうが、実務経験者は極端に少ない。

うんこが正しい

底辺同士の戦いｗｗｗｗ

ランタイムまだぁ

>>954
> 入力と計算処理は何で？アクセスで？
まあ、アクセスとは言ってないのだけどね。その時は別のものでやるつもりでした。

> 入力や計算処理でアクセス(その他?)が優れている点でどのあたりですか？
桐の入力も悪いわけじゃない。
上の行を簡単に複写できたりするのは便利だ。
ただ、やっぱり慣れないとちょっと抵抗がある人もいると思う。
アクセスはそんな便利な機能は標準では無い。
VBAを駆使すれば出来ないことではないけれど。
まあ、これは重大な問題とは思ってないのだけど・・・・・
計算処理は正直桐よりAccessのほうが良いかな？
AccessというよりSQLなんだけどね。
処理にもよるけどSQLだと何千件のデータをほんの短時間で処理できることがある。
桐のつもりでこれくらいは時間がかかるだろうと思って作っていると
良い意味で裏切られる。

> 自分は桐からの移行を考えているので教えてください
うーーーん、自分もその道を通ってきたのでダメとは言わないけど、
考え方が全然違うから苦労するよ。
とにかく桐のことはすっかり忘れて一からやるつもりでがんばってください。

>>964
>AccessというよりSQLなんだけどね。

意味不明。Jetが早いとか言いたいのか？

>>965
桐にはSQLという考え方がないから別のやり方を取るのだけど、
それよりはSQL（つまりクエリー）でやったほうが早いことが多いという意味。
それと桐はテーブルの中に計算式を持つのだけど、
これはExcelライクでちょっと使うのにはとても便利。
だけど、プログラムとデータが分離されないわけだから開発者としては困った仕様。
桐が良くないと言うより、目指す方向が違う。
Accessマンセーも桐マンセーも無知をさらけ出しているとしか俺には思えない。

＞桐にはSQLという考え方がないから

ちょ・・・

何でもかんでも正規化する時代は終わりました
正規化が必要なのはメモリーやＨＤＤが高価だった昔の話です
今は、運用のし易さ優先で設計してください

>>967
あると言いたいのか？なら聞かせてもらいたいけど？

>>967
結合表とか言うつもりじゃないよね？


>>964さん　もうちょっと語って欲しいです
移行時に特に困った点とか

>>970
どこに困ったもなにもまるで初心者。
おなじところなんかあるかよって感じ。
とにかく初心に戻ってという感じかな？
いまでもそうなんだけど、なんで一つのファイルにまとめる必要があるのかわからない。
正直言ってこれだけは変えて欲しいなあ？
ひとつのオブジェクトはひとつのファイルのほうが俺は良いなあ？
Excelを意識したのかなあ？そんなところだけ真似てもなあ？

>971
テーブルごとにばらけてたらデータベースを移行したときに参照先を変更するのが面倒じゃない?
インデックスやフォーム、コントロールとかまで単体のファイルに分かれてたりしたら頭髪的に
チャレンジすることになりそう。

>>972
> >971
> テーブルごとにばらけてたらデータベースを移行したときに参照先を変更するのが面倒じゃない?
データベースを移行ってどういうときのことを言っているのか、いまいちわからない。
> インデックスやフォーム、コントロールとかまで単体のファイルに分かれてたりしたら頭髪的に
> チャレンジすることになりそう。
頭髪的にチャレンジってのもますます謎だ。

さっぱりわからないが、Access以外のデータベースは皆バラバラだが特に問題があるわけじゃない。
まとめたいならひとつのディレクトリに入れればいいだけだと思うけどなあ？

>>973
> Access以外のデータベースは皆バラバラ

違う。
OracleもSQL Serverも
表領域とかデータファイルとかのレベルでは
「ひとつのオブジェクトはひとつのファイル」
ってことはない。

ACCESSだってリンク使えば、
オブジェクトごとにバラすことも可能だしな。
むしろ、今のご時世だからこそ、
小容量のファイルが大量に出来る方が管理が大変。

# 同一ディレクトリに大量にファイル作ると
# NTFSでもI/Oのパフォーマンスが落ちる。

>>974
すまん。OracleとかSQL Serverとかは全然考えてなかった。
あくまでもAccessと同等と思われるものについてしか考えてなかった。
なるほどパフォーマンスが落ちることもあるのか？
それは認識不足でした。失礼しました。

Ａｃｃｅｓｓは残高･累計計算も出来ない時点でウンコ

うんこ　うんこ　うんこスレ

ｽｶﾄﾛﾏﾆｱ ｷﾀ━━━━━━━━━(ﾟ∀ﾟ)━━━━━━━━━ !!!!!

今日はあさからウンコ大量だなｗ

SQLの概念が存在しないうんこDBと同列で比較されてる時点でうんこ

ＳＱＬなんか介さなくとも、ＡＣＣＥＳＳのクエリより、桐の絞込み並べ替えの方が速いよ