Kính thưa:
- Ban quản trị diễn đàn Thủ thuật Access;
- Các anh chị là "Thành viên đẳng cấp";
- Cùng các bạn là thành viên có niền sở thích về Access.

Ngày hôm nay, ở nơi đây, mình không được vinh dự hiện diện với tư cách là Ban quản trị diễn đàn, cũng như không được nằm trong số các thành viên có niềm đam mê về Access.

Kính thưa các bạn. Qua hơn ba năm ngồi quan sát, từ một người không biết Access là gì, cũng chưa từng học qua Access bởi trường lớp nào. Nhưng được đọc những bài viết từ các Anh/chị có kinh nghiệm kỹ năng viết lập trình về Access, những bài demo sinh động, dễ hiểu và nhất là từ những câu hỏi của các bạn. Mình tích lũy được rất nhiều kiến thức về Access để ngày hôm nay mình có thể viết những ứng dụng mà mình thích.

Kinh thưa các bạn, để tỏ lòng kính trọng, gửi lời cảm ơn chân thành đến Ban quản trị diễn đàn này, nhất là các anh Noname, Xuân Thanh, Hạ Vàng, Mattroinguquen, HaQuocQuan, Quan_PC, cpuloi.... mình không biết nói bao nhiêu lời cảm ơn đã giúp mình có nhiều kiến thức như thế.

Và để tiếp tục phát huy những kỳ vọng mà các anh mang lại cho Diễn đàn nay, mình cũng noi theo các Anh để hôm nay, ngày mai giúp đỡ các bạn khác có niềm đam mê về Access.

Đến đây mình xin bắt đầu chia sẽ một ít về kinh nghiệm về xây dựng một ứng dụng hoàn hảo cho bản thân mình nhé các bạn.

Các bạn thân mến! thực ra để viết một ứng dụng ưng ý và thật hoàn hỏa không phải bắt nguồn từ việc ta biết lập trình code giỏi là được đâu. Mà nó bắt nguồn từ việc tạo ra nguồn data ban đầu ( chính xác là table ) các bạn ạ và tạo các muốn quan hệ: khóa chính, khóa phụ đấy.

- Để viết ứng dụng ban đầu ta phải có mẫu; tiếp theo ta tạo table.
- Cuối cùng, ta đặt giả thuyết và xử lý các biến cố trong tương lai.

Chỉ 2 điều trên ta liệt kê ra hết chắc chắn ứng dụng của ta sẽ rất ấn tượng. Còn việc viết code như thế nào, ta từ từ tìm hiểu sau cũng không muộn.

* Ghi chú: nhưng để thực hiện 2 điều trên thì khó hơn là học ngôn ngữ lập trình nửa, Tại sao tôi lại nói vậy. Cho dù bạn biết đến 100 ngôn ngữ lập trình, giỏi đến cỡ bác Bill mà bạn không am hiểu về cách thức vận hành công việc của công ty, của cửa hàng hay của cơ quan...đó thì khó mà cho ra một đứa con hoàn hảo đến hơn 50%. Cho nên giống như bạn thuê một lập trình viên giỏi để viết ứng dụng nhưng sự truyền đạt của bạn để viết ứng đến lập trình viên ấy không am hiểu hết nhất là các từ chuyên ngành...đến lĩnh vực bạn cần viết.


Vì thế, đối với mình không khi nào mình vội viết query, form hay report, modules. Mà mình thường ngấm nghía table rất kỹ nhất là các khóa quan hệ của chúng, từng cột mang kiểu dữ liệu, độ rộng ra sau. Rồi việc hạn chế đến mức thấp nhất việc tạo ra nhiều tabel, nhiều khóa chính. và vừa làm mình vừa quan sát ở trang tạo quan hệ các khóa, luôn tưởng tượng mình đang nhập liệu trên từng table, để có thể ngộ ra những biến cố sau đó ghi lại từng chút một. Cuối cùng thường mất 2-3 tháng mình mới làm xong table của mình dù chương trình đó đơn giản...

Mình chỉ nói về table nên xin phép Noname cho mình post tại đây.
Xin được phép nói tới đây!
Ngày mai tiếp tục....

Cám ơn bạn maidinhdan đã chia sẻ. Đúng như bạn đã chia sẻ, người lập trình phải hiểu rõ công việc người sử dụng đang làm thì mới làm phần mềm thành công được. Đó là lý do tại sao không có bất cứ phần mềm ứng dụng quản lý nào phù hợp cho tất cả mọi người được, mà đó chỉ là những ứng dụng tham khảo để tự xây dựng ứng dụng cho riêng mình

OK bạn. Mình cũng xin mạn phép nói về kinh nghiệm của mình. Qua đây mình cũng xin nói qua một chút lý do mình đến với môn lập trình này. Hồi PTTH mình học ban toán, lý. Vào sư phạm mình học sư phạm Văn. Ra trường dạy tin học. Giờ nghĩ dạy làm kế toán. Cuộc đời mình kỳ cục vậy đó (hình như cuộc đời của những thằng tốt nghiệp phổ thông lúc giao thời giữa thập kỷ 70-80 của bọn mình đa số đều kỳ kỳ như thế). Cái hồi người ta dạy bằng B là Pascal. Thì chỗ của mình dạy bảo mình nghiên cứu access 2.0 cho nó phong phú bộ môn. Nhớ lúc ban đầu mà mình mắc cở. Ai đời dạy access mà chỉ biết sử dụng công thức như excel. còn code cứ Wizard mà phang. Học viên có hỏi thì cứ "để về nghiên cứu lại". Cũng may ngày xưa thi bằng B chỉ cần tạo bảng, viết một cái select đơn giản rồi xử lý form và report bằng wizard là xong vả lại học viên chỉ cần có cái bằng đóng dấu đo đỏ để đi làm chứ mấy ai bắt lập trình. Lúc đó thấy mấy thằng bạn có công ty viết thử cho nó mấy cái ứng dụng tồn kho đã cho không còn năn nỉ mà nó chẳng thèm xài. Thời đó kế toán còn mở bảng excel, tạo xong cái bảng gõ mấy chữ rồi lấy máy tính tay ra tính xong nhập số vào .
Mãi sau này khi mình đến với nghề kế toán. Mình cũng vẫn vơ với các phần mềm cr@ck. Rồi mài mò viết visual basic. Chính ông tổng cục thuế với thỏi quen thay đổi biểu mẫu xoành xoạch đã đưa mình trở về với access. Cuối cùng mình phát hiện phần mềm access dễ bán nhất.
Đối với mình Access có mấy cái hay là cơ động dễ điểu chỉnh, sữa chữa nhưng chiếm dụng tài nguyên máy rất cao do khi chạy tập tin bung ra rất lớn. Vì vậy Trước khi viết phải hiểu rõ yêu cầu người sử dụng qua đó khi phân tích tinh chỉnh tối đa số lượng table, số lượng quan hệ. Tinh chỉnh tối đa số lượng table không có nghĩa là thiết kế càng ít table càng tốt mà là gom những table đồng dạng lại thành 1 và chuyển những field ít sử dụng ra subtable. Trong query chấp nhận tạo 1 query phức tạp thay vì tạo nhiều query chồng chất. Nếu trường hợp buột phải xử lý bằng những query chồng chất chuyển nó qua khi xử lý ra report chứ không xử lý khi nhập liệu ở form (người xử dụng chấp nhận thời gian chờ đợi lâu khi gọi report chứ không chấp nhận đợi lâu khi nhập liệu). Khi xử lý form nên xử dụng từ khóa gọi đối tượng với dấu (.) chứ không sử dụng với dấu ([]![]) (ví dụ tên_objet.value thay vì [tên_form]![tên_objet] nếu cần tham chiếu nhiếu tầng thì cứ Form_ABC.DEF.Value. Với fom nhập liệu sử dụng hàm dlookup để gọi giá trị các trường liên kết thay vì đeo các subtable liên kết vào recordsource. Trừ trường hợp bất khả kháng nên nhập dữ liệu thẳng vào các recordsource của table không sử dụng các phương thức đối tượng truy cập dữ liệu - Data access objecd dao. (kiểu dim ...as data base, dim...as recordset rồi edit, addnew... ). Cũng như thế thay bằng các SQL appelle, update cho DAO...Theo kinh nghiệm của tôi xử lý điều này cải thiện tốc độ chạy code đáng kể. Văn bản pháp quy hiện nay cũng buộc sử dụng bằng unicode vì vậy phần mềm cũng nên sử dụng font unicode để tránh việc chuyển mã font cho người sử dụng. Nói chung là càng gọn thì càng nhanh mà càng nhanh thì người sử dụng càng khoái. Đôi lời tâm sự. Nếu có gì sai sót mong các bạn thứ lỗi.

(10-03-15, 11:58 PM)maidinhdan Đã viết: Kính thưa:
- Ban quản trị diễn đàn Thủ thuật Access;
- Các anh chị là "Thành viên đẳng cấp";
- Cùng các bạn là thành viên có niền sở thích về Access.

Ngày hôm nay, ở nơi đây, mình không được vinh dự hiện diện với tư cách là Ban quản trị diễn đàn, cũng như không được nằm trong số các thành viên có niềm đam mê về Access.

Kính thưa các bạn. Qua hơn ba năm ngồi quan sát, từ một người không biết Access là gì, cũng chưa từng học qua Access bởi trường lớp nào. Nhưng được đọc những bài viết từ các Anh/chị có kinh nghiệm kỹ năng viết lập trình về Access, những bài demo sinh động, dễ hiểu và nhất là từ những câu hỏi của các bạn. Mình tích lũy được rất nhiều kiến thức về Access để ngày hôm nay mình có thể viết những ứng dụng mà mình thích.

Kinh thưa các bạn, để tỏ lòng kính trọng, gửi lời cảm ơn chân thành đến Ban quản trị diễn đàn này, nhất là các anh Noname, Xuân Thanh, Hạ Vàng, Mattroinguquen, HaQuocQuan, Quan_PC, cpuloi.... mình không biết nói bao nhiêu lời cảm ơn đã giúp mình có nhiều kiến thức như thế.

Và để tiếp tục phát huy những kỳ vọng mà các anh mang lại cho Diễn đàn nay, mình cũng noi theo các Anh để hôm nay, ngày mai giúp đỡ các bạn khác có niềm đam mê về Access.

Đến đây mình xin bắt đầu chia sẽ một ít về kinh nghiệm về xây dựng một ứng dụng hoàn hảo cho bản thân mình nhé các bạn.

Các bạn thân mến! thực ra để viết một ứng dụng ưng ý và thật hoàn hỏa không phải bắt nguồn từ việc ta biết lập trình code giỏi là được đâu. Mà nó bắt nguồn từ việc tạo ra nguồn data ban đầu ( chính xác là table ) các bạn ạ và tạo các muốn quan hệ: khóa chính, khóa phụ đấy.

- Để viết ứng dụng ban đầu ta phải có mẫu; tiếp theo ta tạo table.
- Cuối cùng, ta đặt giả thuyết và xử lý các biến cố trong tương lai.

Chỉ 2 điều trên ta liệt kê ra hết chắc chắn ứng dụng của ta sẽ rất ấn tượng. Còn việc viết code như thế nào, ta từ từ tìm hiểu sau cũng không muộn.

* Ghi chú: nhưng để thực hiện 2 điều trên thì khó hơn là học ngôn ngữ lập trình nửa, Tại sao tôi lại nói vậy. Cho dù bạn biết đến 100 ngôn ngữ lập trình, giỏi đến cỡ bác Bill mà bạn không am hiểu về cách thức vận hành công việc của công ty, của cửa hàng hay của cơ quan...đó thì khó mà cho ra một đứa con hoàn hảo đến hơn 50%. Cho nên giống như bạn thuê một lập trình viên giỏi để viết ứng dụng nhưng sự truyền đạt của bạn để viết ứng đến lập trình viên ấy không am hiểu hết nhất là các từ chuyên ngành...đến lĩnh vực bạn cần viết.


Vì thế, đối với mình không khi nào mình vội viết query, form hay report, modules. Mà mình thường ngấm nghía table rất kỹ nhất là các khóa quan hệ của chúng, từng cột mang kiểu dữ liệu, độ rộng ra sau. Rồi việc hạn chế đến mức thấp nhất việc tạo ra nhiều tabel, nhiều khóa chính. và vừa làm mình vừa quan sát ở trang tạo quan hệ các khóa, luôn tưởng tượng mình đang nhập liệu trên từng table, để có thể ngộ ra những biến cố sau đó ghi lại từng chút một. Cuối cùng thường mất 2-3 tháng mình mới làm xong table của mình dù chương trình đó đơn giản...

Mình chỉ nói về table nên xin phép Noname cho mình post tại đây.
Xin được phép nói tới đây!
Ngày mai tiếp tục....

Chia sẽ của bạn rất bổ ích cho người mới tập access
Nếu bạn chia sẽ thêm về những cuốn sách hay mà bạn đã học qua cho anh em thì hay nữa

Tôi hoàn toàn thống nhất với quan điểm của chủ topic. Tư duy bao quát là rất quan trọng và cần thiết. Tôi mới tham gia diễn đàn, nhưng cũng sẽ cố gắng học hỏi để giao lưu cùng anh em. 
Chúc mọi người vui vẻ!