訪問本地前端連接到Azure SQL Server後端很慢

Question

我一直在使用Access來快速原型數據庫。現在我想進行一個小組在線測試，因此我拆分了數據庫並將後端放置在Azure SQL Server上，然後重新鏈接。這是非常緩慢的，我一直在研究解決方案的日子沒有積極的結果。我的本地環境是Win10，Office2016 64位和互聯網連接快速和穩定。

我試過不同的ODBC驅動程序，包括SQL Native Client v11。

我已禁用NIC上的自整定級別。

我重新創建了服務器上訪問的所有查詢。

我已確認在ODBC中的跟蹤已關閉。

但我啓用了跟蹤暫時看看發生了什麼。如果我打開前端，登錄（小用戶表），並在第一個表單上做了一些操作（添加1個記錄和3個子記錄......並且真的......沒有任何花哨或沉重的東西，而這隻需要1分鐘）然後關閉數據庫，我發現跟蹤日誌文件是1.5MB。

所以我創建了一個空Access文件和ODBC連接到只有用戶表（12列，20條），然後再次監測跟蹤日誌文件。打開訪問不會向日志文件添加任何內容，但打開這個鏈接表後，日誌文件將增長到255kb。在訪問中打開此表需要5秒鐘。

訪問發送了大約800個請求到服務器打開這個小表。如果我將所有用戶表格數據粘貼到文本文件中，則只有2kb。 SO爲什麼這麼慢？

對此有任何想法，特別是其他建議，以更快地工作？

親切的問候，

Answer 1

好了，經過將近試圖得到這個工作（Access前端到SQL Server Azure上的後端）一個星期，我得出的結論是，它不是一個可行的解決方案。

我試過SQL Server和安裝在Azure上一個SharePoint 2016服務器，這也失敗了。

有什麼使用的產品從Bullzipp稱爲MS訪問MySQL轉換的訪問表，然後在服務器上添加一個MySQL數據庫和導入通過的BullZip生成的文件工作。這裏唯一要注意的是，Bullzip不喜歡較新的訪問格式（它想要一個MDB文件），所以去訪問，創建一個新的空文件，但確保您將其文件類型設置爲MDB。然後導入您的表並運行Bullzip。

它現在比SQL Server工作速度快很多，但我在Access中遇到了一些寫入衝突，所以我只需要通過代碼並執行所需的任何操作，以便我可以避免這些消息。

Answer 2

的問題很簡單，Azure的SQL數據庫是不是非常快的小的DTU（數據庫事務單位）運行相比，比方說，SQL Server的內部實例承載的能力，即使溫和的現代服務器。

我檢查出來過，它需要查詢和過濾的非常細心的設計 - 遠離你通常可以逃脫 - 獲得可接受的整體速度。另一方面，這是一種給予體驗，它將注意力集中到潛在的瓶頸上，否則它可能爲時已晚。

Answer 3

那麼，使用Azure的原因比運行Access的速度慢的原因是，連接到本地SQL Server實例的原因是，速度慢很慢！

我的意思是，如果你要旅行30英里，你可以選擇走路或坐車。

因此，這裏是你需要知道的問題：

爲什麼走路比開車慢？

回答，因爲您的旅行速度較慢！

那麼，爲什麼使用Azure會降低使用本地計算機或本地網絡上運行的SQL Server實例？

答案： 因爲Azure的連接速度大約慢100倍！

這裏的想法，你不會考慮連接速度的差異是這裏的問題。對於公衆來說，這可能會導致這樣的設置（訪問SQL Server的Azure實例上的前端）不是一個可行的設置。

因此，這裏的第一個問題是記錄到後端數據庫的連接速度。

典型的辦公室局域網的速度爲100MBits，或者今天大多數是1gig--即使是在Best Buy購買的el-cheapo路由器現在的額定容量爲1gig（1000 mbits）。

但是，您的典型高速互聯網的額定值爲5或10兆位。所以這是100倍慢。 （其實1000/5 = 200倍慢!!!）。

這意味着如果您的辦公網絡需要3秒鐘的時間與Access和SQL服務器？那麼一個廣域網（通過互聯網），那麼你需要通過改變連接速度來增加時間（這很簡單 - 但它似乎逃脫了所有！）。所以，如果你幸運的話，你的網絡速度可能會達到5Mbit。這意味着你去

五分之一千= 200

現在你把你的200和多個現有的延時說3秒鐘，你會得到600秒（即10分鐘，如果你想知道！）。所以你從3秒到10分鐘！

這種速度的比較就像走進一家體育用品商店買橡皮船穿越大西洋。因此，不考慮互聯網速度的變化，並想知道爲什麼速度緩慢是這裏的問題。

您絕對可以使用Access到Azure，但您必須實現兩個簡單的概念。

1 - 連接和測試的連接速度比您的局域網慢50-200倍，這樣的測試速度會慢50到200倍！沒有提到並考慮到LAN與LAN的速度連接的巨大差異，這是一個簡單的問題。

2 - 打開綁定到大型數據表的表單會導致大小寫性能問題。

我坐在公交車站跟一位90歲的老太太說話。我問她以下幾點：

你有沒有使用過即時出納員？她說，爲什麼是，我一直都在使用它們。

然後我問這個問題你不覺得在你等待的時候讓出納機下載所有的人的賬戶是不好的，那麼請問你的賬號？

這位老太太說，當然這很愚蠢。我輸入我的帳戶密碼，機器只下載我的帳戶信息 - 這是實用而明顯的。

換句話說，老太太意識到下載一堆數據之前，用戶甚至輸入或做任何事情都是浪費帶寬。

因此，你永遠不想啓動綁定到表的表單然後問用戶什麼記錄工作。爲什麼Access會將大量記錄下載到表單中，然後詢問用戶或允許用戶導航到所需的記錄？

即使使用Google，它也不會將整個互聯網下載到您的網頁瀏覽器頁面，然後按ctrl-f搜索該網頁的內容。

相同的概念應該適用於Access應用程序。一個設計，要求什麼工作，然後啓動一個表格綁定到一個「where」子句將解決這個問題。

因此，如果您有一個顯示客戶發票的表單（甚至子表單），您首先需要詢問發票號碼，然後使用where子句將該表單限制爲一張發票！

請記住，你仍然可以使用綁定到1萬行，只有一個記錄一個表，發票形式將被拉低網絡連接*如果一個使用的「where」子句。

因此，一個典型的互聯網連接有足夠的速度來運行瀏覽器，也有足夠的帶寬速度來拉下幾個記錄。訪問通常會導致糟糕的性能表現，但這對於Access開發人員來說只是一個必然的結果，因爲忽略了一個明顯的建議，即將不需要的大量內容下載到表單中的操作將會很慢。

所以基於Web的應用，或寫在vb.net甚至桌面應用程序與SQL Azure在雲中過那麼多的互聯網連接較慢運行，因爲這些應用程序不啓動綁定到大型數據集不先簡單地允許形式表現良好用戶請求他們需要查看和查看的內容。

至於訪問和使用SharePoint？該設置可以非常快，實際上比SQL Azure，MySQL或任何傳統數據庫系統快得多，因爲當您使用SharePoint表和Access時，Access會自動同步數據本地副本。此設置意味着您的應用程序將繼續運行，而無需任何互聯網連接。即時連接恢復，然後數據同步可以恢復。

這意味着如果您有一個包含15,000行的表並運行有關該數據的報表，則該報表可以在SharePoint後端立即運行並立即啓動，因爲數據的本地副本位於ALL TEST的前端！所以這個設置非常適合脫機模式，或者你的互聯網連接速度很慢並且速度很慢，因爲你提到的數據總是有本地數據副本 - 只有當記錄被改變時纔會發生同步，並且該同步可以獨立於Access而發生。因此，您更改了一條記錄 - 並開始與SharePoint同步。

但是，對於需要更新的大型數據集，SQL Server要好得多，因爲您可以在10,000行上執行sql更新，並且在使用SQL Server時需要發生零網絡流量和數據傳輸以更新這10,000行（傳遞查詢），並且在使用SharePoint時，由於本地副本需要更新行，10,000行將通過網絡傳輸。因此，對於必須更新大量行或執行大量行更新類型的數據處理的應用程序，不存在使用SharePoint用於數據庫後端的巨大優勢。

所以關鍵概念，並帶走這裏：

的你有高速互聯網連接往往比典型的廉價辦公室（本地）網絡慢10-200倍。這意味着2秒的操作現在需要10-200倍的時間。

Access應用程序需要進行優化，以避免將太多記錄加載到表單中。因此構建搜索表單等等。首先要問用戶他們需要處理的是對所有優秀開發人員以及包括Access開發人員的基本和簡單要求。

訪問和SharePoint可以是最好的選擇，並且這樣的設置允許應用程序甚至在沒有互聯網連接時運行。如果表格大小低於10,000行，那麼這種設置通常是理想的。然而，對於必須更新大量行和處理大量數據的應用程序，此設置很差，因爲對任何行的更新都會導致數據同步通過網絡發生。此設置也是最便宜的，因爲具有SharePoint支持Access的單個Office 365帳戶每月可以支付6美元，而6美元帳戶最多允許500個免費用戶，而這500位用戶甚至可以使用他們的Gmail或非Microsoft帳戶爲此設置。而且，這種適合SharePoint表格邊界的訪問應用程序往往需要更少的更改和優化，然後通過Internet使用SQL Server。

使用SQL服務器，使用視圖，pass-tough查詢以及在某些情況下編寫存儲過程允許更新和代碼在不使用任何帶寬的情況下運行。因此，可以將單個更新查詢發送到更新10,000行數據的服務器 - 唯一的網絡成本將是發送該sql語句的「微小」帶寬量。

因此，儘管綁定表單可以與運行在雲中的SQL Azure一起使用，但需要構建類似於Web的軟件或vb.net，在這些軟件中，他們首先詢問用戶要使用哪個帳戶或客戶，然後啓動UI以顯示給定的數據。

所以在訪問中，將構建一個搜索表單這樣說：

在一天結束

所以，在這裏忽略職位，表明訪問雲to SQL是很重要不可行。使用適當的設計進行訪問將比在Azure上運行的SQL服務器的典型互聯網連接工作得更好。

事實上，我看到有人在56k調制解調器上使用Access to SQL！

必須採用合理的設計，其中爲特定任務提取的數據受到限制 - 這是所有開發人員的大廳標記 - 唯一的問題是Access不執行此方法，而大多數其他開發人員工具不允許你把自己掛在大桌子上的裝訂形式！這並不是說訪問速度很慢，但是當您做出糟糕的設計決策時訪問速度很慢。

對SharePoint的訪問可能是一個真正的贏家 - 尤其是對於帶寬不足，帶寬不穩定的情況，甚至當連接丟失時，如果運行相同的應用程序，應用程序將繼續運行並且運行速度超過99％與SQL後端。這裏有一個大的警告，因爲只有某些類型的應用程序可以很好地處理SharePoint表。我解釋了爲什麼，怎麼樣，當這樣的應用更好地超出了一個簡單的帖子在這裏，但人們只需知道的SharePoint可不得了的解決方案，而不是對所有的應用程序和SQL服務器能夠而且將會是更好的選擇。這種SharePoint「更好」的選擇只能根據特定類型的應用程序的案例評估來確定。