Accessはほとんど初めてなのですが、会社でAccessを使ってDBを作るよう指示されました。
まず、テーブルを顧客情報・商品・見積・見積明細などに分けて組み立て、商品テーブルに販売価格や仕入価格などを入れて見積に反映させました。

ところが、商品の売買だけで無く、その商品に対する修理やアフターサービス、また全く別のイレギュラーな仕事など、そのような様々な事案についてもひとつのDBにしたいという事でした。
この場合、今出来ている商品テーブルとは別にその他の事案のテーブルを作れば良いのでしょうか?
その場合、見積テーブルはまた別に作るのでしょうか?
さまざまな案件に関して、どのようにテーブルを作って関連づければいいのかわかりません。

アクセスはほとんど独学で、PCにもあまり詳しくないのでうまく説明できていないかもしれません。
要するに、必要なのは会社の収益になる品物や、サービスや、その他もろもろをすべてひとつにDB化し、見積書・契約書・粗利計算書などが出せるDBです。
また、定期的に販売した商品に対してサービスの案内をするためアラートをつけたいと言われていますがそのようなことは可能なのでしょうか?

本当に初心者で本を読みながらやっています。
現在すっかり混乱してします。どうしてもここからの構築方法がわかりません。
質問の意味がわかっていただけると嬉しいです…。
よろしくお願いします。

このQ&Aに関連する最新のQ&A

A 回答 (7件)

>についてもひとつのDBにしたいという事でした


と言っているのはデータベースやシステムを判っている人(経験者)か。
1つの.mdbにまとまっていれば良いとぐらいに解釈すべきでは。テーブルを無理して、色々違う(何を以って違うというか経験が必要だが)情報をぶち込むと困ることになる。先人の経験で言われているとおり。
リレーショナルデータベースのテーブルを分けるという発想も、相当訓練しないと出てこない発想だと思う。一般には総合とか称して、何でもそこに有るイメージを持ちやすい。
>ひとつのDB
>もろもろをすべてひとつにDB化し
はそういう気分を言うのだろう。
しかしテーブル面では分けるべきものは分けないといかん。
ーー
テーブル関係について
事業活動で
(1)商品の売買
顧客情報・商品・見積・見積明細
商品テーブルに販売価格や仕入価格
==>一応出来上がっている
(2)商品に対する修理やアフターサービス
==>これから作る
(3)全く別のイレギュラーな仕事
は何を言うのか読者にはわからない。
ーー
質問の主要事項は(2)だとすれば
質問者の会社で主体は、顧客、商品どちらでしょうか。やはり顧客かな。(社内で話題になるのは、XX社のyyの件が多いのか?YY商品はどうなっているのか?利用時には、それらをつなぐものがいるでしょうね)
(2)では必要なテーブルを作る。同じものは(1)を使う。
この検討をすれば仕舞いでしょう。
後はアクセス直接触るシステムを作る担当者の話で、良くわからない上司などに惑わされるな。テーブルの結合をして、情報を揃えればよい。
ーー
>定期的に販売した商品に対してサービスの案内をするためアラートをつけたいと
こんなの月次作業で条件をかけて、クエリで抜き出しをおこない、社別のレポートを印刷とかの話で、根幹を左右する話ではない。
頭を混乱させず冷静に。
ーー
重複情報を持たない、出来るだけテーブルを連携して、望みの項目を揃える。
ーーー
それより、お偉いさんは、ほしいことだけ、のたまうが、入力の便利さ省力性、早期データ提出、関係者の提出の締め切りのばらつきをなくす、業務の実行と同時にデータ化されることを目指すことだ。
システムが腐る(使えないと不平が出て、使われなくなるのは、この面からが多い)。
例えばお客から修理要求があれば、まずコンピュターにデータを入れないと修理が進まないように仕組むことだ。従事者がそれをしないと決定的に困るようにすることだ。例えば受注したらコンピュターに入れないと、商品が発送されず、先方から大目玉を食らうように仕組むことだ。商品以外などでは、コンピュター処理とは別に、行動面でちゃんと修理をやって、対お客様では済んだことにすることも可能。しかしデータはコンピュタに入っていないとか。
もうひとつどうしてもまとめて入力する部分が残る。専任の入力担当者を手当てすること。兼任させると、どうしても遅れたりおろそかになる。
アクセスのテーブルなど2の次。アクセスの難しさに気を取られ、アクセス馬鹿になるな。実際動かしてれば欠点誤りには気づかしてくれるから
そのとき自分で改良すればしまい。それより体制と言うのは、偉いさん(あれもこれも途といい勝ち)が言うだけの実施面で空回りの恐れが多い。
    • good
    • 0

補足です



Oplockの問題は、クライアントサーバもどきにしないなら必要ないです。逆に、複数のパソコンで同時処理したいような場合には必要です。

そのほか、クライアントサーバもどきにする場合は、
無理にすべてを一つのファイルでやろうとすると失敗することがあります。
(メンテなどの都合上、オールインワンにすると業務が止まるため。
 また、1つのmdbファイル内にテーブル、フォーム、クエリなど、
 数が増えれば増えるほど管理しづらくなり、ミスやトラブルを
 誘発します )

データの件数をよく考えながら、場合によっては、顧客は顧客のmdbだけ、各トランザクションはそれぞれ独立させて・・・、という形のほうが良い場合もあります。

各テーブルを1つのmdbに独立させた場合、参照整合性が設定できなくなるので参照整合性が取れる機能を自前で作らないといけなくなりますが、自分で作れればとくに問題は無いと思います。

最適化やバックアップも1日1回程度は行って。

また、ネットワーク越しの
リンクテーブルの速度が異常に遅くなることもあります。
その際はこちらをご参考に
http://support.microsoft.com/kb/838670/ja

クライアントが多い時やデータ件数が多い時は、これ以外にも
クエリやテーブル動作を早くする方法がありますが、
それらはまた問題が起こったときに聞けばよいと思います。
    • good
    • 0

>そのようなことは可能なのでしょうか?



可能ですけれども、規模にもよります。
もしあまりAccessのことを熟知していないのでしたら、
パソコンの台数が5、6台以下の場合までを想定されるとよいと思います。30台くらいまでは大丈夫ですが、件数が1ファイル5万件を超えたあたりや台数が7、8台を超えたあたりから、作り方を注意しないと動きが遅くなります。

・顧客マスタ
・商品マスタ
・見積関連のトランザクション
・売上(成約?)関連のトランザクション
  (↑顧客マスタとは関連しているイレギュラーな仕事なら、
   ここに含めてもいいかも。切り離してもいいですが。)
  客先情報などの概要トランザクションと
  売上商品明細のトランザクションなど。
  売上のメインとサブ
・修理やアフターサービス関連のトランザクション

>見積書・
見積のトランザクションで管理

>契約書
売上関連のトランザクションで、契約書のファイルのフルパスを記録して契約書をリンクさせるようなかたちで管理

>粗利計算書などが出せるDBです。
売上関連のトランザクションで、定価ではなく販売価格や値引き、仕入れ値などを記録して管理

>また、定期的に販売した商品に対してサービスの案内をするためアラート
見積を売上トランザクション(概要と明細ともに)に転記して、
もし修正があれば修正し、売上トランザクション(明細部分)の
販売日付を基準値に、年数などを計算してアラートもしくは、
TELリストなどを出力

というような感じでできるのではないでしょうか?

適当に書いてしまったので参考程度にしてください。

簡易的なクライアントサーバにする場合は、
サーバ側のレジストリをいじらないとファイルが頻繁に壊れることがあります。その際は サーバ側 の Oplock のレジストリ設定を変更してください。

参考
http://support.microsoft.com/kb/303528/ja の
ネットワーク ファイル サーバーでの Opportunistic Locking (Oplock) 
のあたり。
    • good
    • 0

会社の規模や業種(販売だけなのか製造からなのか、販売先は固定した取引先だけなのか一般顧客が対象なのか)などにもよりますが、


最初に取り掛かるデータベースとしては大変です。
Accessで大丈夫か(Webなどを通じて作業を行う必要性があるのか)なども重要です。
Accessだけの知識ではなくネットーワークに加えて経営から会社全体の作業まで把握する必要があります。
既にNo1の方もおっしゃるとおりです。
ましてやイレギュラーな仕事はテーブルのリレーションや正規化するのが厄介です。
下手にシステムだけを最優先に決定してしまうと営業活動や開発など
無理が利かなくなったりします。
商品テーブルと取引先テーブルを作成して、売上(出荷)のテーブルをリレーションで作成するところ辺りからスタートしては如何でしょうか。
修理サービス、見積書などは他のデータベースとして分離、商品テーブルなど共有できる部分だけ共有する方向で後々、発展していくような方法が良いと思います。
一つのデータベースで行うのではなく、複数のデータベースに分けて、それぞれがテーブルを共有するなどしながら発展して行くことを検討してもらったほうが失敗が少ないのではないでしょうか。
別のデータベースで修理品のテーブルを作成して商品のテーブルだけを共有するとかしながら発展させていきます。
最初からしっかりとと云われるのであれば、それなりのプロの力を借りるべきです。
テーブルの構成の決定はPCの勉強以上に、経験や会社の経営などまで含めて深い知識が必要で、誤ると経営まで悪くしてしまいます。
    • good
    • 0
この回答へのお礼

そうですよね。もっと勉強してからすべき仕事だとは私も思うのですが…
皆さんおっしゃるようになるだけ小分けして後でどのように展開しても極力困らないように作ってみます。有難うございました。

お礼日時:2009/05/17 22:39

専門家ではありませんので、的確なアドバイスはできませんが、おそらくリレーションシップというものについて勉強されると見通しがよくなるのではないかと思います。

多様なデータをどのようにテーブルに分けて表現し、またそれらのテーブルをどのように結合して利用するかということです。

ただ、入門レベルでは、まずリレーションシップを使わない、簡単なデータベースの作成と利用(操作)から入り、そのあとでリレーションシップの学習に進んでいくのがよいのではないでしょうか。初心者向けの解説本はそのような構成になっているものが多いように思います。

たいへんさはお察しいたしますが、重要なお仕事であることは間違いありません。がんばってください。
    • good
    • 0
この回答へのお礼

リレーションについては本を読んで見ましたが、難しくて…。
期待されていると思って頑張ります!有難うございました。

お礼日時:2009/05/17 22:36

アフターサービス、アラートについてコメントします。


このためには5つのテーブルを作ります。
1.販売先テーブル 顧客名、ID、住所、電話番号など
2.生産者テーブル 生産者名、ID、住所、電話番号など
3.商品テーブル 商品名、ID、など
4.販売テーブル 期日、商品ID、生産者ID、顧客ID、仕入れ価格、販売価格など
5.修理テーブル 期日、商品ID、顧客ID、故障原因など。故障原因はユーザーミスかメーカーミスか、耐用年数によるものかをはっきりさせる。
こんなデータベースがあれば、ある商品についてある故障が出た場合、原因がメーカーミスであれば、販売テーブルで同じ商品を納めている顧客を抽出して、その顧客に商品交換などの処置を取る。原因が耐用年数によるものであれば、販売テーブルを見て、同じ商品について納品期日の古いものを抽出して、更新を助言などの処置を取ることができます。
    • good
    • 0
この回答へのお礼

そうですよね、やっぱりテーブルを分離させて、リレーションさせていくべきですよね。具体的なご意見有難うございました!

お礼日時:2009/05/17 22:35

それはまずAccessに限らずデータベースの設計そのものです。


教育や訓練を受けずにいきなり仕事を一人で着手するのは
かなり厳しい環境です。同情します。混乱して当然と思います。

一般的にシステムを企画から運用まで10のフェーズに分けます。
Accessの設計といえばプログラム設計のフェーズ4あたりに
なろうかと思います。
データベースの設計はフェーズ3のシステム設計です。
しかし、その前にデータベースの論理設計が必要で、これは
フェーズ2の要件定義で確立しておきたい事案です。
論理設計がどうしても上手くいかない場合、企画そのものを
見直す必要があるからです。

常に現フェーズは前フェーズの結論に対して検証及びフィード
バックが必要です。これは予算やスケジュールで確保する問題
で、頭の悪い役員を説得する必要のあるタフな仕事です。

また、上司が口頭であれこれ言っているのをフェーズ1の企画
と捉えて、あなたが企画書をまとめた方がいいと考えます。
そして、要件定義書ですね。

企画段階から矛盾が必ずあると私は言い切ります。その矛盾を
明らかにし、企画のコンセプトを打ち出し(価値観)、コンセ
プトから企画の方向修正をし、上司に提案する必要があります。

データベースの基本的な考え方は、あなたの会社を中心とした、
取引会社と顧客の世界と商品を表現することです。
1つのテーブルには何もかもを詰め込まない、テーブルを
分けて、各テーブルはキーによって結合します。

現帳票や将来必要な帳票の全ての項目を洗い出し、単なる
項目とキーたる要件を持った項目に分けて、キーに着目します。

このテーブル分割が上手くいくと、将来の環境の変化に対する
システム修正に強いデータベースになります。柔軟性が高い
ということです。
殆どのシステムは、決め付けの固まったデータベースが、シス
テム開発中に既に世の中の変化に付いていけなくて、運用前に
使い物にならないことに気が付いたりするものです。

日本の多くのシステムがバブル崩壊のあたりから、少品種大量
生産から、多品種少量生産に社会に要求され切り替えようとし
ましたが、データベースがガチガチでシステムが付いてこれま
せんでした。

それで論理データベースの設計は、テーブルとテーブルの関係が
キーで結ばれますが、これがm対nにならないよう常に1対nにす
る必要があります。
例えば商品コードで結ばれたテーブル同志は、片側は同じ商品
コードのレコードが複数あっても構いませんが、片側は必ず1
レコードになるようなテーブルの意味になっていることです。

このモデルは最初は単純化し、テーブル名と概要とキーだけで
各テーブルの関係を線で結びつけて全体を見てみましょう。
どのテーブルのどのキーが1でどれがnか図の中に書いていきます。
いきなり細かい項目まで見る必要はありません。
木を見て森を見ず、になりますから。

データベースはあくまでも世界の模写です。
それに対して各機能がどのテーブルから取り掛かると必要な
データが得られるかが、スラスラ言えれば1面成功です。
データベースの設計がしっかりしていればするほど、機能の
実現が楽になります。
データベースが中途半端ですと、本来データベースが行わなけ
ればならないことを機能(プロセス)で行うことになり、開発
コストがかかる上、環境の変化に弱くなる訳です。

最初は細かくなりすぎるぐらいテーブルを分けてもいいでしょう。
少しずつ、何かが見えてきます。それは開発対象を理解する
糸口です。一方向だけでなく、多く方向から何かが見えて、
理解するものが生まれたら成功でしょう。あなたはそのころには
立派な設計者になっていると思います。
べき論を口にしだします。その頃が初心に帰るタイミングです。

まあ、一朝一夕では無理ですので、腰を落ち着けて頑張って下
さい。

テーマが大きく、短い時間で執りまとめが無いのは失礼します。
    • good
    • 0
この回答へのお礼

考える論理をたくさん教えていただいて有難うございます。道は険しいですが、こつこつやってみます。こんなことくらいは簡単なことだろうとほざいている上司に負けません!(笑)

お礼日時:2009/05/17 22:34

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

Q論理的思考力、問題解決力、分析力。 これらが必要とされ、また活かすことが出来る職業(ex.プログラ

論理的思考力、問題解決力、分析力。

これらが必要とされ、また活かすことが出来る職業(ex.プログラマー、コンサルタント)あるいは職種(ex.営業職、マーケティング職)は何だと思いますか。

漠然とした質問ですが、皆さんの様々なご意見を頂きたいです。宜しくお願いします。

Aベストアンサー

職業で「論理的思考力、問題解決力、分析力」だけですと、顧客満足度と云うものに対して不足します。若い人は嫌がりますが「経験値」と云うものも要求されます。本来的なコンサルタント業務では会社が独自に開発したプログラムや過去実績・経験累積に従って分析し問題点を明確にし、その問題点の解決方法論を提案しますが、その時、相手の置かれている状況に応じて最適解を提示できれば顧客満足度は上がり、目的を達成できます。他方、相手に合わせた最適解を提示出来なければ絵に描いた餅です。典型が地方公共団体が求める地方活性化への提案です。本来ですと活性化の成果が重要ですが、ともすれば予算消化の書類作りと云う方向に走ります。
ここで示したことはある種のコンサルタントのさわりですが、社会活動により何を目的とするかを明確にし、経済的な便益を主眼に据えれば、貴方に「論理的思考力、問題解決力、分析力」と云う能力があれば、大方の社会活動の場面に有意義だと思います。他の皆さんが指摘にするように、すべての職業に向くでしょう。
なお、質問者が学生さんで来年への就職活動の参考を求めているのなら、外資系や伸び盛りの企業の人事は「論理的思考力、問題解決力、分析力」に「経験値」が加味されなければ、その人材は事務的な作業員(StaffとOffice Clarkでの区分)に過ぎないことを知っていますから、早い段階から「経験値」を積むプログラミングを組みます。これは職種においてもコンサル、出版、イベント企画、物販、製品開発、製造、建設などの分野は問いません。自己に自信があれば外資系や伸び盛りの企業で早期に「経験値」を積むことをお勧めします。自信がなけれな「寄らば大樹の陰」をお勧めします。ただ、お若い方なら、40年先、何が大樹となるかは難しいところです。40年前、産業では砂糖・セメント・繊維が旧帝大系の人気産業でした。ただし、早期に「経験値」を積むには、外資コンサルの人や有名なソフト開発者のように、非常なブラックな生活を要求されます。

職業で「論理的思考力、問題解決力、分析力」だけですと、顧客満足度と云うものに対して不足します。若い人は嫌がりますが「経験値」と云うものも要求されます。本来的なコンサルタント業務では会社が独自に開発したプログラムや過去実績・経験累積に従って分析し問題点を明確にし、その問題点の解決方法論を提案しますが、その時、相手の置かれている状況に応じて最適解を提示できれば顧客満足度は上がり、目的を達成できます。他方、相手に合わせた最適解を提示出来なければ絵に描いた餅です。典型が地方公共団...続きを読む

Q別のテーブルから別のテーブルへデータを保存する方法

Access2002です。
二つのコンボボックス、大・小でそれぞれ絞り込みを行なうようにしています。
大で絞り込んだ結果が小に反映されるのですが、追加で新しい項目も登録させたいです。
その際に、次に絞り込みを行なうときに新規で小に追加された項目が、大を選んだ後にきちんと表示されるようにしたいのですが、その処理をどうすればいいのか分かりません。

それぞれ番号を振ってあるので、小に新規登録するときに、その時点で選択されている大の番号を自動で取得し、小のテーブルに入れられればと思っています。

大テーブル
・大項目コード(オートナンバー型)
・大項目(テキスト型)

小テーブル
・小項目コード(オートナンバー型)
・小項目(テキスト型)
・大項目コード(数値型:ここに大テーブルの「大項目コード」を入れたい)

テーブルは上記のようになっています。
絞り込みは下記のように、大・小ふたつ分記載してあります(名前以外は同じです)


Private Sub コンボ大_NotInList(NewData As String, Response As Integer)

Dim strmsg As String
strmsg = "登録されていない語句です。保存しますか?"

If 1 <> MsgBox(strmsg, 1) Then
Response = acDataErrContinue
Me.コンボ大.Undo
Else
DoCmd.SetWarnings False
DoCmd.OpenQuery "追加クエリ"
Response = acDataErrAdded
DoCmd.SetWarnings True

MsgBox "登録しました。"
End If

End Sub

追加クエリはフィールドに『式1: Forms!入力フォーム!コンボ.text』、レコードの追加には『大項目』としています。小も同様です。
現在は別のテキストボックスに大の『大項目コード』を表示させ、そこから小のテーブルに入れられないかと思ってます。テキストボックスに表示させるのは出来ました。
その値を、小に新規で項目を登録する際に、一緒に小テーブルに入れられればと思っていますが、実際にどうすればいいのか、、ネットや本で調べてみましたがさっぱり分かりません。
望む結果になれば方法は問わないので、お知恵を拝借できればと思います。
分かりづらい文章かもしれませんが、よろしくお願いします。

Access2002です。
二つのコンボボックス、大・小でそれぞれ絞り込みを行なうようにしています。
大で絞り込んだ結果が小に反映されるのですが、追加で新しい項目も登録させたいです。
その際に、次に絞り込みを行なうときに新規で小に追加された項目が、大を選んだ後にきちんと表示されるようにしたいのですが、その処理をどうすればいいのか分かりません。

それぞれ番号を振ってあるので、小に新規登録するときに、その時点で選択されている大の番号を自動で取得し、小のテーブルに入れられればと思ってい...続きを読む

Aベストアンサー

> 追加クエリはフィールドに『式1: Forms!入力フォーム!コンボ.text』、
> レコードの追加には『大項目』としています。小も同様です。

でしたら、『小テーブル』用の追加クエリに、もうひとつ列(フィールド)を追加すれば、
コードの方は特に触らなくても対応できるかと思います。


そのクエリをデザインビューで開いたら、以下のように「式2」の列を追加します:

   フィールド: 式1: (下記参照) 式2: (下記参照)
    テーブル:
    並べ替え:
レコードの追加: 小項目      大項目コード

・「式1:」の式部分:
  Forms!入力フォーム!コンボ小.Text
・「式2」の式部分:
  Forms!入力フォーム!大コード
  (大項目コードを表示させたテキストボックスの名前が「大コード」の場合)


・・・以上です。


要するに、

> 新規で項目を登録する際に、一緒に小テーブルに入れられればと思っています

という場合は、上記のように、必要なフィールド群を順次横に並べてやればOKだと
いうことです。

・・・質問の趣旨を誤解していたらすみません(汗)

> 追加クエリはフィールドに『式1: Forms!入力フォーム!コンボ.text』、
> レコードの追加には『大項目』としています。小も同様です。

でしたら、『小テーブル』用の追加クエリに、もうひとつ列(フィールド)を追加すれば、
コードの方は特に触らなくても対応できるかと思います。


そのクエリをデザインビューで開いたら、以下のように「式2」の列を追加します:

   フィールド: 式1: (下記参照) 式2: (下記参照)
    テーブル:
    並べ替え:
レコードの追加: 小項目     ...続きを読む

Q「eX.computer」は、なんて読むのでしょう

「eX.computer」は、なんて読むのでしょうか?
何コンピューターでしょうか?

Aベストアンサー

イーエックスコンピュータ ですね。九十九の。

Qアクセスのテーブルに別のテーブルを加えて一つのテーブルにしたい

エクセルファイル内の複数のシートをインポートして複数の同じフォーマットのテーブルを作る所まではできました。次のその複数のテーブルをまとめて、一つのテーブルにしようと思ったのですが、その方法がわかりません。どなたか教えてください。

Aベストアンサー

インポート済みのテーブルの
フィールド名・データ型・並び順が一緒だとして
ユニオンクエリでまとめてからそのクエリを元にテーブル作成クエリを作成しては?
クエリのデザインビューでは出来ないのでSQLビューで行います。

select * from テーブル名1
union all
select * from テーブル名2
union all
select * from テーブル名3
;

↑をテーブル名を実際のものに替えて
SQLビューにコピペ。このクエリが出来たら後はテーブル作成クエリですが
クエリウィザードで出来ると思います。

Q彼女さんのすっぴんをみて驚いたこと、がっかりしたことを教えてください。 ex.目の大きさがちがう

彼女さんのすっぴんをみて驚いたこと、がっかりしたことを教えてください。

ex.目の大きさがちがう

Aベストアンサー

すごい美人のギャル系の子だったが、メイクをとると眉毛無しでつけまつげもなしで
怪談話に出てくるようなお化けのような幸薄そうな顔だった事。

Qテーブルの一部を別のテーブルを使って更新したい

テーブルA…[住所]、[氏名]、[電話番号]、[携帯番号]、[変更日]
テーブルB…[氏名]、[自宅電話・携帯番号]、[変更日]

Bの[氏名]と[自宅電話・携帯番号]が、Aの[氏名]と[電話番号]、[携帯番号]に一致した場合、Aの[変更日]がBの[変更日]に更新されるようにしたいです。

以前、似たような質問で回答して頂いたのですが、条件が二つになり指定方法が上手くいかなくなってしまいました。

お手数お掛けしますが回答宜しくお願いします。

Aベストアンサー

UPDATE TBL_B
INNER JOIN TBL_A
ON ((TBL_B.自宅電話・携帯番号=TBL_A.携帯番号) Or (TBL_B.自宅電話・携帯番号=TBL_A.電話番号))
AND (TBL_B.氏名=TBL_A.氏名)
SET TBL_B.変更日 = TBL_A.変更日;

こんな感じかな?SQLビューでしか編集できません。
一応検証はしましたが自信が無いので、
バックアップを取って実行し、検証もしつこい位に行ってください。
当方Access2002

Q例えばフェラーリF430に最も安価なオイル(ex.4L缶780円)でオイル交換

例えばフェラーリF430に最も安価なオイル(ex.4L缶780円)でオイル交換しても、故障・燃費等何の問題も『全く』ありませんか?

Aベストアンサー

所詮オイルです。
油が入っていれば問題無く動きます。
その問題というのはフェラーリに限定したものではなく、
たとえばカローラに入れたとしてもサーキット走行やシビアコンディションで走行したならば当然問題が発生します。
つまり車種を限定するものではなく走行状況による影響のほうが大きいということです。
もちろんハイスペックなオイルよりも性能が劣るのは言うまでもないことです。
付け加えて粗悪なオイルならばどんな車であっても問題です。

Qアクセス フィールド名変更と別テーブル作成 access2010です。 既存テーブル名:AAA 既存

アクセス フィールド名変更と別テーブル作成



access2010です。

既存テーブル名:AAA
既存フィールド名:あああ

これをレコード内容、型式を変えずに別の新テーブルに新フィールド名で作りたいです。

新テーブル名:BBB
新フィールド名:かかか

よろしくお願いします。

Aベストアンサー

テーブルを構造とデータを含めてコピーして、フィールド名を変えればよいのでは?

Q九十九電機  eX.computer B30A / DualCoreモデル

PCを買いたいのですが今までメーカー製しか買ったことありません。
ショップブランドは初めてなのですが九十九電機eX.computer B30A / DualCoreモデルの評判や九十九電機の評判を教えてください
よろしくお願いします

Aベストアンサー

自作経験者としての見方になりますが、九十九の商品ページを見る限りケチをつけられそうなパーツは少ないように思います。光学ドライブが標準だと一世代古い点、HDDのメーカー指定が利かない点くらいでしょうか。
で、パーツさえまともなら組み立て段階でトラブルを起こす方が難しいのが自作の常ですし、完成品としてもおそらく品質的に問題はないものと思います。

あとはサポート体制などの評価になりますが、これについてはちょっとわからないですね。自分が店舗を利用した限りでは九十九の顧客対応に不満を感じたことはありませんが、通販になるとちょっとわからないです。

Qaccess超初心者です! すみませんが教えてください。。 1のテーブルには 日付と商品区分と商品と

access超初心者です!

すみませんが教えてください。。

1のテーブルには
日付と商品区分と商品と売上があります。
売上ない日もあり、日付は飛び飛びです。
で、一か月全日の日付カレンダーをテーブル2として作りました。

あとは2つのテーブルを繋げ、
売上ない日は空白表示させたいのですが。。

1.2の日付をリレーションし
2つを繋げたクエリ1の結合プロパティは1の全レコードと2の…にチェックをいれました。

SQLビューの中は
FROM テーブル1 LEFT JOIN テーブル2 ON テーブル1.日付 = テーブル2.日付
としました。
これで空白も表示されました。


問題は、最後に商品区分毎に絞りたいので、
区分の抽出条件にいれこむと、空白が表示されなくなるのです。当たり前ですよね…泣
この場合はどう設定したらうまくいくのでしょうか?

Aベストアンサー

テーブル1と2をリレーションさせてから絞り込むのではなく、絞り込んだクエリとテーブル2をリレーションさせましょう。
発想の転換ですよ。^^


人気Q&Aランキング

おすすめ情報