แนวทางปฏิบัติที่ดีที่สุดสำหรับการย้ายแอปพลิเคชัน MS Access ขนาดใหญ่ไปยัง. Net?

เรามีแอปพลิเคชั่น MS Access ขนาดใหญ่มากที่พัฒนาขึ้นภายในองค์กรเพื่อความต้องการส่วนบุคคลของเราซึ่งต่อมาได้กลายเป็นซอฟต์แวร์เชิงพาณิชย์และขายได้สำเร็จ ซอฟต์แวร์นี้เป็น "all-round-software-for-your-business" และมีหลายโมดูลรวมถึงระบบการจัดการเอกสารการวางแผนทรัพยากรองค์กรการจัดการสินค้าคงคลังการจัดการลูกค้าสัมพันธ์การวิเคราะห์ข้อมูลและอื่น ๆ เราค่อนข้างพอใจกับปัจจุบัน ฟังก์ชันการทำงานของแอปพลิเคชัน แต่เพื่อตอบสนองคำขอจากลูกค้าของเราเราตระหนักว่าเราต้องย้ายไปยังสิ่งใหม่

เราตัดสินใจที่จะค่อยๆย้ายแอปพลิเคชันของเราไปยัง. Net เพราะเราสามารถติดกับ Visual Basic .Net: แม้ว่ามันจะเป็นภาษาใหม่สำหรับนักพัฒนาส่วนใหญ่ที่นี่เรามีความรู้เชิงลึกเกี่ยวกับ VBA และโครงการขนาดเล็กจำนวนมาก

เราได้เริ่มย้ายฟังก์ชันการทำงานของชั้นข้อมูลของแอปพลิเคชันของเราไปยัง MS SQL Server เพื่อให้ทุกการจัดการข้อมูลและการค้นหาทำได้โดยตรงบนเซิร์ฟเวอร์

สิ่งที่เรากำลังมองหาคือแนวปฏิบัติที่ดีที่สุดสำหรับการค่อย ๆ เคลื่อน GUI ที่กว้างขวางของเรา (ประมาณ 500-600 รูปแบบที่แตกต่างกันรวมถึงฟอร์มย่อยรายงานประมาณ 200 ฉบับพร้อมการสนับสนุนหลายภาษาเป็นต้น) การติดตามคำขอล่าสุดจากลูกค้าที่มีศักยภาพของเราในการใช้การเข้ารหัสข้อมูลแบบอะซิงโครนัสบนเอกสารใน DMS เรายินดีที่จะแยกส่วนนี้ออกจาก MS Access อย่างสมบูรณ์และนำไปใช้ใน. Net

คำถามคือทำอย่างไรจึงจะรวมแอปพลิเคชั่น. Net เข้ากับระบบ MS Access ที่มีอยู่ได้อย่างราบรื่นเพื่อให้เราสามารถเรียกใช้พารามิเตอร์บางตัว (สิทธิ์ผู้ใช้เป็นต้น) และเปิดใช้งานการแลกเปลี่ยนข้อมูลระหว่างแอปพลิเคชันนี้

แก้ไข:

เราพยายามใช้แนวทางปฏิบัติบางอย่างจากหนังสือของมาร์ตินฟาวเลอร์ " รูปแบบการรวมกันขององค์กร " เพื่อให้เกิดการบูรณาการระหว่างแอปพลิเคชัน MS Access และยูทิลิตี้ขนาดเล็กบางอย่างที่เรานำมาใช้ใน. Net แต่เราจัดการเพื่อใช้รูปแบบ "ฐานข้อมูลที่ใช้ร่วมกัน" เท่านั้นและไม่พอใจกับโซลูชันของเราจริงๆ

ตัวอย่างเช่นเราใช้ยูทิลิตี้ขนาดเล็กที่ทำงานเป็นบริการของ Windows ซึ่งจะดาวน์โหลดข้อความทั้งหมดจากเมลเซิร์ฟเวอร์โดยอัตโนมัติโดยใช้การเชื่อมต่อ POP3 และเก็บไว้ในตารางเดียวในขณะที่สิ่งที่แนบมาทั้งหมดจะถูกเก็บไว้ในระบบไฟล์

สิ่งที่เราทำส่วนใหญ่คือเราใช้ ADO.NET เพื่อเข้าถึงฐานข้อมูล MS Access โดยตรงในรูปแบบ MDB และเติมตารางด้วยข้อมูลที่ประมวลผลบางส่วน (เช่นข้อมูลเกี่ยวกับข้อความอีเมลจากตัวอย่างข้างต้น: เรามีฟิลด์สำหรับ FROM, TO, CC, BCC, หัวเรื่องและร่างกาย)

ไม่มีปัญหาในการทำงานกับรูปแบบข้อมูล MDB จาก. Netยิ่งไปกว่านั้นเราไม่ต้องการอยู่กับ MDB และเพิ่มพูนเกือบทุกอย่างให้กับ MS SQL Server 2008 - สิ่งนี้ทำให้เรามีอิสระมากขึ้นเกี่ยวกับการจัดการข้อมูลและความยืดหยุ่น

ปัญหาหลักที่นี่คือเราไม่รู้วิธีการใช้ "การติดต่อกลับ"ใน Access เพื่อให้เราสามารถเรียกใช้งานโค้ด VBA บางตัวในการอัพเดทข้อมูล

เรามีความหวังอย่างยิ่งกับ MS Access 2010 ที่รองรับการอัปเดตและแทรกทริกเกอร์สำหรับตารางข้อมูลแต่ปรากฎว่าเราสามารถใช้ MS Access Macros สำหรับทริกเกอร์เหล่านี้ได้เท่านั้นและไม่มีวิธีเรียกใช้โค้ด VBA ที่กำหนดเองภายในไก

นอกจากนี้เรายังลองวิธีการแก้ปัญหาด้วยการส่งการกดแป้นพิมพ์โดยตรงไปที่หน้าต่าง MS Accessเพื่อเลียนแบบแบบสอบถามข้อมูลที่ผู้ใช้เรียกใช้ ใช้งานได้ แต่เราไม่คิดว่านี่เป็นโซลูชันที่ใช้งานได้จริงซึ่งสามารถนำมาใช้ในการผลิตได้

นอกจากนี้เรายังค้นหา DDE สำหรับ MS Access ด้วย แต่เราไม่พบโซลูชันตัวอย่างที่ดีใด ๆ ที่ใช้คำสั่ง DDEและใช้พวกมันสำหรับข้อมูลในหน่วยความจำและการแลกเปลี่ยนคำสั่ง

ดังนั้นปัญหาหลักคือการมี MS Access และ. Net application อยู่ร่วมกันและโต้ตอบกัน

แก้ไข 2 :

ฉันลืมที่จะพูดถึงสิ่งที่เรายังใช้ไลบรารี MSMQ ใน VBAสำหรับการส่งข้อความระหว่าง. Net และ MS Access ปัญหาคือการขาดการติดต่อกลับที่นี่: เราต้องสำรวจคิวสำหรับข้อความใหม่และ VBA ไม่สนับสนุนจริงๆ หลายเธรดมันไม่ได้เป็นทางออกที่ดีจริงๆ

นี่จะเป็นโครงการขนาดใหญ่และเกี่ยวข้องมาก ฉันต้องรับผิดชอบในการโยกย้ายฐานข้อมูล Access ไปยัง. NET หลายครั้ง แต่ไม่เคยอยู่ในระดับนี้ ฉันยอมรับว่าวิธีการแบบค่อยเป็นค่อยไปอาจเป็นจริงที่สุด การพยายามทำทุกอย่างในนัดเดียวเป็นวิธีที่ล้มเหลวง่าย

เช่นเดียวกับคำตอบอื่น ๆ ขั้นตอนแรกและสำคัญที่สุดคือการย้ายทุกอย่างไปยัง SQL Server ขณะทำสิ่งนี้ให้บันทึกฐานข้อมูลหากยังไม่ได้ดำเนินการและระบุพื้นที่สำหรับการปรับโครงสร้างใหม่หากมีอยู่ เข้าถึงฐานข้อมูลที่เติบโตเพื่อตอบสนองความต้องการที่เปลี่ยนแปลงบ่อยครั้งมีตัวแบบข้อมูลที่สามารถปรับปรุงให้ดีขึ้นเมื่อดูภาพรวม

ถัดไประบุโมดูลของแอปพลิเคชันที่ "อยู่ในตัวเอง" เนื่องจากนี่เป็นฐานข้อมูลทำทุกอย่างอาจมีโมดูลของโมดูลที่แยกออกจากกันเกือบทั้งหมด หลังจากมีชิ้นส่วนแยกเหล่านี้ให้ระบุหนึ่งในโมดูลขนาดเล็กที่มีประโยชน์มากที่สุดจากการได้รับการอัปเดตและนำไปใช้ก่อน

ขณะที่ย้ายไปยัง. NET อย่าเพิ่งทำสำเนาแอพพลิเคชั่น 1 ถึง 1 อย่างง่าย ๆ รวบรวมข้อมูลจากผู้ใช้เพื่อระบุจุดปวดด้วยแอปพลิเคชันปัจจุบัน คุณต้องการให้หน่วยการโยกย้ายครั้งแรกของคุณประสบความสำเร็จอย่างมากในการได้รับการซื้ออย่างสมบูรณ์จากทุกคน

หลังจากที่คุณทำยูนิตแรกเสร็จแล้วให้ดูสิ่งที่เกิดขึ้นในแง่ของความท้าทายความยุ่งยาก ฯลฯ และใช้สิ่งนี้ก้าวไปข้างหน้า

สิ่งหนึ่งที่ฉันขอแนะนำอย่างยิ่งคือการใช้โมดูลการทำงานบางส่วน (เช่น: "เราย้ายข้อมูล CRM แต่คุณสมบัติ X, Y, Z ยังไม่ได้อยู่ในระบบใหม่") สิ่งนี้จะทำให้ผู้ใช้รู้สึกหงุดหงิดอย่างรวดเร็วจากการมีระบบที่ไม่สมบูรณ์เมื่อระบบเก่าของพวกเขานั้น "ดีมาก" การพัฒนาแบบนี้อาจทำงานได้ดีสำหรับโดเมนอื่น แต่ไม่ใช่ในธุรกิจที่ผู้ใช้เห็น "ไม่มีอะไรผิดปกติ" กับ monolith Access เก่าและไม่เข้าใจความต้องการการโยกย้าย

นี่คือแผนที่จะเปลี่ยนแอปพลิเคชัน MS Access ของคุณให้เป็นแอปพลิเคชัน VB.Net โดยการกลายพันธุ์

นี่ไม่ใช่แผนทั่วไปแผนต่อไปนี้ขึ้นอยู่กับโครงการที่คุณอธิบาย

ขั้นตอนที่ 1: ย้ายข้อมูลทั้งหมดไปยัง SQL Server

อย่าใช้ ODBC สำหรับการเชื่อมต่อการเข้าถึง SQL Server ใช้ Access Project (ADP) แทน Access Project เป็นไฟล์ Access ที่มีนามสกุล. adp แต่ก็มีคุณสมบัติการเข้าถึงอย่างเต็มรูปแบบ (มาโครฟอร์มรายงานโมดูล) แต่การเชื่อมต่อนั้นโดยตรงบนฐานข้อมูล SQL Server แทนที่จะเป็นไฟล์ MDB ไฟล์ ADP เข้ากันได้กับไฟล์ MDB ดูเหมือนว่าพวกเขาจะไม่ได้รับการสนับสนุนใน Access 2010 ในขณะที่ในความเป็นจริงคุณลักษณะถูกซ่อนอยู่ แต่ได้รับการสนับสนุนเป็นอย่างดี เช่นเดียวกับ MDE ไฟล์ ADP สามารถ "รวบรวม" เป็นไฟล์ ADE

การย้ายไปยัง SQL Server จะมีค่าใช้จ่ายในการปรับเปลี่ยนโครงสร้างข้อมูลและรหัสน้อยมาก แต่ทั้งหมดนี้ค่อนข้างง่ายต่อการโยกย้าย และเป็นเป้าหมายสุดท้ายหลังจากทั้งหมด

ลืมเกี่ยวกับการทริกเกอร์เหตุการณ์ฐานข้อมูลไปยังรหัส VBA หรือ VB.Net ในทางเทคนิคสามารถทำได้โดยใช้ SQL Server Extended Stored Procedure แต่เป็นกลอุบายที่แย่มาก โครงการของคุณมีชีวิตในอนาคตดังนั้นจึงเป็นการดีกว่าที่จะบังคับใช้โครงสร้างข้อมูลโดยหลีกเลี่ยงการทำลายโครงสร้าง โดยทั่วไปเล่นด้วยทริกเกอร์ฐานข้อมูลมันฉลาด แต่ค่อนข้างยากที่จะรักษา

ขั้นตอนที่ 2: สร้างชุดการตรวจสอบสิทธิ์

เป็นสิ่งที่ดีที่แอปพลิเคชันของคุณไม่ได้อยู่ที่ความปลอดภัยของ Access (ไฟล์ MDW)

จัดทำแผนสำหรับการรับรองความถูกต้องเป้าหมายสำหรับแอปพลิเคชัน VB.Net แล้วกำหนดวิธีการโยกย้ายการรับรองความถูกต้องของการเข้าถึงไปยังเป้าหมายนี้เพื่อให้มีการรับรองความถูกต้องที่เหมือนกันระหว่างสองแอปพลิเคชัน

เนื่องจากการตรวจสอบความถูกต้องตามขวางในสถาปัตยกรรมแอปพลิเคชันสิ่งนี้จะง่ายกว่าในการแบ่งระหว่างเวอร์ชัน Access กับเวอร์ชัน VB.Net

ขั้นตอนที่ 3: เตรียมคุณสมบัติโทเค็นเพื่อสร้างสะพานเชื่อมระหว่าง Access และ VB.Net

คุณกล่าวว่า Access UI จะต้องเปิด VB.Net UI พร้อมกับพารามิเตอร์ที่ถูกต้องและการตรวจสอบสิทธิ์ด้วย และคุณอาจต้องทำแบบเดียวกันในอีกทางหนึ่ง

ทางออกที่ดีคือการสร้างคุณลักษณะโทเค็นขนาดเล็กตามตารางโทเค็น: คอลัมน์สามารถเป็นโทเค็น id (จำนวนเต็ม), คีย์โทเค็น (สตริงยาว) วันที่โทเค็นและรายการพารามิเตอร์ (สตริงหรือข้อความยาว) ทุกครั้งที่ Access จำเป็นต้องเปิดหน้าจอ VB.Net จากนั้นให้บันทึกโทเค็นในฐานข้อมูลด้วยพารามิเตอร์จากนั้นเปิดแอปพลิเคชัน VB.Net ของคุณด้วยรหัสโทเค็นและคีย์โทเค็นเท่านั้น VB.Net เปิดขึ้นค้นหาโทเค็น id ในฐานข้อมูลตรวจสอบคีย์ (สิ่งนี้ใช้เป็นการรับรองความถูกต้อง) และอ่านพารามิเตอร์ จากนั้นมันจะเปิดไปยังแบบฟอร์มที่เกี่ยวข้องและทำสิ่งที่จำเป็น อย่าลืมให้เวลากับโทเค็นและทำความสะอาดโทเค็นเก่า ๆ

หากคุณต้องการโทรกลับจาก VB.Net ไปยัง Access (คุณอาจจะ) ฉันคิดว่ามันเป็นไปได้ที่จะเปิดใช้งานรหัส VBA บางส่วนในไฟล์ MDB Access ที่เปิดอยู่โดยใช้ OLE

ขั้นตอนที่ 4: โยกย้าย UI และหน้าจอโมดูลโดยหน้าจอโมดูลโดยโมดูล

ตอนนี้การเตรียมการครั้งใหญ่เสร็จสิ้นแล้ว คุณสามารถเริ่มโยกย้ายส่วนติดต่อผู้ใช้จาก Ms Access ไปยัง VB.Net

ไม่มีเครื่องมืออัตโนมัติที่ดีสำหรับการทำเช่นนี้ VBA และ. Net แตกต่างกันเกินไป คุณต้องเตรียมงานของคุณสำหรับการโยกย้ายดังกล่าว เริ่มด้วยรูปแบบขนาดเล็กเช่นกล่อง "เกี่ยวกับ" และดำเนินการต่อจากรูปแบบง่าย ๆ ไปยังรูปแบบที่ซับซ้อน แน่นอนว่าคุณจะต้องรวมกลุ่มและกำหนดเวลาการย้ายข้อมูลบางอย่าง แต่คุณจะค่อยๆย้ายหน้าจอรายงานและไลบรารีของคุณจาก Ms Access ไปยัง VB.Net

ฉันประหลาดใจที่คุณทำทุกอย่างด้วย Access มีคำถามที่สำคัญมากที่คุณไม่ได้ขอ. NET Windows Forms หรือ. NET WPF WPF มีช่วงการเรียนรู้ที่สูงชัน แต่ในความคิดของฉันมันมีประสิทธิภาพมากขึ้นด้วย UI ที่ดีกว่า เมื่อเร็ว ๆ นี้เราได้แปลงแอปพลิเคชันเชิงพาณิชย์ของเราจาก Forms เป็น WPF และเราได้รับยอดขายเพิ่มขึ้นแล้ว เรายังเพิ่มคุณสมบัติใหม่ แต่ WPF UI นั้นเป็นเรื่องที่เซ็กซี่กว่า ตรวจสอบการออกแบบตารางของคุณและทำความสะอาด - ตอนนี้เป็นเวลา ตรวจสอบให้แน่ใจว่าคุณกำลังประกาศ FKs ทั้งหมดของคุณ ใน Access คุณสามารถเพิ่มสิ่งต่าง ๆ ได้อย่างง่ายดายในบางครั้งที่สิ่งนั้นหลุด ถ้านี่คือ WPF UI แรกของคุณสร้างต้นแบบบางอย่าง เราสามารถบรรจุมากขึ้นใน WPF ว่าแอปใหม่มีคุณสมบัติมากขึ้นหน้าจอน้อยลงและรหัสน้อยลง คุณจะเปลี่ยนจากการเกลียด XAML ไปเป็นความรัก พิจารณาโครงสร้างอย่าง MVVM

เนื่องจากคุณมีความเข้าใจที่ดีเกี่ยวกับโมเดลวัตถุ Access แล้วฉันคิดว่าคุณต้องการใช้Access Interopจากแอป. NET ของคุณ ควร (มากกว่าหรือน้อยกว่า) อนุญาตให้คุณควบคุมแอป Access โดยอัตโนมัติโดยไม่ต้องเปิดใช้ DDE

ฉันไม่รู้ความรู้เชิงลึกเกี่ยวกับเลเยอร์ตรรกะทางธุรกิจของคุณ แต่คุณสามารถเข้าถึงฐานข้อมูล MS Access ของคุณในแอปพลิเคชัน. NET ของคุณ หากไม่ใช่เพียงการดึงข้อมูลคุณสามารถใช้การเชื่อมต่อ TCP / IP ระหว่างโปรแกรมของคุณ (แอปพลิเคชัน VB6 และ VB.NET) กรุณาดูได้ที่บทความเกี่ยวกับ CodeProject

คุณกำลังขอวิธีปฏิบัติที่ดีที่สุดในการทำสิ่งที่ผิด ไม่มีใคร แนวปฏิบัติที่ดีที่สุดครอบคลุมวิธีการสร้างระบบที่บำรุงรักษาได้อย่างมีประสิทธิภาพดังนั้นแม้ว่ารถบัสจะล้มเหลวและทีมใหม่ทั้งหมดก็ต้องเข้ามาอยู่ในสภาพอากาศหนาวเย็นการพัฒนาและการสนับสนุนสามารถดำเนินต่อไปได้ ระบบที่คุณอธิบายจะส่งนักพัฒนาซอฟต์แวร์ส่วนใหญ่ที่ทำงานให้กับเนินเขา คุณมีผลิตภัณฑ์ที่สร้างขึ้นด้วยเทคโนโลยีที่ล้าสมัยและต้องการเชื่อมต่อกับเทคโนโลยีในปัจจุบัน และคุณต้องการทำโดยไม่ต้องจัดการกับรูปแบบการต่อต้านใด ๆ ที่คุณได้อธิบายไว้สำหรับผลิตภัณฑ์หลัก ผู้พัฒนาที่ยินดีที่จะแก้ไขปัญหานั้นอาจไม่เต็มใจที่จะทำตามเงื่อนไขที่คุณเสนอ

อย่างไรก็ตามรถบัสของคุณไม่ได้ผิดพลาดดังนั้นคุณสามารถใช้ประโยชน์จากทีมที่มีอยู่ที่เข้าใจระบบ วิธีที่ดีที่สุดในการพัฒนาอย่างค่อยเป็นค่อยไปที่ฉันได้พบคือการใช้วิธีการเปรียว สนับสนุนกระบวนการวนซ้ำที่ตอบสนองความต้องการที่มีความเสี่ยงสูงในช่วงต้นและจัดการความต้องการทางธุรกิจได้เป็นอย่างดี

เราตัดสินใจที่จะย้ายแอปพลิเคชันของเราไปยัง. Net

มักจะผิดพลาด วิธีปฏิบัติที่ดีที่สุดคือไม่ลอง "ค่อยๆ"

แม้ว่ามันจะเป็นภาษาใหม่สำหรับนักพัฒนาส่วนใหญ่ที่นี่ แต่เรามีความรู้เชิงลึกเกี่ยวกับ VBA และโครงการขนาดเล็กหลายสิบดำเนินการใน VB6

ไม่ใช่พื้นฐานที่ดีสำหรับการตัดสินใจ หากคุณต้องการเรียนรู้ภาษาใหม่อย่าเรียนรู้ VB เรียนรู้ C # หรือสิ่งที่ดียิ่งขึ้นเช่น Java

"ภาษาใหม่สำหรับนักพัฒนาส่วนใหญ่ที่นี่เรามีความรู้อย่างลึกซึ้งเกี่ยวกับ VBA" เป็นวลีรหัสทั่วไปสำหรับ "เรามี VBA Guru ที่เราไม่ต้องการทำให้ระคายเคือง" นั่นคือสิ่งที่อาจไม่ดีเช่นกัน

สิ่งที่เรากำลังมองหาคือแนวทางปฏิบัติที่ดีที่สุดสำหรับการค่อยๆเคลื่อน GUI ที่กว้างขวาง

แนวปฏิบัติที่ดีที่สุดไม่เกี่ยวข้องกับ "ค่อยเป็นค่อยไป" พวกเขาเกี่ยวข้องกับ "ทิ้งทั้งหมด"

การโยกย้ายอย่างค่อยเป็นค่อยไปที่ฉันเคยเห็นได้พังเพราะมันยากเหลือเกิน

คุณทำได้ดีกว่านี้

1. รักษาทรัพย์สินที่มีค่ามากที่สุด ข้อมูล. ย้ายข้อมูลทั้งหมดไปยัง SQL Server ทั้งหมดของมัน. เขียนซ้ำ MS-Access ทั้งหมดเพื่อใช้การเชื่อมต่อ ODBC ไปยัง SQL Server ตอนนี้

2. ดำเนินการกับทุกคนที่สร้างตารางชั่วคราวหรือข้อมูลหรือสิ่งใดก็ตามใน MS-Access ข้อมูลทั้งหมดจะต้องอยู่ในฐานข้อมูลนอก MS-Access ข้อมูลใน MS-Access คือสิ่งที่ทำให้เกิดปัญหาดังนั้นหยุดเดี๋ยวนี้และให้แน่ใจว่าทุกคนเห็นด้วย หากพวกเขาไม่เห็นด้วยให้หางานใหม่ที่ไม่เกี่ยวข้องกับการแฮ็คใน MS-Access ในขณะที่คุณพยายามกำจัด MS-Access

3. ค้นหากรอบการรายงานที่จะสร้างรายงานโดยอัตโนมัติใกล้กับสิ่งที่คุณมีตอนนี้ ไม่มีการเขียนโปรแกรม เพียงแค่ให้ตารางหรือมุมมองและปัง! มันจบแล้ว.

4. ระบุ 500 รายงานทั้งหมด แบ่งพาร์ติชันออกเป็นรายงานที่สร้างขึ้นได้ง่ายด้วยเครื่องมือและรายงานที่ยากขึ้น จัดลำดับความสำคัญของฮาร์ดลงใน "ต้องมี", "ควรมี", สามารถมีได้ "และ" จะไม่ทำต่อไปในภายหลัง "แทนที่รายงานอัตโนมัติและรายงานต้องมีเครื่องมือรายงานนี้อย่างสมบูรณ์นอก MS-Access

   ประสบการณ์ของฉันคือมุมมองฐานข้อมูลมักถูกนำมาใช้ซ้ำในรายงานประมาณ 20 ครั้ง จากนั้นฉันเดาว่าคุณมี 25 มุมมองที่เกี่ยวข้องซึ่งได้รับ 500 รายงาน เครื่องมือใด ๆ ที่สามารถสร้างการรายงานได้โดยอัตโนมัติควรจัดการกับการรายงานส่วนใหญ่ของคุณจากชุดมุมมอง SQL ที่จัดทำขึ้นอย่างดี รายงานบางฉบับจะซับซ้อนหรือยากเกินไปสำหรับเครื่องมืออัตโนมัติ

5. ค้นหากรอบการพัฒนาที่สร้างธุรกรรม CRUD โดยอัตโนมัติ

6. แบ่งพาร์ติชันแบบฟอร์ม 200 ของคุณออกเป็นแบบฟอร์ม CRUD (ซึ่งสามารถสร้างโดยอัตโนมัติ) และแบบฟอร์มที่ไม่ใช่ CRUD ในบรรดา non-CRUD ให้ความสำคัญกับการใช้กฎ MoSCoW (ต้อง, ควร, ทำได้, ไม่ได้)

   บ่อยครั้งที่ 60-80% ของแบบฟอร์มแอปพลิเคชันเป็นแบบฟอร์ม CRUD ที่ง่ายและอัตโนมัติ 20-40% นั้นซับซ้อนและต้องการโปรแกรมที่มีทักษะมากกว่า จากนี้คุณมี 120 ถึง 160 CRUD แบบฟอร์มที่คุณไม่จำเป็นต้องเขียนใหม่เพียงแค่ทำให้เป็นอัตโนมัติ คุณมีธุรกรรมที่ซับซ้อนอย่างจริงจัง 40-80 รายการ

7. สร้างแบบฟอร์ม CRUD และแบบฟอร์ม CRUD ที่ต้องมี

8. ประเมินช่องว่าง จัดลำดับความสำคัญใหม่และเริ่มทำงานในส่วนที่สำคัญที่สุดของรายการ "ควรมี"

มันอาจจะง่ายที่สุดในการยกเลิก Access ทั้งหมด หลีกเลี่ยงการค่อยเป็นค่อยไป

คุณจะใช้จ่ายเงินทั้งหมดในที่สุด

คุณอาจใช้งบประมาณและใช้เงินทันที

พยายามที่จะทำเช่นนี้ค่อยๆจริงอาจจะมากขึ้นราคาแพงเพราะความซับซ้อนของการพยายามที่จะอยู่ร่วมกันในการจัดการ