เราทุกคนมีขีดจํากัด และฐานข้อมูล Access ก็ไม่มีข้อยกเว้น ตัวอย่างเช่น ฐานข้อมูล Access มีขนาดจํากัด 2 GB และไม่สนับสนุนผู้ใช้ที่ใช้พร้อมกันมากกว่า 255 ราย ดังนั้น เมื่อถึงเวลาที่ฐานข้อมูล Access ของคุณจะไปยังระดับถัดไป คุณสามารถโยกย้ายไปยัง SQL Server ได้ SQL Server (ไม่ว่าจะเป็นภายในองค์กรหรือใน Azure Cloud) สนับสนุนข้อมูลจํานวนมาก ผู้ใช้พร้อมกันมากขึ้น และมีความจุมากกว่ากลไกจัดการฐานข้อมูล JET/ACE คู่มือนี้ช่วยให้คุณเริ่มต้นการเดินทาง SQL Server ได้อย่างราบรื่น ช่วยรักษาโซลูชัน Front-End ของ Access ที่คุณสร้างขึ้น และหวังว่าจะสร้างแรงจูงใจให้คุณใช้ Access สําหรับโซลูชันฐานข้อมูลในอนาคต ใช้ตัวช่วยการโยกย้าย Microsoft SQL Server (SSMA) เพื่อโยกย้ายให้เสร็จสมบูรณ์ ตามขั้นตอนเหล่านี้
ก่อนที่คุณจะเริ่มต้น
ส่วนต่อไปนี้มีพื้นหลังและข้อมูลอื่นๆ เพื่อช่วยให้คุณเริ่มต้นใช้งาน
เกี่ยวกับฐานข้อมูลแบบแยก
วัตถุฐานข้อมูล Access ทั้งหมดสามารถอยู่ในไฟล์ฐานข้อมูลเดียว หรืออาจเก็บไว้ในไฟล์ฐานข้อมูลสองไฟล์ ได้แก่ ฐานข้อมูลส่วนหน้าและฐานข้อมูลส่วนหลัง ซึ่งเรียกว่า การแยกฐานข้อมูล และถูกออกแบบมาเพื่ออํานวยความสะดวกในการแชร์ในสภาพแวดล้อมเครือข่าย ไฟล์ฐานข้อมูลส่วนหลังต้องมีเฉพาะตารางและความสัมพันธ์เท่านั้น ไฟล์ Front-End ต้องมีเฉพาะวัตถุอื่นๆ ทั้งหมด รวมถึงฟอร์ม รายงาน คิวรี แมโคร มอดูล VBA และตารางที่ลิงก์ไปยังฐานข้อมูลส่วนหลัง เมื่อคุณโยกย้ายฐานข้อมูล Access จะคล้ายกับฐานข้อมูลแยกในที่ SQL Server ทําหน้าที่เป็น Back-end ใหม่สําหรับข้อมูลที่อยู่บนเซิร์ฟเวอร์
ด้วยเหตุนี้ คุณยังคงสามารถเก็บรักษาฐานข้อมูล Access ส่วนหน้าด้วยตารางที่ลิงก์ไปยังตาราง SQL Server ได้ อย่างมีประสิทธิภาพ คุณสามารถได้รับประโยชน์จากการพัฒนาแอปพลิเคชันอย่างรวดเร็วที่ฐานข้อมูล Access มีให้ พร้อมกับความสามารถในการปรับขนาดของ SQL Server
ประโยชน์ของ SQL Server
ยังต้องการความโน้มน้าวในการโยกย้ายไปยัง SQL Server อยู่หรือไม่ ต่อไปนี้คือประโยชน์เพิ่มเติมบางประการที่ควรคํานึงถึง:
-
ผู้ใช้ที่เกิดขึ้นพร้อมกันมากขึ้น SQL Server สามารถจัดการกับผู้ใช้ที่ใช้พร้อมกันได้มากกว่า Access และลดความต้องการด้านหน่วยความจําเมื่อมีผู้ใช้เพิ่มมากขึ้น
-
เพิ่มความพร้อมใช้งาน ด้วย SQL Server คุณสามารถสํารองข้อมูลแบบไดนามิก ได้ ทั้งแบบเพิ่มหน่วยหรือแบบสมบูรณ์ ฐานข้อมูลขณะใช้งาน ดังนั้น คุณไม่จําเป็นต้องบังคับให้ผู้ใช้ออกจากฐานข้อมูลเพื่อสํารองข้อมูล
-
ประสิทธิภาพและความสามารถในการปรับขนาดสูง โดยปกติฐานข้อมูล SQL Server จะทํางานได้ดีกว่าฐานข้อมูล Access โดยเฉพาะกับฐานข้อมูลขนาดใหญ่ขนาดเทราไบต์ นอกจากนี้ SQL Server ยังประมวลผลคิวรีได้รวดเร็วและมีประสิทธิภาพมากโดยการประมวลผลคิวรีควบคู่กัน โดยใช้เธรดภายในกระบวนการเดียวเพื่อจัดการกับการร้องขอของผู้ใช้
-
ความปลอดภัยที่ได้รับการปรับปรุง เมื่อใช้การเชื่อมต่อที่เชื่อถือได้ SQL Server จะรวมเข้ากับความปลอดภัยของระบบ Windows เพื่อให้สามารถเข้าถึงเครือข่ายและฐานข้อมูลแบบรวมศูนย์โดยใช้ระบบความปลอดภัยที่ดีที่สุดทั้งสองระบบ ซึ่งทําให้การจัดการแบบแผนการรักษาความปลอดภัยที่ซับซ้อนง่ายขึ้นมาก SQL Server เป็นที่เก็บข้อมูลที่เหมาะสําหรับข้อมูลที่ละเอียดอ่อน เช่น หมายเลขประกันสังคม ข้อมูลบัตรเครดิต และที่อยู่ที่เป็นความลับ
-
ความสามารถในการกู้คืนทันที ถ้าระบบปฏิบัติการหยุดทํางานหรือไฟฟ้าดับ SQL Server สามารถกู้คืนฐานข้อมูลให้อยู่ในสถานะที่สอดคล้องกันได้โดยอัตโนมัติในเวลาไม่กี่นาที และไม่มีผู้ดูแลระบบฐานข้อมูลแทรกแซง
-
การใช้ VPN การเข้าถึงและเครือข่ายส่วนตัวเสมือน (VPN) ไม่เข้ากัน แต่ด้วย SQL Server ผู้ใช้ระยะไกลยังคงสามารถใช้ฐานข้อมูลส่วนหน้าของ Access บนเดสก์ท็อปและส่วนหลังของ SQL Server ที่อยู่ด้านหลังไฟร์วอลล์ VPN ได้
-
Azure SQL Server นอกเหนือจากประโยชน์ของ SQL Server แล้ว ยังมีความสามารถในการปรับขนาดแบบไดนามิกโดยไม่มีการหยุดทํางาน การปรับให้เหมาะสมอัจฉริยะ ความสามารถในการปรับขนาดและความพร้อมใช้งานทั่วโลก การขจัดต้นทุนฮาร์ดแวร์ และลดการดูแลระบบลง
เลือกตัวเลือก Azure SQL Server ที่ดีที่สุด
ถ้าคุณกําลังโยกย้ายไปยัง Azure SQL Server จะมีสามตัวเลือกให้เลือก โดยแต่ละตัวเลือกจะมีสิทธิประโยชน์ที่แตกต่างกัน:
-
กลุ่มฐานข้อมูล/กลุ่มความยืดหยุ่นเดียว ตัวเลือกนี้มีชุดทรัพยากรของตนเองที่จัดการผ่านเซิร์ฟเวอร์ฐานข้อมูล SQL ฐานข้อมูลเดียวจะเหมือนกับฐานข้อมูลที่มีอยู่ใน SQL Server คุณยังสามารถเพิ่มพูลแบบยืดหยุ่น ซึ่งเป็นคอลเลกชันของฐานข้อมูลที่มีชุดทรัพยากรที่แชร์ซึ่งจัดการผ่านเซิร์ฟเวอร์ฐานข้อมูล SQL คุณลักษณะของ SQL Server ที่ใช้กันทั่วไปจะพร้อมใช้งานกับการสํารองข้อมูล การปรับปรุง และการกู้คืนในตัว แต่ไม่มีการรับประกันว่าเวลาการบํารุงรักษาและการโยกย้ายจาก SQL Server อาจเป็นเรื่องยาก
-
อินสแตนซ์ที่มีการจัดการ ตัวเลือกนี้คือคอลเลกชันของฐานข้อมูลระบบและฐานข้อมูลผู้ใช้ที่มีชุดทรัพยากรที่ใช้ร่วมกัน อินสแตนซ์ที่มีการจัดการจะเหมือนกับอินสแตนซ์ของฐานข้อมูล SQL Server ที่เข้ากันได้กับ SQL Server ภายในองค์กรเป็นอย่างมาก อินสแตนซ์ที่มีการจัดการมีการสํารองข้อมูล การแก้ไข การกู้คืนในตัว และโยกย้ายจาก SQL Server ได้ง่าย อย่างไรก็ตาม มีจํานวนน้อยของคุณลักษณะ SQL Server ที่ไม่พร้อมใช้งาน และไม่มีการรับประกันเวลาการบํารุงรักษาที่แน่นอน
-
เครื่องเสมือน Azure ตัวเลือกนี้ช่วยให้คุณสามารถเรียกใช้ SQL Server ภายในเครื่องเสมือนในระบบคลาวด์ของ Azure คุณสามารถควบคุมโปรแกรม SQL Server และเส้นทางการโยกย้ายอย่างง่ายได้อย่างเต็มที่ แต่คุณต้องจัดการการสํารองข้อมูล โปรแกรมแก้ไข และการกู้คืนของคุณ
สําหรับข้อมูลเพิ่มเติม ให้ดู การเลือกเส้นทางการโยกย้ายฐานข้อมูลของคุณไปยัง Azure และ Azure SQL คืออะไร
ขั้นตอนแรก
มีปัญหาบางอย่างที่คุณสามารถแก้ไขปัญหาล่วงหน้าที่สามารถช่วยเพิ่มประสิทธิภาพกระบวนการโยกย้ายก่อนที่คุณจะเรียกใช้ SSMA:
-
เพิ่มดัชนีตารางและคีย์หลัก ตรวจสอบให้แน่ใจว่าแต่ละตาราง Access มีดัชนีและคีย์หลัก SQL Server ต้องการให้ตารางทั้งหมดมีดัชนีอย่างน้อยหนึ่งดัชนี และจําเป็นต้องมีตารางที่ลิงก์เพื่อให้มีคีย์หลักถ้าตารางสามารถอัปเดตได้
-
ตรวจสอบความสัมพันธ์ของคีย์หลัก/Foreign Key ตรวจสอบให้แน่ใจว่าความสัมพันธ์เหล่านี้ยึดตามเขตข้อมูลที่มีชนิดข้อมูลและขนาดที่สอดคล้องกัน SQL Server ไม่สนับสนุนคอลัมน์ที่รวมกันที่มีชนิดข้อมูลและขนาดต่างกันในข้อจํากัด Foreign Key
-
เอาคอลัมน์สิ่งที่แนบมาออก SSMA จะไม่โยกย้ายตารางที่มีคอลัมน์ สิ่งที่แนบมา
ก่อนที่คุณจะเรียกใช้ SSMA ให้ทําตามขั้นตอนแรกต่อไปนี้
-
ปิดฐานข้อมูล Access
-
ตรวจสอบให้แน่ใจว่าผู้ใช้ปัจจุบันที่เชื่อมต่อกับฐานข้อมูลได้ปิดฐานข้อมูลด้วย
-
ถ้าฐานข้อมูลอยู่ในรูปแบบไฟล์.mdb ให้เอาความปลอดภัยระดับผู้ใช้ออก
-
สํารองฐานข้อมูลของคุณ สําหรับข้อมูลเพิ่มเติม ให้ดู ปกป้องข้อมูลของคุณด้วยกระบวนการสํารองข้อมูลและคืนค่า
เคล็ดลับ พิจารณาติดตั้ง Microsoft SQL Server Express รุ่นบนเดสก์ท็อปของคุณที่รองรับขนาดสูงสุด 10 GB และเป็นวิธีที่ใช้งานฟรีและง่ายกว่าในการดําเนินการและตรวจสอบการโยกย้ายของคุณ เมื่อคุณเชื่อมต่อ ให้ใช้ LocalDB เป็นอินสแตนซ์ฐานข้อมูล
เคล็ดลับ ถ้าเป็นไปได้ ให้ใช้ Access เวอร์ชันสแตนด์อโลน
เรียกใช้ SSMA
Microsoft มี ตัวช่วยการโยกย้าย Microsoft SQL Server (SSMA) เพื่อให้การโยกย้ายง่ายขึ้น SSMA ส่วนใหญ่จะโยกย้ายตารางและคิวรีแบบใช้เลือกข้อมูลที่ไม่มีพารามิเตอร์ ฟอร์ม รายงาน แมโคร และโมดูล VBA จะไม่ถูกแปลง เมตาดาต้า Explorer ของ SQL Server จะแสดงวัตถุฐานข้อมูล Access และวัตถุ SQL Server ของคุณซึ่งอนุญาตให้คุณตรวจทานเนื้อหาปัจจุบันของฐานข้อมูลทั้งสองได้ การเชื่อมต่อทั้งสองนี้จะถูกบันทึกไว้ในไฟล์การโยกย้ายของคุณ คุณควรตัดสินใจถ่ายโอนวัตถุเพิ่มเติมในอนาคต
หมายเหตุ กระบวนการโยกย้ายอาจใช้เวลาสักครู่ขึ้นอยู่กับขนาดของวัตถุฐานข้อมูลของคุณและจํานวนของข้อมูลที่ต้องถูกถ่ายโอน
-
เมื่อต้องการโยกย้ายฐานข้อมูลโดยใช้ SSMA ก่อนอื่นให้ ดาวน์โหลด และติดตั้งซอฟต์แวร์โดยการดับเบิลคลิกที่ไฟล์ MSI ที่ดาวน์โหลด ตรวจสอบให้แน่ใจว่าคุณติดตั้งเวอร์ชัน 32 หรือ 64 บิตที่เหมาะสมสําหรับคอมพิวเตอร์ของคุณ
-
หลังจากติดตั้ง SSMA ให้เปิดบนเดสก์ท็อปของคุณ โดยเฉพาะอย่างยิ่งจากคอมพิวเตอร์ที่มีไฟล์ฐานข้อมูล Access
คุณยังสามารถเปิดฐานข้อมูลบนเครื่องที่สามารถเข้าถึงฐานข้อมูล Access จากเครือข่ายในโฟลเดอร์ที่แชร์ได้
-
ทําตามคําแนะนําเริ่มต้นใน SSMA เพื่อให้ข้อมูลพื้นฐาน เช่น ตําแหน่งที่ตั้ง SQL Server, ฐานข้อมูล Access และวัตถุเพื่อโยกย้าย ข้อมูลการเชื่อมต่อ และระบุว่าคุณต้องการสร้างตารางที่ลิงก์หรือไม่
-
ถ้าคุณกําลังโยกย้ายไปยัง SQL Server 2016 หรือใหม่กว่า และต้องการอัปเดตตารางที่ลิงก์ ให้เพิ่มคอลัมน์ rowversion โดยการเลือก เครื่องมือการตรวจทาน > การตั้งค่าโครงการ > ทั่วไป
เขตข้อมูล rowversion ช่วยหลีกเลี่ยงความขัดแย้งของระเบียน Access จะใช้เขตข้อมูล rowversion นี้ในตารางที่ลิงก์ของ SQL Server เพื่อกําหนดว่าระเบียนถูกอัปเดตล่าสุดเมื่อใด นอกจากนี้ ถ้าคุณเพิ่มเขตข้อมูล rowversion ลงในคิวรี Access จะใช้เขตข้อมูลนั้นเพื่อเลือกแถวอีกครั้งหลังจากการดําเนินการอัปเดต ซึ่งจะช่วยปรับปรุงประสิทธิภาพโดยช่วยหลีกเลี่ยงข้อผิดพลาดในการเขียนที่ขัดแย้งกันและสถานการณ์การลบระเบียนที่อาจเกิดขึ้นเมื่อ Access ตรวจพบผลลัพธ์ที่แตกต่างจากการส่งเดิม เช่น อาจเกิดขึ้นกับชนิดข้อมูลตัวเลขจุดลอยตัวและทริกเกอร์ที่ปรับเปลี่ยนคอลัมน์ อย่างไรก็ตาม หลีกเลี่ยงการใช้เขตข้อมูล rowversion ในแบบฟอร์ม รายงาน หรือโค้ด VBA สําหรับข้อมูลเพิ่มเติม ให้ดูที่ rowversion
หมายเหตุ หลีกเลี่ยงการสับสน rowversion กับการประทับเวลา แม้ว่าคําสําคัญ timestamp เป็นคําเหมือนสําหรับ rowversion ใน SQL Server แต่คุณจะไม่สามารถใช้ rowversion เป็นวิธีประทับเวลารายการข้อมูลได้
-
เมื่อต้องการตั้งค่าชนิดข้อมูลที่แม่นยํา ให้เลือก เครื่องมือตรวจทาน > การตั้งค่าโครงการ > การแมปชนิด ตัวอย่างเช่น ถ้าคุณเก็บเฉพาะข้อความภาษาอังกฤษ คุณสามารถใช้ varchar แทนชนิดข้อมูล nvarchar ได้
แปลงวัตถุ
SSMA จะแปลงวัตถุ Access เป็นวัตถุ SQL Server แต่จะไม่คัดลอกวัตถุทันที SSMA มีรายการของวัตถุต่อไปนี้เพื่อโยกย้าย เพื่อให้คุณสามารถตัดสินใจได้ว่าคุณต้องการย้ายวัตถุเหล่านั้นไปยังฐานข้อมูล SQL Server หรือไม่
-
ตารางและคอลัมน์
-
เลือก คิวรีที่ไม่มีพารามิเตอร์
-
คีย์หลักและคีย์นอก
-
ดัชนีและค่าเริ่มต้น
-
ตรวจสอบข้อจํากัด (อนุญาตคุณสมบัติคอลัมน์ความยาวเป็นศูนย์ กฎการตรวจสอบคอลัมน์ การตรวจสอบความถูกต้องของตาราง)
สําหรับแนวทางปฏิบัติที่ดีที่สุด ให้ใช้รายงานการประเมิน SSMA ซึ่งแสดงผลลัพธ์การแปลง รวมถึงข้อผิดพลาด คําเตือน ข้อความให้ข้อมูล เวลาที่ประเมินสําหรับการดําเนินการโยกย้าย และขั้นตอนการแก้ไขข้อผิดพลาดแต่ละรายการที่ต้องทําก่อนที่คุณจะย้ายวัตถุจริงๆ
การแปลงวัตถุฐานข้อมูลจะใช้ข้อกําหนดวัตถุจากเมตาดาต้าของ Access แปลงเป็น ไวยากรณ์ Transact-SQL (T-SQL) ที่เทียบเท่ากัน แล้วโหลดข้อมูลนี้ลงในโครงการ จากนั้นคุณสามารถดูวัตถุ SQL Server หรือ SQL Azure และคุณสมบัติของวัตถุได้โดยใช้ SQL Server หรือ SQL Azure Metadata Explorer
เมื่อต้องการแปลง โหลด และโยกย้ายวัตถุไปยัง SQL Server ให้ทําตามคําแนะนํานี้
เคล็ดลับ เมื่อคุณโยกย้ายฐานข้อมูล Access ของคุณเรียบร้อยแล้ว ให้บันทึกไฟล์โครงการเพื่อใช้ในภายหลัง เพื่อให้คุณสามารถโยกย้ายข้อมูลของคุณอีกครั้งสําหรับการทดสอบหรือการโยกย้ายขั้นสุดท้าย
เชื่อมโยงตาราง
พิจารณาติดตั้งเวอร์ชันล่าสุดของโปรแกรมควบคุม SQL Server OLE DB และ ODBC แทนการใช้โปรแกรมควบคุม SQL Server ดั้งเดิมที่มาพร้อมกับ Windows ไม่เพียง แต่เป็นโปรแกรมควบคุมที่ใหม่กว่าได้เร็วขึ้น แต่ยังสนับสนุนฟีเจอร์ใหม่ใน Azure SQL ที่โปรแกรมควบคุมก่อนหน้านี้ไม่รองรับ คุณสามารถติดตั้งโปรแกรมควบคุมบนคอมพิวเตอร์แต่ละเครื่องที่ใช้ฐานข้อมูลที่แปลงแล้วได้ สําหรับข้อมูลเพิ่มเติม ให้ดู โปรแกรมควบคุม Microsoft OLE DB 18 สําหรับ SQL Server และ โปรแกรมควบคุม Microsoft ODBC 17 สําหรับ SQL Server
หลังจากที่คุณโยกย้ายตาราง Access คุณสามารถลิงก์ไปยังตารางใน SQL Server ซึ่งตอนนี้โฮสต์ข้อมูลของคุณ การลิงก์โดยตรงจาก Access ยังทําให้คุณสามารถดูข้อมูลของคุณได้ง่ายกว่าการใช้เครื่องมือการจัดการ SQL Server ที่ซับซ้อนมากขึ้น คุณสามารถสอบถามและแก้ไขข้อมูลที่ลิงก์โดยขึ้นอยู่กับสิทธิ์ที่ตั้งค่าโดยผู้ดูแลระบบฐานข้อมูล SQL Server ของคุณ
หมายเหตุ ถ้าคุณสร้าง ODBC DSN เมื่อคุณลิงก์ไปยังฐานข้อมูล SQL Server ของคุณในระหว่างกระบวนการลิงก์ ให้สร้าง DSN เดียวกันบนทุกเครื่องที่ใช้แอปพลิเคชันใหม่หรือใช้สตริงการเชื่อมต่อที่จัดเก็บในไฟล์ DSN โดยทางโปรแกรม
สําหรับข้อมูลเพิ่มเติม ให้ดู ลิงก์หรือนําเข้าข้อมูลจากฐานข้อมูล Azure SQL Server และ นําเข้าหรือลิงก์ไปยังข้อมูลในฐานข้อมูล SQL Server
เคล็ดลับ อย่าลืมใช้ตัวจัดการตารางที่ลิงก์ใน Access เพื่อรีเฟรชและลิงก์ตารางใหม่ได้อย่างสะดวก สําหรับข้อมูลเพิ่มเติม ให้ดูที่ จัดการตารางที่ลิงก์
ทดสอบและแก้ไข
ส่วนต่อไปนี้จะอธิบายปัญหาทั่วไปที่คุณอาจพบระหว่างการโยกย้ายและวิธีจัดการกับปัญหาเหล่านั้น
คิวรี
คิวรีแบบใช้เลือกข้อมูลเท่านั้นที่จะถูกแปลง คิวรีอื่นๆ จะไม่รวมถึงคิวรีแบบใช้เลือกข้อมูลที่ใช้พารามิเตอร์ คิวรีบางรายการอาจไม่แปลงอย่างสมบูรณ์ และข้อผิดพลาดคิวรีรายงาน SSMA ระหว่างกระบวนการแปลง คุณสามารถแก้ไขวัตถุที่ไม่แปลงด้วยตนเองได้โดยใช้ไวยากรณ์ T-SQL นอกจากนี้ ข้อผิดพลาดทางไวยากรณ์ยังอาจต้องใช้การแปลงฟังก์ชันและชนิดข้อมูลเฉพาะของ Access ไปเป็นฟังก์ชัน SQL Server ด้วย สำหรับข้อมูลเพิ่มเติม ให้ดู การเปรียบเทียบ Access SQL กับ SQL Server TSQL
ชนิดข้อมูล
Access และ SQL Server มีชนิดข้อมูลที่คล้ายกัน แต่ต้องระวังปัญหาที่อาจเกิดขึ้นต่อไปนี้
ตัวเลขขนาดใหญ่ ชนิดข้อมูลตัวเลขขนาดใหญ่จะจัดเก็บค่าตัวเลขที่ไม่ใช่ค่าเงินและเข้ากันได้กับชนิดข้อมูล bigint ของ SQL คุณสามารถใช้ชนิดข้อมูลนี้เพื่อคํานวณตัวเลขจํานวนมากได้อย่างมีประสิทธิภาพ แต่ต้องใช้รูปแบบไฟล์ฐานข้อมูล .accdb ของ Access 16 (16.0.7812 หรือใหม่กว่า) และทํางานได้ดียิ่งขึ้นด้วย Access เวอร์ชัน 64 บิต สําหรับข้อมูลเพิ่มเติม ให้ดู การใช้ชนิดข้อมูลตัวเลขขนาดใหญ่ และ เลือกระหว่าง Office เวอร์ชัน 64 บิตหรือ 32 บิต
ใช่/ไม่ใช่ ตามค่าเริ่มต้น คอลัมน์ ใช่/ไม่ใช่ ของ Access จะถูกแปลงเป็นเขตข้อมูลบิตของ SQL Server เพื่อหลีกเลี่ยงการล็อกระเบียน ตรวจสอบให้แน่ใจว่าได้ตั้งค่าเขตข้อมูลบิตเป็นไม่อนุญาตให้มีค่า NULL ใน SSMA คุณสามารถเลือกคอลัมน์บิตเพื่อตั้งค่าคุณสมบัติ Allow Nulls เป็น NO ใน TSQL ให้ใช้คําสั่ง CREATE TABLE หรือ ALTER TABLE
วันที่และเวลา มีข้อควรพิจารณาเกี่ยวกับวันที่และเวลาอยู่หลายข้อ:
-
ถ้าระดับความเข้ากันได้ของฐานข้อมูลคือ 130 (SQL Server 2016) หรือสูงกว่า และตารางที่ลิงก์มีคอลัมน์วันที่เวลาหรือวันที่เวลา 2 อย่างน้อยหนึ่งคอลัมน์ ตารางอาจส่งกลับข้อความ #deleted ในผลลัพธ์ สําหรับข้อมูลเพิ่มเติม ให้ดูที่ ตารางที่ลิงก์กับฐานข้อมูล Access SQL-Server จะส่งกลับ #deleted
-
ใช้ชนิดข้อมูลวันที่/เวลาของ Access เพื่อแมปไปยังชนิดข้อมูลเวลาวันที่ ใช้ชนิดข้อมูลวันที่/เวลาที่ขยายของ Access เพื่อแมปไปยังชนิดข้อมูล datetime2 ซึ่งมีช่วงวันที่และเวลาที่ใหญ่กว่า สําหรับข้อมูลเพิ่มเติม ให้ดูที่ การใช้ชนิดข้อมูลวันที่/เวลาที่ขยาย
-
เมื่อทําคิวรีสําหรับวันที่ใน SQL Server ให้คํานึงถึงเวลาและวันที่ ตัวอย่างเช่น
-
วันที่สั่งซื้อระหว่าง 1/1/19 และ 31/1/19 อาจไม่รวมคําสั่งซื้อทั้งหมด
-
วันที่สั่งซื้อระหว่าง 1/1/19 00:00:00 AM และ 31/1/19 11:59:59 PM จะรวมคําสั่งซื้อทั้งหมด
-
สิ่งที่แนบมา ชนิดข้อมูลของสิ่งที่แนบมาจะเก็บไฟล์ไว้ในฐานข้อมูล Access ใน SQL Server คุณมีตัวเลือกมากมายให้พิจารณา คุณสามารถแยกไฟล์ออกจากฐานข้อมูล Access แล้วพิจารณาจัดเก็บลิงก์ไปยังไฟล์ในฐานข้อมูล SQL Server ของคุณ อีกวิธีหนึ่งคือ คุณสามารถใช้ FILESTREAM, FileTables หรือ Remote BLOB Store (RBS) เพื่อเก็บสิ่งที่แนบมาไว้ในฐานข้อมูล SQL Server
เชื่อม โยง หลาย มิติ ตาราง Access มีคอลัมน์ไฮเปอร์ลิงก์ที่ SQL Server ไม่สนับสนุน ตามค่าเริ่มต้น คอลัมน์เหล่านี้จะถูกแปลงเป็นคอลัมน์ nvarchar(max) ใน SQL Server แต่คุณสามารถกําหนดการแมปเองเพื่อเลือกชนิดข้อมูลที่เล็กลงได้ ในโซลูชัน Access ของคุณ คุณยังคงสามารถใช้ลักษณะการทํางานของไฮเปอร์ลิงก์ในฟอร์มและรายงานได้ ถ้าคุณตั้งค่าคุณสมบัติ ไฮเปอร์ลิงก์ สําหรับตัวควบคุมเป็นจริง
เขตข้อมูลแบบหลายค่า เขตข้อมูลแบบหลายค่าของ Access จะถูกแปลงเป็น SQL Server เป็นเขตข้อมูล ntext ที่มีชุดของค่าที่ใช้ตัวคั่น เนื่องจาก SQL Server ไม่สนับสนุนชนิดข้อมูลที่มีหลายค่าซึ่งสร้างรูปแบบความสัมพันธ์แบบกลุ่มต่อกลุ่ม อาจจำเป็นต้องมีการออกแบบและทำการแปลงเพิ่มเติม
สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการแมปชนิดข้อมูล Access และ SQL Server ให้ดูที่ เปรียบเทียบชนิดข้อมูล
หมายเหตุ เขตข้อมูลที่มีหลายค่าจะไม่ถูกแปลง
สําหรับข้อมูลเพิ่มเติม ให้ดูที่ ชนิดวันที่และเวลา, ชนิดสตริงและไบนารี และ ชนิดตัวเลข
Visual Basic
แม้ว่า VBA จะไม่ได้รับการสนับสนุนโดย SQL Server ให้สังเกตปัญหาที่เป็นไปได้ต่อไปนี้:
ฟังก์ชัน VBA ในคิวรี คิวรี Access สนับสนุนฟังก์ชัน VBA บนข้อมูลในคอลัมน์คิวรี แต่คิวรี Access ที่ใช้ฟังก์ชัน VBA ไม่สามารถเรียกใช้บน SQL Server ได้ ดังนั้นข้อมูลที่ร้องขอทั้งหมดจะถูกส่งผ่านไปยัง Microsoft Access เพื่อดําเนินการ ในกรณีส่วนใหญ่ คิวรีเหล่านี้ควรถูกแปลงเป็นคิวรีแบบพาส-ทรู
ฟังก์ชันที่ผู้ใช้กําหนดเองในแบบสอบถาม คิวรี Microsoft Access สนับสนุนการใช้ฟังก์ชันที่กําหนดไว้ในมอดูล VBA เพื่อประมวลผลข้อมูลที่ส่งผ่านไปยังคิวรีเหล่านั้น คิวรีสามารถเป็นคิวรีแบบสแตนด์อโลน คําสั่ง SQL ในแหล่งระเบียนฟอร์ม/รายงาน แหล่งข้อมูลของกล่องคําสั่งผสมและกล่องรายการบนฟอร์ม รายงานและเขตข้อมูลตาราง และนิพจน์กฎเริ่มต้นหรือการตรวจสอบ SQL Server ไม่สามารถเรียกใช้ฟังก์ชันที่ผู้ใช้กําหนดเองเหล่านี้ได้ คุณอาจต้องออกแบบฟังก์ชันเหล่านี้ใหม่ด้วยตนเอง และแปลงเป็นกระบวนงานที่เก็บไว้บน SQL Server
ปรับประสิทธิภาพให้เหมาะสม
วิธีที่สําคัญที่สุดในการปรับประสิทธิภาพให้เหมาะสมด้วย SQL Server แบบใหม่ส่วนหลังคือการตัดสินใจว่าควรใช้คิวรีภายในหรือระยะไกลเมื่อใด เมื่อคุณโยกย้ายข้อมูลของคุณไปยัง SQL Server คุณกําลังย้ายจากเซิร์ฟเวอร์ไฟล์ไปยังรูปแบบฐานข้อมูลไคลเอ็นต์เซิร์ฟเวอร์ของการคํานวณด้วย ทําตามคําแนะนําทั่วไปเหล่านี้:
-
เรียกใช้คิวรีแบบอ่านอย่างเดียวขนาดเล็กบนไคลเอ็นต์เพื่อการเข้าถึงที่รวดเร็วที่สุด
-
เรียกใช้คิวรีการอ่าน/เขียนบนเซิร์ฟเวอร์เป็นเวลานานเพื่อใช้ประโยชน์จากพลังการประมวลผลที่มากขึ้น
-
ลดปริมาณการใช้งานเครือข่ายด้วยตัวกรองและการรวมเพื่อถ่ายโอนเฉพาะข้อมูลที่คุณต้องการเท่านั้น
สําหรับข้อมูลเพิ่มเติม ให้ดู สร้างคิวรีแบบพาส-ทรู
ต่อไปนี้เป็นแนวทางเพิ่มเติมที่แนะนํา
วางตรรกะบนเซิร์ฟเวอร์ แอปพลิเคชันของคุณยังสามารถใช้มุมมอง ฟังก์ชันที่ผู้ใช้กําหนดเอง กระบวนงานที่เก็บไว้ เขตข้อมูลจากการคํานวณ และทริกเกอร์เพื่อรวมและแชร์ตรรกะแอปพลิเคชัน กฎและนโยบายทางธุรกิจ คิวรีที่ซับซ้อน การตรวจสอบความถูกต้องของข้อมูล และโค้ด Referential Integrity บนเซิร์ฟเวอร์ แทนที่จะเป็นไคลเอ็นต์ ถามตัวคุณเองว่าคิวรีหรืองานนี้สามารถทํางานบนเซิร์ฟเวอร์ได้ดีขึ้นและเร็วขึ้นหรือไม่ สุดท้าย ทดสอบแต่ละคิวรีเพื่อให้แน่ใจถึงประสิทธิภาพสูงสุด
ใช้มุมมองในฟอร์มและรายงาน ใน Access ให้ทําดังต่อไปนี้:
-
สําหรับฟอร์ม ให้ใช้มุมมอง SQL สําหรับฟอร์มแบบอ่านอย่างเดียวและมุมมองที่มีการทําดัชนีของ SQL สําหรับฟอร์มแบบอ่าน/เขียนเป็นแหล่งระเบียน
-
สําหรับรายงาน ให้ใช้มุมมอง SQL เป็นแหล่งระเบียน อย่างไรก็ตาม ให้สร้างมุมมองแยกต่างหากสําหรับแต่ละรายงาน เพื่อให้คุณสามารถอัปเดตรายงานเฉพาะได้อย่างง่ายดายโดยไม่มีผลกระทบต่อรายงานอื่นๆ
ย่อการโหลดข้อมูลในฟอร์มหรือรายงานให้น้อยที่สุด ไม่ต้องแสดงข้อมูลจนกว่าผู้ใช้จะขอข้อมูลนั้น ตัวอย่างเช่น ให้ปล่อยคุณสมบัติ recordsource ให้ว่าง ทําให้ผู้ใช้เลือกตัวกรองบนฟอร์มของคุณ แล้วใส่คุณสมบัติ recordsource ลงในตัวกรองของคุณ หรือใช้ส่วนคําสั่ง where ของ DoCmd.OpenForm และ DoCmd.OpenReport เพื่อแสดงระเบียนที่ผู้ใช้ต้องการ พิจารณาปิดการนําทางระเบียน
โปรดใช้ความระมัดระวังในการสอบถามต่างๆ หลีกเลี่ยงการเรียกใช้คิวรีที่รวมตาราง Access ภายในเครื่องและตารางที่ลิงก์ของ SQL Server ซึ่งบางครั้งเรียกว่าคิวรีแบบไฮบริด คิวรีชนิดนี้ยังต้องการให้ Access ดาวน์โหลดข้อมูล SQL Server ทั้งหมดไปยังเครื่องภายใน แล้วเรียกใช้คิวรี คิวรีจะไม่เรียกใช้คิวรีใน SQL Server
เมื่อใดควรใช้ตารางภายในเครื่อง พิจารณาใช้ตารางภายในเครื่องสําหรับข้อมูลที่ไม่ค่อยมีการเปลี่ยนแปลง เช่น รายการของรัฐหรือจังหวัดในประเทศหรือภูมิภาค ตารางแบบคงที่มักจะใช้สําหรับการกรองและสามารถทํางานได้ดียิ่งขึ้นในส่วนหน้าของ Access
สําหรับข้อมูลเพิ่มเติม ให้ดู โปรแกรมช่วยแนะนําการปรับกลไกจัดการฐานข้อมูลใช้ตัววิเคราะห์ประสิทธิภาพเพื่อปรับฐานข้อมูล Access ให้เหมาะสม และ การปรับแอปพลิเคชัน Microsoft Office Access ที่ลิงก์กับ SQL Server ให้เหมาะสม
ดูเพิ่มเติม
คู่มือการโยกย้ายฐานข้อมูล Azure
บล็อกการโยกย้ายข้อมูลของ Microsoft
Microsoft Access ไปยังการโยกย้าย SQL Server, การแปลง และการปรับให้ใช้กับระบบที่ใหญ่ขึ้น