Đánh giá chủ đề:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[Hỏi] Xin kinh nghiệm thiết kế access dùng trong mạng Lan
#1
Chào anh chị em, để chạy được access trong môi trường mạng Lan thì cần phải xử lí tốt việc xung đột dữ liệu khi thêm xóa sửa. Vậy xin mọi người có thể chia sẽ kinh nghiệm khi thiết kế form có thêm dữ liệu, xóa dữ liệu hoặc sửa dữ liệu.
- Thêm dữ liệu: Tránh bị trùng khóa chính khi thêm mới.
- Sửa dữ liệu: Nhiều user cùng sửa trên 1 record.
- Xóa dữ liệu: user A xóa dữ liệu trong khi user B đang focus để sửa dữ liệu.
Vấn đề nhức nhối nữa là độ trể của access dùng trong mạng lan. Ví dụ: Khi thêm mới dữ liệu thiết kế nút lưu theo cấu trúc lấy mã khóa chính + 1 (dmax(mahd) + 1). Nhưng vì có độ trể nên nếu 2 user cùng click vào nút lưu đồng thời thì cấu trúc dmax + 1 lỗi ngay, để không lỗi thì user A ấn lưu, sau đó user B phải đợi khoảng vài giây thì ấn lưu mới lấy mã user A vừa lưu + 1.

Vậy anh chị em có thể chia sẽ kinh nghiệm để giải quyết tốt những vấn đề trên. Hiện tại mình rất tâm huyết đối với access, nhưng khi chào mời phần mềm viết bằng access thì nhiều người tỏ vẻ ái ngại, chê nó yếu thua nhiều phần mềm lập trình bằng ngôn ngữ khác. Rất là buồn.
Chữ ký của mrsiro Xin chào, mình là mrsiro, Tham gia http://thuthuataccess.com/forum từ ngày 05-12 -14.
Reply
Những người đã cảm ơn
#2
Tránh xung đột theo mình bạn nên cập nhật dữ liệu trước hiển thị sau có nghĩa là bạn nên sử dụng các câu lệnh sql cập nhật vào bản dữ liệu trước
Chữ ký của tt1212 -  Phần mềm quản lý bán hàng - nhà phân phối -phòng khám https://butso.net/
-  Hỗ trợ những khó khăn vướng mắc cần chia sẻ giải đáp: 08-665.977.68
-   Email. Tantriviet.vnn@gmail.com
Reply
Những người đã cảm ơn
#3
(02-02-18, 11:52 PM)mrsiro Đã viết: ...
- Thêm dữ liệu: Tránh bị trùng khóa chính khi thêm mới.
- Sửa dữ liệu: Nhiều user cùng sửa trên 1 record.
- Xóa dữ liệu: user A xóa dữ liệu trong khi user B đang focus để sửa dữ liệu.
Vấn đề nhức nhối nữa là độ trể của access dùng trong mạng lan. Ví dụ: Khi thêm mới dữ liệu thiết kế nút lưu theo cấu trúc lấy mã khóa chính + 1 (dmax(mahd) + 1). Nhưng vì có độ trể nên nếu 2 user cùng click vào nút lưu đồng thời thì cấu trúc dmax + 1 lỗi ngay, để không lỗi thì user A ấn lưu, sau đó user B phải đợi khoảng vài giây thì ấn lưu mới lấy mã user A vừa lưu + 1.
...

1. Để giải quyết vấn "Thêm mới" dữ liệu bạn xem link bài này: http://thuthuataccess.com/forum/post-357...l#pid35777
 -> Nó giải quyết việc tránh bị trùng Primary Key khi nhiều người cùng tạo mới và lưu dữ liệu.
2. Sửa/Xóa dữ liệu: bạn dùng thuộc tính Record Lock trong Form: Edited record. Khi có ai đang sửa dữ liệu thì Record đó sẽ bị khóa.
Chữ ký của ongke0711 If you BORN poor, it's not your mistake. But if you DIE poor, It's your mistake!
ღღღღღTài sản của ongke0711 (View All Items) ღღღღღ
Reply
Những người đã cảm ơn mrsiro
#4
(05-02-18, 06:40 AM)ongke0711 Đã viết: 1. Để giải quyết vấn "Thêm mới" dữ liệu bạn xem link bài này: http://thuthuataccess.com/forum/post-357...l#pid35777
 -> Nó giải quyết việc tránh bị trùng Primary Key khi nhiều người cùng tạo mới và lưu dữ liệu.
2. Sửa/Xóa dữ liệu: bạn dùng thuộc tính Record Lock trong Form: Edited record. Khi có ai đang sửa dữ liệu thì Record đó sẽ bị khóa.

Cám ơn bạn, vấn đề đặt ra là độ trể của việc lưu dữ liệu trong mạng lan đó bạn. Ví dụ: 1 unbound form để thêm dữ liệu, với button lưu, cấu trúc lệnh là khi ấn nút lưu thì kiểm tra mahd trên table, lấy dmax + 1. Thì khi chạy trong mạng lan, khi user A ấn lưu thì check dmax là 10 chẳng hạn thì kết quả lưu vào table sẽ là 11, nhưng nếu user B ấn lưu cùng lúc ở 1 máy khác thì cả 2 đều là 11 (lỗi), nếu user B chờ khoảng 1-2s (thời gian khá đáng kể) thì ấn lưu mới lấy 11 + 1 (dmax của user A vừa lưu).

Ví dụ khác: Check user đã đăng nhập hay chưa, có form login và table Online, khi user A đăng nhập thì thêm vào bảng Online giá trị của username và trạng thái online, mục đích của việc này là nếu trên 1 máy khác mà có người đăng nhập tiếp user A này sẽ check trong bảng Online nếu có tồn tại giá trị thì ra msbox "đã đăng nhập". Nhưng do có độ trể của việc lưu vào bảng Online nên nếu 2 người dùng ở 2 máy cùng ấn login đồng thời với user A thì bẩy lỗi "đã đăng nhập" vô tác dụng, người sau phải ấn đăng nhập chậm hơn 1-2s thì bẫy lỗi mới có tác dụng (vì độ trể nên lúc này dữ liệu mới được thêm vào table Online).

Trước đây mình có chơi game Muonline thì gặp phải vấn đề này, 2 người 2 máy cùng nhập 1 user rồi ấn login gần như đồng thời thì đăng nhập vào được => h@ck game. Nhưng các phiên bản sau khi này thì giải quyết được vấn đề, giảm độ trể của việc check (gần như là không nhận ra), mặc dù là chạy online, máy mình kết nối với máy họ trên internet mà việc check user online gần như tuyệt đối.
Chữ ký của mrsiro Xin chào, mình là mrsiro, Tham gia http://thuthuataccess.com/forum từ ngày 05-12 -14.
Reply
Những người đã cảm ơn
#5
(05-02-18, 07:11 PM)mrsiro Đã viết: Cám ơn bạn, vấn đề đặt ra là độ trể của việc lưu dữ liệu trong mạng lan đó bạn. Ví dụ: 1 unbound form để thêm dữ liệu, với button lưu, cấu trúc lệnh là khi ấn nút lưu thì kiểm tra mahd trên table, lấy dmax + 1. Thì khi chạy trong mạng lan, khi user A ấn lưu thì check dmax là 10 chẳng hạn thì kết quả lưu vào table sẽ là 11, nhưng nếu user B ấn lưu cùng lúc ở 1 máy khác thì cả 2 đều là 11 (lỗi), nếu user B chờ khoảng 1-2s (thời gian khá đáng kể) thì ấn lưu mới lấy 11 + 1 (dmax của user A vừa lưu).

Bạn ngâm cứu kỹ cái link tôi gửi đi, nó y chang trường hợp của bạn và nó giải quyết cái vụ mà bạn kêu "độ trễ" đó. Nó thực ra là vấn đề nhập liệu trong môi trường đa người dùng. Cái ví dụ trong link là thay vì lấy (Dmax +1) thì nó là tạo 1 cái Primary Key tự động theo cấu trúc khác (ngày tháng, mã BN) nhưng cũng gặp một vấn đề chung là bị trùng Primary Key khi 2 người cùng nhập liệu mới cùng lưu một lúc.
Thực ra trong thực tế rất khó nào có sự trùng hợp cả 2, 3, 4... máy cùng lưu dư liệu ở cùng 1 thời điểm chính xác bằng phần ngàn giây (milisecond) mà phải có máy nào truy cập trước lưu trước, máy nào sau thì lưu sau. Do đó giải pháp trong đó của tôi là khi 1 table cần lưu nhận được tín hiệu lưu của máy nào trước sẽ lập tức khóa table đó luôn để máy sau không truy cập được để lấy số thứ tự Dmax+1 và tất nhiên Access sẽ báo lỗi ngay. Tôi sẽ bẫy lỗi này và để người dùng thứ 2 chờ trong vài phần ngàn giây để table đang bị khóa được giải phóng và máy truy cập để lấy số thứ tự mới nhất và lưu kế tiếp. Việc chờ vài phần ngàn giây thì không ảnh hưởng gì đáng kể đến người dùng.
Việc này cũng áp dụng tương tự cho việc quản lý Login. Máy nào gửi tín hiệu truy cập trước sẽ Lock user (vd: cập nhật field [Login status]= true) đó ngay để máy sau thấy dấu hiệu "khóa" sẽ báo lỗi và không cho truy cập.
Chữ ký của ongke0711 If you BORN poor, it's not your mistake. But if you DIE poor, It's your mistake!
ღღღღღTài sản của ongke0711 (View All Items) ღღღღღ
Reply
Những người đã cảm ơn
#6
(05-02-18, 09:13 PM)ongke0711 Đã viết: Bạn ngâm cứu kỹ cái link tôi gửi đi, nó y chang trường hợp của bạn và nó giải quyết cái vụ mà bạn kêu "độ trễ" đó. Nó thực ra là vấn đề nhập liệu trong môi trường đa người dùng. Cái ví dụ trong link là thay vì lấy (Dmax +1) thì nó là tạo 1 cái Primary Key tự động theo cấu trúc khác (ngày tháng, mã BN) nhưng cũng gặp một vấn đề chung là bị trùng Primary Key khi 2 người cùng nhập liệu mới cùng lưu một lúc.
Thực ra trong thực tế rất khó nào có sự trùng hợp cả 2, 3, 4... máy cùng lưu dư liệu ở cùng 1 thời điểm chính xác bằng phần ngàn giây (milisecond) mà phải có máy nào truy cập trước lưu trước, máy nào sau thì lưu sau. Do đó giải pháp trong đó của tôi là khi 1 table cần lưu nhận được tín hiệu lưu của máy nào trước sẽ lập tức khóa table đó luôn để máy sau không truy cập được để lấy số thứ tự Dmax+1 và tất nhiên Access sẽ báo lỗi ngay. Tôi sẽ bẫy lỗi này và để người dùng thứ 2 chờ trong vài phần ngàn giây để table đang bị khóa được giải phóng và máy truy cập để lấy số thứ tự mới nhất và lưu kế tiếp. Việc chờ vài phần ngàn giây thì không ảnh hưởng gì đáng kể đến người dùng.
Việc này cũng áp dụng tương tự cho việc quản lý Login. Máy nào gửi tín hiệu truy cập trước sẽ Lock user (vd: cập nhật field [Login status]= true) đó ngay để máy sau thấy dấu hiệu "khóa" sẽ báo lỗi và không cho truy cập.
Độ trể tính bằng milisecond thì mình nghĩ không cần phải bẩy lỗi, tại vì như bạn cũng đã nói là hầu như khó xảy ra. Nhưng độ trể mình đề cập là có thể nhận biết đó bạn (1-2s). Ứng dụng của mình thiết kế như thế này: Khi người dùng 1 ấn chỉnh sửa trên 1 record, thì chạy sql insert vào bảng lock mã của record đang được chỉnh sửa đó, khi người dùng khác ấn chính sửa trên chính record đó thì lập tức check trong bảng lock nếu tồn tại mã này ra thông báo đang được chỉnh sửa, khi người dùng 1 ấn lưu thì thực hiện delete mã này trong bảng lock, lúc đó người dùng khác mới ấn button chỉnh sửa được. Nhưng do độ trể 1-2s nên nếu 2 người dùng ấn nút chỉnh sửa cách nhau khoảng 0,5 - 1s thì bẩy lỗi vô tác dụng. Tương tự khi người dùng 1 ấn lưu thì cũng khoảng 1-2s thì mã record kia mới dc xóa trong bảng lock, nếu người dùng 2 ấn nút sửa khoảng 0.5 - 1s sau khi người dùng 1 ấn lưu thì lại bị bẫy lỗi "đang được chỉnh sửa" trong khi người dùng 1 đã ấn lưu rồi, nhưng do độ trể nên khoảng 1-2s sau người dùng 2 ấn sửa mới không hiện bẩy lỗi. Không biết là bạn đã gặp vấn đề này chưa. Nếu như độ trể bạn đề cập là milisecond thì thật sự quá tốt, bởi vì đó là khoảng thời gian là người dùng khó có thể nhận ra.
Chữ ký của mrsiro Xin chào, mình là mrsiro, Tham gia http://thuthuataccess.com/forum từ ngày 05-12 -14.
Reply
Những người đã cảm ơn
#7
Bạn ngâm cứu bài viết tôi đi rồi mới biết.
- Tôi đã nói nó bẫy lỗi được độ trễ đến milisecond rồi thì 1 -2 s của bạn thì cần gì phải lăn tăn nữa.
- Tôi nói bẫy lỗi dù là milisecond vì đây là lỗi hệ thống, nó sẽ tự động báo khi bị trùng dữ liệu, nếu không bẫy thì nó hiện thông báo một đống tiếng Anh thì người dùng biết xử lý như thế nào?
- Cái thủ thuật trong link trên của tôi là dùng cho việc nhiều người thêm mới dữ liệu và Lưu không bị trùng mã PK.
- Vụ lock record khi chỉnh sửa: không biết bạn dùng Bound hay Unbound Form? Nếu dùng Bound Form thì thiết lập thuộc tính Record Lock: Edited Record là cũng giải quyết việc Lock record rồi không cần dùng bảng Lock và cũng không cần thực hiện thêm lệnh delete Lock. Khi đó người thứ 2 không chỉnh sửa được, nếu cố chỉnh sửa sẽ nhận báo lỗi của hệ thống, bạn cũng cần bẫy lỗi hệ thống này. Khi người dùng đã lưu dữ liệu lúc đó hệ thống tự động xóa lock. Từ đó thấy rằng việc chỉnh sửa của nghười thứ 2 đã không thực hiện được rồi thì không cần lo gì đến nút Lưu.
- Một cách khác là dùng thư viện DAO: rs.EditMode. Bạn sẽ check nếu rs.EditMode <> dbEditInProgress thì cho chỉnh sửa nếu không thì Stop, không cho chỉnh sửa.
Chữ ký của ongke0711 If you BORN poor, it's not your mistake. But if you DIE poor, It's your mistake!
ღღღღღTài sản của ongke0711 (View All Items) ღღღღღ
Reply
Những người đã cảm ơn
#8
Ban đầu mình dùng bound form và sử dụng lock edit, nhưng quá trình sử dụng phát sinh vấn đề người dùng 1 ấn sửa không ấn lưu, treo máy rồi đi về, record đó mãi bị lock dẫn đến các người dùng khác không thao tác được gì. 
Vì vậy mình chuyển sang dùng unbound và sử dụng cách thêm mã vào bảng lock như đã nói ở trên (dự trù nếu gặp trường hơp như trên thì mình chỉ việc vào bảng lock xóa cái mã record này là người dùng khác có thể thao tác được trên record này).
Khi đó lại gặp vấn đề độ trể như mình đề cập, ấn nút sửa đồng thời hoặc cách 0.5 - 1s thì bẫy lỗi không tác dụng => 2 người dùng cùng sửa trên 1 record => xung đột.
Chữ ký của mrsiro Xin chào, mình là mrsiro, Tham gia http://thuthuataccess.com/forum từ ngày 05-12 -14.
Reply
Những người đã cảm ơn
#9
Bây giờ khoan nói vụ bẫy lỗi nhé. 
Tôi nghĩ giải pháp để ngăn ngừa User khóa record ở chế độ chỉnh sửa trong thời gian dài như bạn đang làm không phải là cách hiệu quả và thực tế. Bạn thử nghĩ trong thực tế nếu ứng dụng có nhiều người dùng, lỡ có User nào vào chế độ edit record rồi để đó đi chơi, người khác vào cập nhật không được lại réo Admin mở Lock record để họ sửa được! Bạn giải quyết được bao nhiều lần, chẳng lẻ phải ngồi đó theo dõi ứng dụng để có gì còn vô Table mở Lock cho người ta hay gọi điện cho User đó "Ê mày, đi đâu đó? vào lưu dữ liệu giùm tao cái để người khác còn nhập liệu".... 007 . Thú thật tôi chưa thấy ứng dụng nào dùng cách này.
Để đơn giản thì bạn nên thiết lập qui định cho ứng dụng của bạn. Người dùng phải đọc hướng dẫn sử dụng trước khi dùng.
Ví dụ:
1. Nếu là Bound Form:
- Qui định khi mở chế độ edit quá 30 phút 1 record thì tự động "Đóng nó lại và Không lưu" dữ liệu. Vì người dùng có bấm Lưu đâu mà mình phải lưu cho họ. Sau này họ có trách thì nói do họ không lưu thì đành mất thôi. Excel, Word cũng vậy mà. Nếu bạn thiết lập tự động "Đóng và Lưu", có gì họ nói bạn họ có chưa muốn Lưu mà ứng dụng tài lanh lưu làm gì.
- Tất nhiên cũng nên hiện thông quá quá thời gian cập nhật dữ liệu, sẽ đóng form để họ biết.
2. Unbound Form:
- Theo tôi thì khi chỉnh sửa, bạn chỉ cần load dữ liệu form về rồi ngắt kết nối.
- Khi bấm nút Lưu, lúc đó mới kết nối Table để lưu. Khi đó sẽ có trường hợp nhiều User cũng chỉnh sửa 1 record nhưng cũng không sao, cứ xếp hàng, User nào bấm nút Lưu trước thì lưu rồi đến user kế tiếp lưu. Nếu có trùng hợp cùng bấm lưu 1 lúc thì sẽ dùng cách câu giờ như demo của tôi, ai tới sau, thấy dữ liệu đang ở trang thái lưu thì chờ chút (milisecond) rồi sẽ lưu kế tiếp.
- Thường thì table nhập liệu có thêm các cột lưu thông tin [người nhập liệu], [thời gian nhập liệu], [người sửa], [thời gian sửa]. Khi có có phát sinh gì thì cứ xem file log ai là người sửa sau cùng (được lưu sau cùng) để truy cứu trách nhiệm.
Chữ ký của ongke0711 If you BORN poor, it's not your mistake. But if you DIE poor, It's your mistake!
ღღღღღTài sản của ongke0711 (View All Items) ღღღღღ
Reply
Những người đã cảm ơn


Có thể liên quan đến chủ đề
Chủ đề: Tác giả Trả lời: Xem: Bài mới nhất
  [Help] chỉ dùm bôi đen text trong form textbox bo bin 5 195 17-11-18, 06:59 PM
Bài mới nhất: bo bin
  Hướng Dẫn Tổng hợp thông tin chi tiết các phiên bản Access maidinhdan 0 161 30-10-18, 12:37 AM
Bài mới nhất: maidinhdan
  [Hỏi] Nên dùng bảng tạm (TempTable) ngay trong file FE hay file .mdb tạm (TempTable.mdb) ongke0711 5 384 29-08-18, 09:18 PM
Bài mới nhất: ongke0711
  Hướng Dẫn Hỏi cách tạo code phục hồi dữ liệu trong table sau khi backup doandinhtam 31 1,467 29-08-18, 03:54 PM
Bài mới nhất: doandinhtam
  Hỏi về bắt lỗi trong accc thanlaem 21 4,427 07-08-18, 11:02 PM
Bài mới nhất: vdttuan

Chuyển nhanh:


User(s) browsing this thread: 1 Guest(s)
Diễn Đàn Thơ Văn Thi Ẩm Lâu|Nhà Hàng Sông Thơ| PMA Nha Trang| Gỗ Acrylic Không Đường Line