Access (一般機能)

Accessの一般機能に関するフォーラムです。
  • 解決済みのトピックにはコメントできません。
このトピックは解決済みです。
質問

 
(Windows 10全般 : 指定なし)
本日以前の直近日付をユニオンクエリで抽出したい
投稿日時: 20/01/19 20:45:07
投稿者: koppage

複数の預金口座の残高管理を目的としたデータベースです。
口座ごとに取引日付が異なります。
 
直近の(本日を含めた過去の)日付の残高を一覧(各口座それぞれ1行)で出力したいと考えています。
 
個別(口座)のクエリとして日付の抽出条件に「<=Date()」を指定し、並べ替えを「降順」にして「トップ1」のデータを取り出せば、望みは叶います。
 
ところが、ユニオンクエリで全口座を一斉出力しようとするとORDER BY句の制限により、「降順」の並べ替えを行えません。
 
すると全てレコードの最も古い日付のレコードを返すことになってしまいます。
 
データの入力日付がランダムになるために、「ID」などのオートナンバー型の数値を活かすこともできない状態です。
 
何か方法はないでしょうか?
 
並べ替えを行わずに、本日以前の最も新しい日付のレコードを取り出したい訳です。
(同一日付は入力順のオートナンバーの大きいものにしたい)

回答
投稿日時: 20/01/20 10:55:59
投稿者: hatena
投稿者のウェブサイトに移動

まず、集計クエリで、Where条件に <=Date() 、口座 でグループ化、取引日付 を最大 にして保存。
新規にクエリを作成して、元テーブルと上記の集計クエリを追加して、[口座]同士、[取引日付]と[取引日付の最大]で結合すれば、ご希望の結果になると思います。
クエリが2つになるのがいやならSQLサブクエリを使えば一つのクエリにできます。
 
別案としては、Dmax関数かサブクエリで該当口座の最大取引日付を取得して、それを取引日付の抽出条件に設定するという方法もあります。
 
パフォーマンス的には前者の方がいいと思います。

回答
投稿日時: 20/01/20 13:17:11
投稿者: sk

引用:
直近の(本日を含めた過去の)日付の残高を一覧(各口座それぞれ1行)で出力したい

引用:
同一日付は入力順のオートナンバーの大きいものにしたい

( SQL ビュー)
-----------------------------------------------------------
SELECT [テーブル名].*
FROM [テーブル名]
WHERE [テーブル名].[ID] = (SELECT TOP 1 tmp.[ID]
                           FROM [テーブル名] tmp
                           WHERE tmp.[金融機関コード] = [テーブル名].[金融機関コード]
                             AND tmp.[支店コード] = [テーブル名].[支店コード]
                             AND tmp.[預金種目] = [テーブル名].[預金種目]
                             AND tmp.[口座番号] = [テーブル名].[口座番号]
                             AND tmp.[取引日付] <= Date()
                           ORDER BY tmp.[取引日付] DESC,
                                    tmp.[ID] DESC);
-----------------------------------------------------------
(テーブル/フィールドの名前は適宜修正すること)
 
以上のようなクエリを実行なさればよろしいのではないかと。

投稿日時: 20/01/23 10:18:19
投稿者: koppage

skさん、ご回答ありがとうございます。
 
以前にもお世話になりましたが、私は拙い知識しか持ち合わせていない者です。
 
ご回答いただいた内容について未だチャレンジできていないのですが、これは「取引レコード」をひとつの「テーブル」の納めた前提ではないでしょうか?
勿論、その方が効率的であるのは理解しています。
 
実は口座数が34個あるのです。
 
ひとつのテーブルに納めた場合に、個別口座の明細などを取り出す際に「パラメータ」を使って口座の特定をする形になりませんか?(これを回避する方法を以下でお尋ねしています)
 
また、取引データを入力する際に(入力する以外で)「口座」を特定する方法も解りません。
 
口座数が多いため、できれば「口座(銀行名、口座番号)」の特定(入力作業)を省きたいので、現在は口座ごとの「テーブル」や「クエリ」を作成しています。
(できれば一つのテーブルに納めたいのですが、現状は口座の倍数で凄い数のテーブル、クエリ、フォーム、レポートが存在していて、我ながら非効率さに呆れている状態です)
 
「オプションボタン」を予め口座の数だけ用意しておいて、その中に口座を特定する仕組みが可能ではないかと考えております。
 
要するに「個々の取引情報」を一つのテーブルに納める前提として、特定の口座の明細を「レポート」で出力する際に、「口座名」を表示した「ボタン」を用意しておき、「口座名」の入力を省略したい。
 
さらに、フォームで取引情報を入力する際に都度の「口座名」の入力を省略したいのです。
 
誠に厚かましいお願いで申し訳ありませんが、良い知恵をお借り出れば幸いです。
 
根本的に理解が違っていればご指摘も併せてお願いいたします。

回答
投稿日時: 20/01/23 11:56:40
投稿者: sk

引用:
ご回答いただいた内容について未だチャレンジできていないのですが、
これは「取引レコード」をひとつの「テーブル」の納めた前提ではないでしょうか?
勿論、その方が効率的であるのは理解しています。
  
実は口座数が34個あるのです。

引用:
口座数が多いため、できれば「口座(銀行名、口座番号)」の
特定(入力作業)を省きたいので、現在は口座ごとの
「テーブル」や「クエリ」を作成しています。

同じ構造のテーブルが 34 個あるということですか?
 
引用:
ひとつのテーブルに納めた場合に、個別口座の明細などを取り出す際に
「パラメータ」を使って口座の特定をする形になりませんか?

そもそも、それらのテーブルに「口座情報を示すフィールド」は
定義されているのでしょうか。
それとも、そんなフィールドはどこにも存在せず、それぞれのテーブルに
「○○さんの取引一覧」のような名前を付けているだけなのでしょうか。
 
引用:
できれば一つのテーブルに納めたいのですが、現状は口座の倍数で
凄い数のテーブル、クエリ、フォーム、レポートが存在していて、
我ながら非効率さに呆れている状態です

いずれにせよ、まずは全ての「取引レコード」を
1 つのテーブルに統合されるのが先決だと思います。
 
引用:
要するに「個々の取引情報」を一つのテーブルに納める前提として、
特定の口座の明細を「レポート」で出力する際に、
「口座名」を表示した「ボタン」を用意しておき、
「口座名」の入力を省略したい。

全ての口座情報が記録されている( 1 つの口座につき 1 つのレコードが格納される)
マスターテーブルは存在しないのでしょうか。

投稿日時: 20/01/26 15:11:57
投稿者: koppage

>全ての口座情報が記録されている( 1 つの口座につき 1 つのレコードが格納される)
マスターテーブルは存在しないのでしょうか。
 
「口座一覧」のテーブルは最初に作りましたが、利用されていません。
 
「〇〇銀行1234567」の(それぞれの入出金の取引レコードを格納する)テーブルが34個存在するのです。
 
完全に個別にテーブルやクリ、フォーム、レポートが口座の数だけ存在します。
 
なぜそうなったかと言うと、入力や出力の際に都度「〇〇銀行1234567」というパラメータの入力を要求されることが(運用上)現実的でなかったからです。
 
今は、メインフォームに34口座に対してそれぞれ入力用と出力用のオプションボタンを並べています。
これ自体はパラメータの入力を避けるためですので、作ってしまえば運用上は問題ありません。
 
ただ、残高を一覧表示するためにユニオンクエリで結合しようとした際に、最初に質問した「ORDER BY句」の制限の問題があって、「日付」の「降順」という並べ替えができなかった訳です。
(現状は降順の並び替えが効かず入力の一番最初の日が出てきてしまう)
 
テーブルを一つにするのは(本来そうあるべきと)理解できます。
 
ただしその場合の問題は、入力や出力の際にいちいち「〇〇銀行1234567」と口座を指定するための入力を省略する方法があるのかどうかなのです。
 
この方法を知らないために34個も同じオブジェクトを作るという愚を犯しております。
 
今の各口座のテーブル構造は「ID」「取引日付」「口座名番号」「入金」「出金」「残高」となっています。
残高はテーブル(レコード)の入金総額から出金総額を差し引いてレコードごとに算出するように作っています。(話がややこしくなりますが、取引日付順に並べ替え、残高が表示されたテーブルを別途「テーブル作成クエリ」で作っております。今になって思えばこれは無くても構わなかったようですが)
入力が必ず日付順になるとは限らないために、同一日付の場合はIDの新しい(数値の大きい)ものが最新の取引と認識したい考えです。
 
そもそもの目的は、予測される将来の取引(主に出金)を入力することにより、(本日より)将来の「残高不足」を起こさないためのデータベースです。
口座数が少なければ単純なエクセルで済むような稚拙な話なのです。
 
出力に関しては
1.「全ての口座の直近(本日以前)の残高を一覧表示する」ことと、
2.個別口座の「特定日付以降の明細を表示する」(こちらは現状でクリアできている)、
3.本日以降で残高不足に陥る口座の最初の日付と残高を一覧表示する」(これもクリアできている)
の三つです。
 
テーブルを一つにまとめる大前提が、入力や出力の都度「口座名」を特定するための入力を省略できるということになります。
(これは物理的な問題ではなく、運用上の使い勝手の問題としてです)

回答
投稿日時: 20/01/26 16:10:57
投稿者: WinArrow
投稿者のウェブサイトに移動

横から失礼します
 
>テーブルを一つにまとめる大前提が、入力や出力の都度「口座名」を特定するための入力を省略できるとい
>うことになります。
 
テーブルを1つにまとめると、口座名を入力しなくてはいけない
という発想を変えましょう。
 
現在の仕様でも、オプションボタンで、34個のテーブルを切り替えているのだから
同じ考え方で、オプションボタンをパラメータにすれば、同じことになるのではないでしょうか?
 
私だったら、オプションボタンではなくコンボボックスにしますけど・・・フォームレイアウトがすっきりいます。

投稿日時: 20/01/26 19:06:57
投稿者: koppage

WinArrowさんありがとうございます。
 
仰る通りなのです。
 
>オプションボタンをパラメータにすれば、同じことになるのではないでしょうか?
  
>オプションボタンではなくコンボボックスにしますけど・・・フォームレイアウトがすっきりいます。
 
で、このやり方が解らない訳です。

回答
投稿日時: 20/01/26 19:34:12
投稿者: よろずや

いまさらですが。
 
>ところが、ユニオンクエリで全口座を一斉出力しようとするとORDER BY句の制限により、「降順」の並べ替えを行えません。
 
そんな制限あったかねー。
 
とりあえず、そのクエリを提示してみましょう。

投稿日時: 20/01/26 21:27:24
投稿者: koppage

よろづや様
ありがとうございます。
 
SELECT TOP 1 〇〇銀行1234567テーブル.口座名, 〇〇銀行1234567テーブル.日付, 〇〇銀行1234567テーブル.ID, 〇〇銀行1234567テーブル.摘要, 〇〇銀行1234567テーブル.支払, 〇〇銀行1234567テーブル.入金, 〇〇銀行1234567テーブル.残高, 〇〇銀行1234567テーブル.表示順FROM 〇〇銀行1234567テーブル作成
WHERE (((〇〇銀行1234567テーブル.日付)<=Date()))
ORDER BY 〇〇銀行1234567テーブル.表示順 DESC;
 
これは個別口座のクエリのSQLです。
「表示順」というのは日付とIDを結合させたものです。
 
個別にはクエリの実行で求めるレコードが得られます。
 
しかし、ユニオンクエリではORDER BY句は最初のSQLにしか書けないようですが?
そうしないと実行してもエラーになります。
 
何か方法があるのですかね?
 
ここが最初の質問だった訳です。

回答
投稿日時: 20/01/26 23:42:14
投稿者: WinArrow
投稿者のウェブサイトに移動

下記は、勘定ごとに取引データの最大日付を求めるSQLです。
参考になればと思います。
 
 前提:取引データは全件1つのテーブルに入っています。
  
SELECT 勘定,MAX(日付) FROM (SELECT FORMAT(年月日,'YYYY/MM/DD') AS 日付,IIF(LEFT(借方勘定,3)>='A02' AND LEFT(借方勘定,3)<='A04',借方勘定,IIF(LEFT(貸方勘定,3)>='A02' AND LEFT(貸方勘定,3)<='A04',貸方勘定,'')) AS 勘定 FROM 取引データ WHERE 年度='2019' AND (LEFT(借方勘定,3) IN('A02','A03','A04') OR LEFT(貸方勘定,3) IN('A02','A03','A04'))) GROUP BY 勘定
  
フィールド :借方勘定/貸方勘定(A02,A03,A04)が口座番号と同じだと考えてください(例では3つ)
  
  

回答
投稿日時: 20/01/27 10:29:21
投稿者: sk

引用:
「口座一覧」のテーブルは最初に作りましたが、利用されていません

引用:
完全に個別にテーブルやクエリ、フォーム、レポートが口座の数だけ存在します。

引用:
今は、メインフォームに34口座に対してそれぞれ入力用と出力用の
オプションボタンを並べています。

引用:
なぜそうなったかと言うと、入力や出力の際に都度「〇〇銀行1234567」という
パラメータの入力を要求されることが(運用上)現実的でなかったからです。

それはテーブルとフォームの設計を初手から誤ったためでしょう。
 
【テーブルの構成】
 
(以下、P は主キー)

[T_金融機関]
------------------------------------------------------------
P 金融機関コード              テキスト型
  金融機関名称                テキスト型
  金融機関フリガナ            テキスト型
------------------------------------------------------------

[T_金融機関支店]
------------------------------------------------------------
P 金融機関コード              テキスト型
P 支店コード                  テキスト型
  支店名称                    テキスト型
  支店フリガナ                テキスト型
------------------------------------------------------------

[T_預金種目]
------------------------------------------------------------
P 預金種目コード              テキスト型
  預金種目名称                テキスト型
------------------------------------------------------------

[T_口座情報]
------------------------------------------------------------
P 口座ID                      オートナンバー型
  金融機関コード              テキスト型
  支店コード                  テキスト型
  預金種目コード              テキスト型
  口座番号                    テキスト型
  口座名義人氏名              テキスト型
  口座名義人フリガナ          テキスト型
  開設日時                    日付/時刻型
  解約日時                    日付/時刻型
------------------------------------------------------------

[T_口座取引履歴]
------------------------------------------------------------
P 取引ID                      オートナンバー型
  取引日時                    日付/時刻型
  口座ID                      長整数型
  入金額                      通貨型
  出金額                      通貨型
  残高金額                    通貨型
  摘要                        テキスト型
------------------------------------------------------------

【フォームの構成】
 
1. [T_口座取引履歴]をレコードソースとする帳票フォーム
   [F_口座取引履歴]を作成する。
 
2. [T_口座情報]をレコードソースとする単票フォーム
   [F_口座情報]を作成する。
 
3. [F_口座情報]の詳細セクション上の[金融機関コード]、
   [支店コード]および[預金種目コード]の連結コントロールの
   種類は全てコンボボックスとする。
   (それぞれの値集合ソースの設定についてはひとまず割愛する)
 
4. [F_口座情報]の詳細セクション上に、[F_口座取引履歴]を
   ソースオブジェクトとするサブフォームコントロールを配置し、
   [口座ID]同士でリンクするようにする。
 
5. 非連結フォーム[F_口座一覧]を作成し、[T_口座情報](を元に
   作成した選択クエリ)を値集合ソースとする非連結リストボックスと、
   [F_口座情報]を開くマクロ/コードを実行するためのコマンドボタンを
   詳細セクション上に配置する。
 
6. コマンドボタンのクリック時イベントのマクロ/コードによって
   [F_口座情報]が開かれる際、リストボックスで選択された
   レコードのみが表示されるようにオプション/引数を設定する。
 
----------------------------------------------------------------
 
ざっくりとした例としては、以上のような構成が挙げられます。
 
引用:
「〇〇銀行1234567」の(それぞれの入出金の取引レコードを格納する)
テーブルが34個存在する

引用:
残高を一覧表示するためにユニオンクエリで結合

テーブルの数が 34 個であるうちはまだそれでも通用するでしょうけど、
UNION 出来る SELECT 文の数(クエリのネスト回数)には上限がありますので、
いずれはその方法でもカバーし切れなくなりますよ。
 
引用:
最初に質問した「ORDER BY句」の制限の問題があって、
「日付」の「降順」という並べ替えができなかった

ユニオンクエリの ORDER BY 句は、それぞれの SELECT 文ごとに
記述するのではなく、クエリの一番最後に記述することで、
併合されたレコード全てが並べ替えられます。
 
( SQL ビュー)
------------------------------------------------------------
SELECT 1 AS [テーブル番号],
       [テーブル1].[日付],
       [テーブル1].[ID]
FROM [テーブル1]
UNION ALL
SELECT 2 AS [テーブル番号],
       [テーブル2].[日付],
       [テーブル2].[ID]
FROM [テーブル2]
ORDER BY [テーブル番号],
         [日付] DESC,
         [ID] DESC;
------------------------------------------------------------

回答
投稿日時: 20/01/27 11:42:43
投稿者: よろずや

>個別にはクエリの実行で求めるレコードが得られます。
 
なら、その34個のクエリをもとにユニオンクエリを作ればいいだけの話です。
 
ユニオンクエリの中でそれぞれに ORDER BY を指定するには、SELECT文を入れ子にします。
 
SELECT * FROM(SELECT TOP 1 * FROM UFJ銀行
 WHERE (((日付)<=Date())) ORDER BY [日付] DESC, [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM あさひ銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC, [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM きらぼし銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM みずほ銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM りそな銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 横浜銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 勧業銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 京葉銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 興行銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 群馬銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 埼玉銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 三井銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 三菱銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 三和銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 山梨銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 住友銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 常陽銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 神奈川銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 千葉銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 足利銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 大和銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 第一銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 第四銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 筑波銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 長野銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 東海銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 東京銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 東日本銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 東和銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 栃木銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 八十二銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 富士銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 武蔵野銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC)
UNION ALL SELECT * FROM(SELECT TOP 1 * FROM 北越銀行
 WHERE ((([日付])<=Date())) ORDER BY [日付] DESC , [ID] DESC);
 
とりあえず、ここまでとし、
あとはゆっくりとテーブル構造の変更を考えましょう。

回答
投稿日時: 20/01/27 16:53:15
投稿者: mayu.

引用:
SELECT TOP 1 〇〇銀行1234567テーブル.口座名
           , 〇〇銀行1234567テーブル.日付
           , 〇〇銀行1234567テーブル.ID
           , 〇〇銀行1234567テーブル.摘要
           , 〇〇銀行1234567テーブル.支払
           , 〇〇銀行1234567テーブル.入金
           , 〇〇銀行1234567テーブル.残高
           , 〇〇銀行1234567テーブル.表示順
FROM 〇〇銀行1234567テーブル作成
WHERE (((〇〇銀行1234567テーブル.日付)<=Date()))
ORDER BY 〇〇銀行1234567テーブル.表示順 DESC;

引用:
これは個別口座のクエリのSQLです。
「表示順」というのは日付とIDを結合させたものです。
 
個別にはクエリの実行で求めるレコードが得られます。
 
しかし、ユニオンクエリではORDER BY句は最初のSQLにしか書けないようですが?
そうしないと実行してもエラーになります。
何か方法があるのですかね?

よろずやさんが回答したように
FROM 句のサブクエリ内に ORDER BY 句を含めてしまう方法もありますし、
ORDER BY 句を使用せずに
同様の結果を得る SQL を記述することもできますから、参考までにご紹介します。
 
SELECT t.口座名 
     , t.日付
     , t.ID
     , t.摘要
     , t.支払
     , t.入金
     , t.残高
FROM 〇〇銀行1234567テーブル t
INNER JOIN
( 
    SELECT Max( Format$( 日付, 'yyyy/mm/dd' ) & Format$( ID, '00000000' ) ) As keys 
      FROM 〇〇銀行1234567テーブル
     WHERE 日付 <= Date()
) q
ON t.ID = CLng( Mid$( q.keys, 11 ) )

なお、私も 2020/01/27 10:29:21 に投稿された skさんと同意見です。
SQL の記述次第で、ユニオンクエリでの結合が可能である
ということに納得いただけたら、速やかにデータベースの再構築を開始すべきでしょう。

投稿日時: 20/01/28 12:51:42
投稿者: koppage

skさん
 
>ユニオンクエリの中でそれぞれに ORDER BY を指定するには、SELECT文を入れ子にします。
 
データベースの構造をやり直すのはこれからとして、とりあえず上記のアドバイスで現状での欲しいデータの取得は可能になりました。
 
ありがとうございます。
 
他の方からのアドバイスも参考にして、次の段階でもっと効率的な構造を目指します。
 
なお、口座数が増加する可能性は現時点でありません。
 
とりあえず運用可能な状態になりました。
 
他の方もありがとうございます。
 
何か不都合なことが出てくる前に改良を図りたいと思いますので、その時点でまたアドバイスいただければ幸いです。
 
一旦、この質問は終了させていただきたいと思います。
 
改良の段階で困ったら、再度別の質問を立てさせていただきますので、よろしくお願いいたします。