ごめん、意味不明(T-T)

うーんと今の用語の使い方だと多分内容が伝わりません。
リブって何よとかあるし。
リブというのが、ライブラリ全体を指しているのか
スタティックリンクライブラリを指しているのか
ダイナミックリンクライブラリのインポート用のライブラリを指しているのか
よく分からないからです。
で、そっちの方の勉強をしてほしいなと。
一人でやっている時は用語とか気にしないでも何とかなるかもしれないのですが、
他の人と話をする為にはある程度の用語は何とか理解しないと難しいです。

逆に言うと説明出来る所まで自分で整理したら問題は解決するかもしれません。

もう少し詳しく書いてみました。

　Aリブ→スタティックリンクライブラリ
　Bリブ→ダイナミックリンクライブラリのインポート用のライブラリ

　ADLL→ダイナミックリンクライブラリ
　BDLL→ダイナミックリンクライブラリ
　CDLL→ダイナミックリンクライブラリ

自分の中でのリブはリブだろっと思っていましたが、
違うんですね。リブっていっても色々あるんですね。
まだまだです。勉強しておきます・・・（；；）

まず、一般的な定義の不明な用語を使われても意味がわかりません。
正しい用語が使えないと有意義な回答が得られないと思ってください。

次に、回答の性質上、質問内に出てくるライブラリは、それぞれ異なった
プロジェクトで、異なったソリューションであることを仮定します。
また、構成ファイルは共有されている場合と、類似の異なったバージョンが
混載する、２つの可能性を排除しません。

で、結論としては「提示された内容だけでは判定できない」といえます。
従って、全てのプロジェクトを「リビルド」すべきです。

できるのなら「唯一のソリューション」にA,B,ADLL,BDLL,CDLL、全ての
プロジェクトを挿入して、VCの依存関係の判定に任せるのが一番です。
意外な依存関係を発見できる場合もあります。

やっぱし、詳しいところ(AとかBとか)は意味不明なので、一般論として
答えておきます。

[スタティックリンクライブラリ]
ただの*.objファイルの固まりであり、それ単体ではロード不可能
よって、スタティックリンクライブラリのソースコードを変更したら、
スタティックリンクライブラリを使用する全プロジェクトのビルドが必要

[ダイナミックリンクライブラリ]
DLLを呼び出す側(EXE等)とは別々にロードされる
呼び出す側は DLL のエクスポート対象の定義(エクスポート関数のI/O等)
だけ知っていればよい
よって、ダイナミックリンクライブラリのソースコードを変更しても、
エクスポート対象に影響しない変更であれば、ダイナミックリンクライブ
ラリ側のビルドだけでよい

ちなみに、DLLで*.libを使う場合は、インポートライブラリと言って、
エクスポート対象の定義(エクスポート関数のI/O等)だけをライブラリ化
した極小のライブラリです。
(同じ、*.libでもスタティックライブラリとはまるで違うもの)

それすら不要なのが、LoadLibrary(), GetProcAddress()を使う方法に
なります。

Aリブ,Bリブとかは抽象的にプロジェクトを表現しているだけです。
今回は詳細に書いてみました。これで分かるか分かりませんが・・・。
banさんの意見を参考にすると、変更したライブラリを使用しているプロジェクト全てを
ビルドした方が良さそうですが・・・、とりあえずみてください。

Aリブ：DBアクセス用共通関数のスタティックリンクライブラリ
以下のテーブル毎にクラスで分けてます。
　　 Aクラス:Aテーブル(DB)用のアクセスするクラス
　　　 Bクラス:Bテーブル(DB)用のアクセスするクラス(Aのクラスを変数定義している）
　　　 Cクラス:Cテーブル(DB)用のアクセスするクラス
　　　 ※変更したのは、Aクラスに取得用の関数を追加しただけです。

Bリブ：データ操作ＤＬＬ（ＡＰ）のロード関数のスタティックリンクライブラリ
　　　 ロードするＤＬＬの引数にAリブのBクラスを宣言しています。

(A)DLL：データ操作ＡＰのダイナミックリンクライブラリ
Mainの引数にAリブのBクラスを宣言しています。
　　　　
(B)DLL：データ操作ＡＰのダイナミックリンクライブラリ
　　　　AリブのAクラスをメンバ変数として定義しています。

(C)DLL：データ操作ＡＰのダイナミックリンクライブラリ
　　　　AリブのBクラスをメンバ変数として定義しています。

(D)DLL：データ操作ＡＰのダイナミックリンクライブラリ
　　　　AリブのCクラスをメンバ変数として定義しています。

その構成の意義はいまひとつ見えなかったりしますが、
抽象化されている上、細かい部分の関連が見えないので
この部分に関しては言及しません。

書かれている表面の話だけで行くと修正を加えたのはA.libのAクラスだけですね。
直接関係有りそうなのは、AクラスとBクラスを使っているライブラリが
対象になると思います。
挙げられている内容からだけ判断するとD.DLL以外は全部リビルドした方が
良さそうです。
但し、御自身で判断が出来ないのであれば全部リビルドした方が良いと思います。
隠れた所で影響があったりすると目も当てられません。
逆に御自身がきちんと依存関係を把握しているのであれば、質問する必要も無いですよね。

最近のHWは性能が良いので全てリビルドしてしまっても対してロスにならない
と言うのもありますね。

「ビルド」だとひとくくりになってますが、
コンパイルは不要でリンクのみ必要なケースとかもありますし…書き方次第ですね。

COM(ちっく)にバイナリ互換を保てる形に実装してたり、
どんな修正をやったかでも結果が変わるので、情報不足ですが、
「理屈を理解してバイナリ互換性を考慮して慎重に実装、設計した」わけでなければ、
とりあえず、全部ビルドが必要と思っておいた方が無難です。

私もよほど自信がなければリブから順に全てリビルドします。

ところで、

> Bリブ：データ操作ＤＬＬ（ＡＰ）のロード関数のスタティックリンクライブラリ
> 　　　 ロードするＤＬＬの引数にAリブのBクラスを宣言しています。

とはデータ操作DLLの中身は Bリブ にライブラリ化(静的) してあるということ？
であれば、Bリブ内でAリブのBクラスを使い、Bクラス内でAクラスを変数定義しているの
で、
BリブもAリブの後にビルドしておいた方がよいです（順番を間違えると意味がないで
す）。