Dataverse 路線下，Access SQL 不能直接搬過去嗎？——Power Apps / Power BI / Dataverse View 的分工整理
Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license.
If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1305
在 Access 系統移行到 Power Platform 時，最容易誤解的一點是：
「既然資料都搬到 Dataverse 了，那我原本 Access 裡寫好的 SQL，是不是可以直接拿來用？」
答案其實很殘酷：
如果後端選 Dataverse，那麼 Power Apps、Power BI、Dataverse View 這三個地方，基本上都不是直接寫 SQL 的地方。
這也是為什麼傳統 Access 系統移行到 Dataverse 時，不能單純理解成「把資料庫搬過去」。
它更像是把原本集中在 Access 查詢裡的邏輯，拆散到 Power Platform 的不同元件裡。
一、先講結論
如果使用 Dataverse 作為後端資料庫，常見的資料處理位置大概是這樣：
Power Apps 畫面
→ 用 Power Fx
→ Filter / LookUp / Search
Power BI 報表
→ 用 Power Query / DAX / 視覺化篩選
Dataverse View
→ 用 View 條件設計器 / FetchXML 系思維
複雜業務邏輯
→ 用 Power Automate / Plugin / Azure Function / API
也就是說，原本 Access 裡常見的這種 SQL：
SELECT
A.受付番号,
A.請求人,
B.税目名,
C.事件種
FROM
事績処理テーブル AS A
INNER JOIN
税目テーブル AS B
ON
A.税目コード = B.税目コード
INNER JOIN
事件種テーブル AS C
ON
A.事件種コード = C.事件種コード
WHERE
A.処理状況 = '未済'
ORDER BY
A.受付日;
不能原封不動貼到 Power Apps、Power BI 或 Dataverse View 裡直接使用。
這一點非常重要。
二、Power Apps 裡不是寫 SQL，而是寫 Power Fx
在 Power Apps Canvas App 裡，如果要顯示某個清單，例如「未済案件」，通常會在 Gallery 或 ComboBox 的 Items 屬性裡寫：
Filter(
事績処理テーブル,
処理状況 = "未済"
)
這裡用的是 Power Fx，不是 SQL。
也就是說，在 Power Apps 裡你不會寫：
SELECT * FROM 事績処理テーブル WHERE 処理状況 = '未済'
而是改成：
Filter(
事績処理テーブル,
処理状況 = "未済"
)
如果還要加條件，例如支部、受付日範圍：
Filter(
事績処理テーブル,
支部 = "01" &&
処理状況 = "未済" &&
受付日 >= Date(2026, 4, 1) &&
受付日 <= Date(2026, 4, 30)
)
這個查詢是由 Power Apps 畫面發起的。
使用者打開畫面時，Power Apps 會根據這個公式去 Dataverse 取資料。
流程大概是：
使用者打開 Power Apps 畫面
↓
Gallery / ComboBox / Form 的 Items 執行 Filter()
↓
Power Apps 向 Dataverse 要資料
↓
Dataverse 回傳符合條件的資料
↓
畫面顯示
所以 Power Apps 裡的 Filter，主要是給 畫面顯示、下拉選單、查詢條件、資料輸入輔助 使用。
三、Power BI 也不是用 Power Apps 的 Filter
Power BI 如果連 Dataverse，它不會使用 Power Apps 的 Filter()。
Power BI 通常是透過：
Power BI
↓
Power Query
↓
Dataverse Connector
↓
Dataverse Table / View
這時候資料處理通常發生在 Power Query 或 Power BI Model / Visual 裡。
Power Query 使用的是 M 語言，例如：
Table.SelectRows(Source, each [処理状況] = "未済")
這不是 SQL，也不是 Power Fx。
如果是在 Power BI 報表畫面上做篩選，那可能是：
報表篩選器
切片器 Slicer
Visual-level filter
Page-level filter
Report-level filter
也就是說，Power BI 的篩選邏輯屬於報表分析層，不是 Power Apps 畫面層。
四、Dataverse View 也不是 SQL View
Dataverse 裡也有 View。
這個 View 很容易讓人聯想到 SQL Server 的 View，但它不是完全同一個東西。
SQL Server View 可以寫：
CREATE VIEW vw_MisaiCases AS
SELECT
A.受付番号,
A.請求人,
B.税目名
FROM
事績処理テーブル A
INNER JOIN
税目テーブル B
ON
A.税目コード = B.税目コード
WHERE
A.処理状況 = '未済';
但 Dataverse View 通常是透過畫面設計器設定條件，例如：
ビュー名：未済案件ビュー
條件：
処理状況 = 未済
削除フラグ = false
它比較像是「固定好的資料檢視條件」，而不是讓你自由貼 SQL 的地方。
所以 Dataverse View 可以幫你做一些常用條件，但它不是 Access Query 的完整替代品。
五、所以這三處都不能直接用 SQL？
可以這樣理解：
| 位置 | 能不能直接寫 SQL？ | 實際使用方式 |
|---|---|---|
| Power Apps Canvas | 基本不能 | Power Fx：Filter() / LookUp() / Search() |
| Power BI 連 Dataverse | 通常不是 | Power Query / DAX / 報表篩選 |
| Dataverse View | 不是 SQL | View 條件設計器 / FetchXML 思維 |
所以如果你的後端是 Dataverse，那原本 Access 裡的 SQL 查詢不能直接搬到這三處。
這不是小問題。
對於 Access 系統來說，這通常意味著大量查詢邏輯需要重新設計。
六、Access 的 SQL 在原系統裡承擔了太多角色
Access 裡的 Query 往往不只是「查資料」。
它可能同時承擔這些角色：
資料取得
條件篩選
Join
Group By
排序
報表資料來源
畫面資料來源
業務判斷的一部分
例如 Access 裡一個查詢可能直接被報表使用：
Access Query
↓
Access Report
↓
印刷プレビュー / PDF / 紙本帳票
但到了 Dataverse / Power Platform，這些角色會被拆開：
Power Apps Filter
→ 畫面顯示用
Dataverse View
→ 固定檢視用
Power Query / DAX
→ Power BI 報表用
Power Automate / Plugin / API
→ 流程與業務邏輯用
所以你原本在 Access 裡一個 SQL 查詢就能解決的事情，到了 Dataverse 路線下，可能會被拆成好幾個地方。
這就是移行時最麻煩的地方。
七、Dataverse 路線不是「SQL 移植」，而是「邏輯重構」
如果原系統只是簡單資料表，例如：
客戶表
商品表
訂單表
而且畫面也只是簡單 CRUD，那 Dataverse 很適合。
但如果原 Access 系統裡有大量：
複雜 SQL
多表 Join
報表 Query
VBA 業務邏輯
印刷帳票
查詢結果再加工
那就不能把 Dataverse 想成 SQL Server 的替代品。
因為實際上不是：
Access SQL
↓ 稍微修改
Dataverse SQL
而是：
Access SQL
↓ 拆解與重構
Power Apps Filter
Dataverse View
Power Query
Power Automate
Plugin
API
這個成本會高很多。
八、如果想保留 SQL 思維，應該考慮 Azure SQL Database
如果系統裡有大量既存 SQL，而你希望盡量保留原本的查詢思維，那後端選 Azure SQL Database 會自然很多。
因為 Azure SQL Database 本質上還是 SQL Server 系的雲端託管資料庫。
這樣原本的 Access Query 至少有機會改造成：
Access Query
↓
Azure SQL View
或者：
Access Query / VBA 邏輯
↓
Stored Procedure
↓
.NET API / Azure Functions
比較合理的架構會是：
Power Apps / Web 前端
↓
.NET API / Azure Functions
↓
Azure SQL Database
↓
SQL View / Stored Procedure
↓
Power BI 報表
這種架構下：
畫面操作 → Power Apps 或 Web
業務邏輯 → API / Azure Functions
資料查詢 → SQL View / Stored Procedure
報表 → Power BI 讀 SQL View
分工會更接近傳統系統的思維。
九、總結
如果後端是 Dataverse，那麼：
Power Apps 裡不能直接寫 SQL
Power BI 連 Dataverse 時通常也不是寫 SQL
Dataverse View 也不是 SQL View
原本 Access 裡的 SQL 查詢，不能直接原封不動搬進 Power Platform 使用。
Dataverse 路線的本質不是：
Access SQL 移植
而是：
Access 查詢邏輯重構
這也是為什麼在面對傳統 Access 系統，尤其是含有大量 SQL、VBA、報表、印刷邏輯的系統時，不能輕易說「搬到 Dataverse 就好」。
比較現實的判斷是：
簡單 CRUD 系統
→ Dataverse / Power Apps 適合
大量 SQL + 複雜報表 + 業務邏輯
→ Azure SQL Database + API + Power BI 更合理
尤其是原系統如果本來就是 Access + SQL Query + Report 的組合，那麼與其把 SQL 拆成到處都是 Filter()，不如把資料與查詢邏輯放到 Azure SQL Database，前端和報表再分別接上去。
否則最後很容易變成：
Access 的 SQL 地獄
↓
Power Apps 的 Filter 地獄
只是換了一種痛苦而已。
This article was last edited at