Không cho nhập trùng dữ liệu trên Access

Liên hệ QC

susu4892

Thành viên mới
Tham gia
29/6/09
Bài viết
11
Được thích
1
Hi cả nhà,
Mình dùng Access
Mình có 1 form nhập dữ liệu gồm các trường: CMND, Họ tên, SĐT...
Table đặt là "Checkin"
Form đặt tên là "form_Checkin"
Trường CMND là Primary key và dạng Number
Mình muốn khi nhập 1 CMND bất kỳ, nếu CMND đó đã được nhập trước đó rồi thì không cho nhập nữa mà sẽ hiển thị thông báo "CMND đã được đăng ký"
Các cao thủ giúp mình gấp với.
Thanks!

215259
 
- Trường CMND nên đổi sang Text mặc dù nó là số.
- Ở sự kiện AfterUpdate của cái textbox [txtCMND] bạn dùng hàm Dlookup (hoặc Dcount) để kiểm tra.
Vd:
Mã:
Private Sub txtCMND_AfterUpdate()
   Dim sCMND As String
   sCMND = Nz(DLookup("CMND","CheckIn","[CMND] ='" & Me.txtCMND & ''"),"")
   If Len(sCMND) > 0 Then
         Msgbox "Số CMND này đã có rồi"
         Me.txtCMND.SetFocus
         Exit Sub
   End If
End Sub
 
Mình đã đổi CMND trên table là short text rồi, đổi tên table cho dễ nhận là tbl_Checkin
Copy vào của bạn nhưng nó báo lỗi ntn
Mình gửi file but ko đính kèm đc :(
215260
 
Lần chỉnh sửa cuối:
Tôi gõ sai cái dấu nháy kép sau tham số me.txtCMND
Sửa lại:
..... & Me.txtCMND & "'")

Nháy kép - nháy đơn - nháy kép

Còn một cái nữa là bạn phải SetFocus sang 1 control khác rồi mới focus lại cái textbox CMND
Vd:
Me.txtNgay.SetFocus
Me.txtCMND.SetFocus
 
Khi thiết kế bảng, nếu ta đặt index 1 cột có với điều kiện là unique thì sẽ bảo đảm 100% không lặp. Lúc đó Access sẽ kiểm soát việc trùng lắp dữ liệu cho chúng ta kể cả khi nhập trực tiếp hay nhập từ form. Với form thì bẫy lỗi dựa trên thông báo của Access. Muốn biết mã lỗi thì cứ nhập 1 cái trùng rồi theo mã lỗi Access nhảy ra là giải quyết được liền.
 
Lần chỉnh sửa cuối:
Khi thiết kế bảng, nếu ta đặt index 1 cột có với điều kiện là unique thì sẽ bảo đảm 100% không lặp. Lúc đó Access sẽ kiểm soát việc trùng lắp dữ liệu cho chúng ta kể cả khi nhập trực tiếp hay nhập từ form. Với form thì bẫy lỗi dựa trên thông báo của Access. Muốn biết mã lỗi thì cứ nhập 1 cái trùng rồi theo mã lỗi Access nhảy ra là giải quyết được liền.

:) Chủ thớt đã có thiết lập Primary key cho trường đó rồi bạn.

Table đặt là "Checkin"
Form đặt tên là "form_Checkin"
Trường CMND là Primary key và dạng Number

Thông thường khi thiết kế bảng, muốn quản lý trùng lắp thì thiết lập Index nó: Yes (No Duplicate) và một số cột khác cũng với Index nhưng có thể trùng lắp: Yes (Duplicate OK). Mục đích việc lập chỉ mục ngoài việc ràng buộc dữ liệu còn là để tăng tốc tìm kiếm, sắp xếp.
Theo kinh nghiệm của tôi trong thực tế thiết kế ứng dụng, sẽ không trông chờ vào thông báo lỗi của hệ thống về việc nhập trùng lắp dữ liệu vì những lý do sau:
- Thông báo của hệ thống là thông báo tiếng Anh và người dùng không trong nghề cũng không hiểu nó là thông báo gì => gây bối rối cho ngườ dùng.
- Nếu bạn bẫy lỗi này (Error 3022) bằng tiếng Việt thì việc bẫy lỗi này sẽ có 2 trường hợp bẫy phải xét đến:
1. Nếu bạn thiết kế Form dạng Unbound thì bẫy lỗi sẽ chậm một nhịp do chỉ khi bấm "Lưu" thì hệ thống mới kiểm tra và báo lỗi phát sinh. Chậm nhip ở đây nghĩa là không báo lỗi sau khi gõ thông tin vào textbox.
2. Nếu thiết kế dạng Bound Form, thì bẫy lỗi ở sự kiện Form _Error(). Bẫy lỗi ở đây sẽ sẽ khắc phục việc chậm nhịp tức là ngay sau khi nhập liệu vào textbox, hệ thống sẽ báo lỗi ngay và bạn chỉ việc thay thông báo hệ thống bằng tiếng Việt. Cách này cũng hay dùng nhưng tóm lại cũng phải tốn code như cách dùng Dlookup. :) . Nhưng cách này sẽ tốn thêm code nếu như bảng có hơn 1 trường có "ràng buộc dữ liệu không trùng". Khi đó bạn phải thêm code để hiện thông báo chính xác trường nào đang bị trùng dữ liệu, không thể dùng một thông báo chung chung là "Dữ liệu bị trùng, cần nhập lại", khi đó người dùng không biết đã nhập trùng cái textbox nào, cái textbox vừa nhập hay textbox nào khác.
Quan điểm thiết kế ứng dụng của tôi là thiết kế sao cho một người dùng chỉ biết cơ bản nhất về vi tính cũng có thể xử lý nhập liệu an toàn, chính xác, nhanh và không bối rối. Do đó thường thì tôi hay bẫy lỗi ngay lúc nhập liệu để người dùng có thể điều chỉnh ngay lúc đó rồi mới đi tiếp.
 
Bẫy lỗi Form khi update (ở đây là Insert new record) qua tính cách bảo vệ primary key của CSDL là bài học căn bản, áp dụng lý tưởng.
Bẫy lỗi sớm, tức là ngay khi key được gõ vào, là cách làm thực tế. Bởi vì trên thực tế, thiết kế được một hệ thống lý tưởng rất khó. Lý do khách quan cũng có mà chủ quan cũng có (* và **).
* điển hình của khách quan là hệ thống legacy (thừa hưởng của ngừoi khác, của hệ thống khác)
** điển hình của chủ quan là người thiết kế kém khả năng.

@tác giả bài #6: [bảng có hơn 1 trường có "ràng buộc dữ liệu không trùng"]
Trường hợp này rất hiếm. Bởi vì nếu CSDL chuẩn bậc 2 trở lên thì nó không thể xảy ra.
Code giải quyết trường hợp rất hiếm là code ... trường hợp rất hiếm. Nếu bạn không thấy nó hiếm ở môi trường làm việc của bạn thì môi tường ấy là loại muôn nơi có một.
 
Tôi thấy tính năng Index giải quyết đúng nhu cầu mà cũng quá đơn giản nên tôi đề nghị thôi. Nếu có đánh index thì chúng ta vẫn có thể kiểm tra dữ liệu trước khi nạp mà?

Không phải tình cờ mà Access (hay các hệ CSDL khác) cung cấp những tinh năng như vậy cho dù điều đó có thể khiến Microsoft phải tốn thêm nhiều công sức, tiền của xây dựng phần mềm Access. Nếu suy nghĩ theo cách của ongke0711 thì tính năng đó chắc là cần được loại bỏ từ lâu rồi vì những tính năng khác cũng đủ để giải quyết.

Tôi giả sử nếu CSDL được nhiều lập trình viên hoặc người nhập liệu trực tiếp sử dụng và một số đó không hay nguyên tắc nhập dữ liệu dẫn đến nhập trùng thì thế nào? Nếu không được phát hiện, thì sai sót tích lũy theo thời gian sẽ vô cùng lớn và khi phát hiện ra thì việc phục hồi còn kinh khủng hơn rất nhiều (thậm chí là không có manh mối để khắc phục trừ khi làm lụi).
 
Lần chỉnh sửa cuối:
Không phải tình cờ mà Access (hay các hệ CSDL khác) cung cấp những tinh năng như vậy cho dù điều đó có thể khiến Microsoft phải tốn thêm nhiều công sức, tiền của xây dựng phần mềm Access. Nếu suy nghĩ theo cách của ongke0711 thì tính năng đó chắc là cần được loại bỏ từ lâu rồi vì những công cụ khác cũng đủ để giải quyết.

Tôi nghĩ bạn Vô Danh đã diễn dịch sai ý trong bài viết của tôi và ca bài của Sơn Tùng "Anh đi xa quá".
Tôi không hề nói bỏ qua việc lập chỉ mục (Index) khi thiết kế CSDL). Đã làm Access và SQL Server mà cái Index không biết thì làm sao thiết kế ứng dụng chạy hiệu quả đây bạn.
Bài viết của tôi chỉ đề cập việc bẫy lỗi nhập trùng như thế nào tốt nhất để thuận tiện cho người nhập liệu thôi nhé.
Tôi đã đề cập bẫy lỗi trong sự kiện Form_Error() tức là tận dụng cái báo lỗi của hệ thống khi nhập trùng trong cột là Primary Key và chuyển nó thành thông báo tiếng Việt để người dùng dễ hiểu.
Khi lập trình tôi phải bẫy lỗi nhập liệu (nhập trùng, nhập text vô trường số,Null value,...) trước khi hệ thống xử lý. Đến mức cuối, hệ thống tự báo lỗi sẽ là hàng rào cuối cùng để kiểm soát nhập liệu.
Lập trình là môn học chính xác thì không cần phải Tây mà Việt Nam cũng phải tuân thủ, chỉ có người lập trình làm biếng bẫy lỗi hoặc khả năng có giới hạn mới phát sinh chuyện thôi bạn.
 
:) Chủ thớt đã có thiết lập Primary key cho trường đó rồi bạn.



Thông thường khi thiết kế bảng, muốn quản lý trùng lắp thì thiết lập Index nó: Yes (No Duplicate) và một số cột khác cũng với Index nhưng có thể trùng lắp: Yes (Duplicate OK). Mục đích việc lập chỉ mục ngoài việc ràng buộc dữ liệu còn là để tăng tốc tìm kiếm, sắp xếp.
Theo kinh nghiệm của tôi trong thực tế thiết kế ứng dụng, sẽ không trông chờ vào thông báo lỗi của hệ thống về việc nhập trùng lắp dữ liệu vì những lý do sau:
- Thông báo của hệ thống là thông báo tiếng Anh và người dùng không trong nghề cũng không hiểu nó là thông báo gì => gây bối rối cho ngườ dùng.
- Nếu bạn bẫy lỗi này (Error 3022) bằng tiếng Việt thì việc bẫy lỗi này sẽ có 2 trường hợp bẫy phải xét đến:
1. Nếu bạn thiết kế Form dạng Unbound thì bẫy lỗi sẽ chậm một nhịp do chỉ khi bấm "Lưu" thì hệ thống mới kiểm tra và báo lỗi phát sinh. Chậm nhip ở đây nghĩa là không báo lỗi sau khi gõ thông tin vào textbox.
2. Nếu thiết kế dạng Bound Form, thì bẫy lỗi ở sự kiện Form _Error(). Bẫy lỗi ở đây sẽ sẽ khắc phục việc chậm nhịp tức là ngay sau khi nhập liệu vào textbox, hệ thống sẽ báo lỗi ngay và bạn chỉ việc thay thông báo hệ thống bằng tiếng Việt. Cách này cũng hay dùng nhưng tóm lại cũng phải tốn code như cách dùng Dlookup. :) . Nhưng cách này sẽ tốn thêm code nếu như bảng có hơn 1 trường có "ràng buộc dữ liệu không trùng". Khi đó bạn phải thêm code để hiện thông báo chính xác trường nào đang bị trùng dữ liệu, không thể dùng một thông báo chung chung là "Dữ liệu bị trùng, cần nhập lại", khi đó người dùng không biết đã nhập trùng cái textbox nào, cái textbox vừa nhập hay textbox nào khác.
Quan điểm thiết kế ứng dụng của tôi là thiết kế sao cho một người dùng chỉ biết cơ bản nhất về vi tính cũng có thể xử lý nhập liệu an toàn, chính xác, nhanh và không bối rối. Do đó thường thì tôi hay bẫy lỗi ngay lúc nhập liệu để người dùng có thể điều chỉnh ngay lúc đó rồi mới đi tiếp.
Những cái anh nói y chang những lý thuyết quá cơ bản mà cả lớp hơn 100 đứa học viên như tôi nghe cách đây 17 năm rồi. Nhưng khi thực hành chính tôi cũng không có cảm giác thích thú với cái cách phổ thông này lắm.

Bản thân Access vốn đã dùng tiếng Anh để giao tiếp với người dùng thì nó có "sờ píc inh lích" lỗi với người dùng cũng chả có gì là vấn đề cả. Chỉ là vấn đề khi người dùng chả chịu mở mang để hiểu nó nói gì.

Tôi tận dụng kiểm soát dữ liệu đầu vào của chính hệ CSDL vì nghĩ rằng nó áp dụng không chỉ cho phần mềm của tôi mà bất cứ những phần mềm nào khác cùng khai thác CSDL đó.

Tôi cũng nghĩ rằng tốc độ kiểm tra của chính hệ CSDL cũng sẽ nhanh hơn việc tôi viết SQL với mớ code kiểm tra.(không áp dụng cho TẤT CẢ những trường hợp khác)

Tôi bẫy lỗi sau đơn giản vì mã lỗi sẽ nằm trong một khối SELECT... CASE tất cả những lỗi mà tôi dự phòng.

Tôi thấy Bound chỉ lý tưởng ở mỗi khâu duyệt xem dữ liệu (đỡ phải viết code gán dữ liệu) chứ thật sự quá phiền toái ở chế độ thêm hay cập nhật nhất là khi con nháy nằm chết dí ở cái ô lỗi nào đó mà không tài nào chuyển qua được các ô nhập khác. Lẽ ra người dùng đã có thể tận dụng thời gian để fill các ô khác nếu không bị trói tay ở cái ô lỗi Bound vớ vẩn nào đó. Tôi đã từng viết code để chuyển đổi qua lại 2 chế độ Bound/UnBound nhưng nay thì chỉ còn đúng 1 chế độ UnBound (anh không nhắc chắc tôi cũng quên bố 2 khái niệm này .

Tóm lại anh theo lý thuyết chính thống khuôn mẫu rồi còn tôi thì từ xuất phát nhu cầu thực tế của bản thân với vốn liếng kiến thực hạn hẹp.
 
Bản thân Access vốn đã dùng tiếng Anh để giao tiếp với người dùng thì nó có "sờ píc inh lích" lỗi với người dùng cũng chả có gì là vấn đề cả. Chỉ là vấn đề khi người dùng chả chịu mở mang để hiểu nó nói gì.

:) Mình viết ứng dụng cho người ta mà bắt người ta phải biết tiếng Anh để đọc hiểu báo lỗi của ứng dụng thì làm sao lấy tiền họ được anh?

Tôi tận dụng kiểm soát dữ liệu đầu vào của chính hệ CSDL vì nghĩ rằng nó áp dụng không chỉ cho phần mềm của tôi mà bất cứ những phần mềm nào khác cùng khai thác CSDL đó.
Đúng là CSDL phải chuẩn hoá, ràng buộc chặt chẽ thì mới nói tới chuyện Form, code...

Tôi cũng nghĩ rằng tốc độ kiểm tra của chính hệ CSDL cũng sẽ nhanh hơn việc tôi viết SQL với mớ code kiểm tra.(không áp dụng cho TẤT CẢ những trường hợp khác)
Đúng là sẽ không áp dụng cho tất cả. Nhất là trong trường hợp kết nối qua mạng (kết nối tới SQL Server), việc tải/ gửi gói tin phải giảm thiểu đến mức có thể để giảm tải cho băng thông, việc hiển thị dữ liệu phía người dùng cũng không phải chờ đợi lâu. Do đó tôi mới code bẫy lỗi từng trường hợp riêng lẻ (gửi gói tin nhỏ) trước khi gửi nguyên một gói tin về server rồi chờ server phản hồi là dữ liệu không đúng yêu cầu (nếu dùng UpdateBatch càng mắc công kiểm tra toàn bộ record).

... nhất là khi con nháy nằm chết dí ở cái ô lỗi nào đó mà không tài nào chuyển qua được các ô nhập khác. Lẽ ra người dùng đã có thể tận dụng thời gian để fill các ô khác nếu không bị trói tay ở cái ô lỗi Bound vớ vẩn nào đó.
:) Anh lại mâu thuẫn rồi. Lỗi này do mình bẫy để tránh nhập dữ liệu rác vào hệ thống thì làm sao vớ vẩn được. Riêng việc việc có thể cho người dùng bỏ qua textbox này để nhập textbox khác thì đồng ý là để cái luồn nhập liệu được trơn tru sau đó mới gửi về một gói các báo lỗi các ô cần nhập liệu lại và các ghi chú hướng dẫn.

Bác chủ thớt mà vô xem lại bài mình chắc cũng giật mình vì một đống trang luận bên dứoi :cool: hehe.

Demo cách tôi dùng bẫy lỗi sau khi bấm [Lưu]:

 
Hihi mỗi người có mỗi cách tư duy, sở thích khác nhau, có người đi theo hướng A thấy hợp lý, có người đi theo hướng B cũng thấy hợp lý. Kết quả vẫn về điểm C. Miễn sao đạt yêu cầu là được.
 
Cảm ơn b
Cho mình hỏi thêm là khi mình tạo 1 nút thêm mới để nhập data cho form.
Mình thấy dữ liệu tự save.
Có cách nào để mình bỏ cái auto save này và chỉ lưu khi mà bấm nút save thôi được ko.
Ví dụ form mình có 3 trường
Tên form: Form_Checkin
CMND (Tên text là: CMND)
Họ tên (Tên text là: Name)
SĐT (Tên text: Phone)
Thanks!
 
Hihi mỗi người có mỗi cách tư duy, sở thích khác nhau, có người đi theo hướng A thấy hợp lý, có người đi theo hướng B cũng thấy hợp lý. Kết quả vẫn về điểm C. Miễn sao đạt yêu cầu là được.
tam hữu.
(chữ "hữu" ở đây là thuộc bộ khẩu chứ không phải bộ hựu, nguyệt, hay vi nhá)
 
Lần chỉnh sửa cuối:
Cảm ơn b
Cho mình hỏi thêm là khi mình tạo 1 nút thêm mới để nhập data cho form.
Mình thấy dữ liệu tự save.
Có cách nào để mình bỏ cái auto save này và chỉ lưu khi mà bấm nút save thôi được ko.
Ví dụ form mình có 3 trường
Tên form: Form_Checkin
CMND (Tên text là: CMND)
Họ tên (Tên text là: Name)
SĐT (Tên text: Phone)
Cảm ơn!

Đây thuộc về kiến thức cơ bản của Access, bạn kiếm các tài liệu Access hướng dẫn cơ bản với các ví dụ mẫu trong đó là bạn có thể làm được rồi.
- Bạn phải tạo một cái biến dạng Boolean (ở tầm vực form module) để lưu thông tin lưu hay không lưu.
- Bẫy ở sự kiện Form_BeforeUpdate().

Demo:

Mã:
Option Explicit

Private blnSave As Boolean

Private Sub cmdLuu_Click()
    blnSave = True
    DoCmd.RunCommand acCmdSaveRecord
    blnSave = False
End Sub

Private Sub Form_BeforeUpdate(Cancel As Integer)
    If Not blnSave Then
        Cancel = True
        MsgBox "Vui lòng bam nút [Luu] de cap nhat du lieu hoac bam nút ESC de huy.", vbInformation, "Thông báo"
    End If
End Sub


tam hữu.
(chữ "hữu" ở đây là thuộc bộ khẩu chứ không phải bộ hựu, nguyệt, hay vi nhá)

Anh VetMini hán thâm quá, đọc không hiểu. Không biết nghĩa tích cực hay tiêu cực. :) Cứ coi là tốt vậy.
 
Lần chỉnh sửa cuối:
:) Mình viết ứng dụng cho người ta mà bắt người ta phải biết tiếng Anh để đọc hiểu báo lỗi của ứng dụng thì làm sao lấy tiền họ được anh?


Đúng là CSDL phải chuẩn hoá, ràng buộc chặt chẽ thì mới nói tới chuyện Form, code...


Đúng là sẽ không áp dụng cho tất cả. Nhất là trong trường hợp kết nối qua mạng (kết nối tới SQL Server), việc tải/ gửi gói tin phải giảm thiểu đến mức có thể để giảm tải cho băng thông, việc hiển thị dữ liệu phía người dùng cũng không phải chờ đợi lâu. Do đó tôi mới code bẫy lỗi từng trường hợp riêng lẻ (gửi gói tin nhỏ) trước khi gửi nguyên một gói tin về server rồi chờ server phản hồi là dữ liệu không đúng yêu cầu (nếu dùng UpdateBatch càng mắc công kiểm tra toàn bộ record).


:) Anh lại mâu thuẫn rồi. Lỗi này do mình bẫy để tránh nhập dữ liệu rác vào hệ thống thì làm sao vớ vẩn được. Riêng việc việc có thể cho người dùng bỏ qua textbox này để nhập textbox khác thì đồng ý là để cái luồn nhập liệu được trơn tru sau đó mới gửi về một gói các báo lỗi các ô cần nhập liệu lại và các ghi chú hướng dẫn.

Bác chủ thớt mà vô xem lại bài mình chắc cũng giật mình vì một đống trang luận bên dứoi :cool: hehe.

Demo cách tôi dùng bẫy lỗi sau khi bấm [Lưu]:

Chắc lúc trước anh học cũng tầm cỡ trong lớp thậm chí là trong trường, kiến thức vững và dư xài để giải quyết mọi trường hợp nên giờ không hứng thú những cái mới mẻ hơn, lạ lẫm về sau.

Tôi đầu óc cũng không mấy thông minh lại tính hay quên nên vốn học không vững. Nhưng nhờ cái chóng quên đó tôi lại có may mắn tiếp cận cái mới vì kiến thức cũ chả còn để mà giải quyết.

Âu cũng do chênh lệch về năng lực đầu óc nên cũng khó hiểu ý nhau được nên thôi cũng không có ý gì thêm. Với lại những nội dung anh viết ra thuộc lý thuyết không có gì mới mẻ và tôi không thấy áp dụng được gì cho chính mình nên cũng tiếc quá.

Mình gợi ý dùng Index cho trường hợp này với hy vọng là nhiều bạn sẽ tìm hiểu tính năng Index mạnh mẽ và dùng trong các thiết kế CSDL tương lai. Biết ít nên mạn phép không nói thêm nữa và dừng luôn ở đây.
 
Lần chỉnh sửa cuối:
...Anh VetMini hán thâm quá, đọc không hiểu. Không biết nghĩa tích cực hay tiêu cực. :) Cứ coi là tốt vậy.
Cái này không hẳn là hán. Nó là trò chơi tiếng Việt, tại xưa rồi cho nên các bạn không dùng nữa.
tam = ba
hữu nếu không nghĩa là "bạn" (bộ hựu), "có" (bộ nguyệt), hoặc "cái vườn" (bộ vi) thì chỉ có thể là "phải" (bộ khẩu)
 
Cái này không hẳn là hán. Nó là trò chơi tiếng Việt, tại xưa rồi cho nên các bạn không dùng nữa.
tam = ba
hữu nếu không nghĩa là "bạn" (bộ hựu), "có" (bộ nguyệt), hoặc "cái vườn" (bộ vi) thì chỉ có thể là "phải" (bộ khẩu)
"Lỗi tại tui" nhiều chuyện, xía vào tranh luận làm gì. Em sẽ rút "kinh nghiệm thật sâu sắc" hichic hàhà
 
Hi cả nhà,
Mình dùng Access
Mình có 1 form nhập dữ liệu gồm các trường: CMND, Họ tên, SĐT...
Table đặt là "Checkin"
Form đặt tên là "form_Checkin"
Trường CMND là Primary key và dạng Number
Mình muốn khi nhập 1 CMND bất kỳ, nếu CMND đó đã được nhập trước đó rồi thì không cho nhập nữa mà sẽ hiển thị thông báo "CMND đã được đăng ký"
Các cao thủ giúp mình gấp với.
Cảm ơn!

View attachment 215259
Nếu đã thiết lập khóa cho trường này rồi thì chuyện đơn giản là bạn bắt lỗi nhập trùng thôi. Mã lỗi đó là 3022
 
Nếu đã thiết lập khóa cho trường này rồi thì chuyện đơn giản là bạn bắt lỗi nhập trùng thôi. Mã lỗi đó là 3022
Đó là trường hợp lý tưởng.
Trên thực tế, người ta thiết lập giao diện thân thiện (user friendly interface) sử dụng kiểm soát ở cả 2 giai đoạn. Giai đoạn mới vừa gõ key, và giai đoạn insert new record. Trừ phi công việc là batch update.

Bối cảnh điển hình là người dùng cầm 1 xấp hồ sơ, vào hồ sơ. Hệ thống thân thiện thì nên cho người ta cơ hội thấy vấn đề trong cái key (ở đây là CMND) ngay lập tức. Lúc ấy ngừoi ta sẽ đẩy hồ sơ đó sang một bên và tiếp tục chỗ còn lại. Sau khi xong hết thì ngừoi ta đem đống hồ sơ "vấn đề" kia đi tìm hiểu vấn đề của chúng. Nếu kiểm soát trễ, chỉ cần vài cái hồ sơ vấn đề là người dùng sẽ phát bực - mất công vào một đống dữ liệu để rồi chẳng nhập được!

Tôi nói trên quan điểm của người đã từng nhiều năm làm Product Manager và liên hệ trực tiếp với Product Manager.
Người ở vị trí này không chuyên về code, nhưng chuyên về khía cạnh hoạt động và hiệu quả của phần mềm. Một trong những trách nhiệm của họ là Giao Diện với Người Dùng (User Interface)
 
Web KT
Back
Top Bottom