Skip to content

Check Record Before Insert

Use uniqueness checks to guide users before insert, while still keeping the final guarantee on the server where duplicate data is actually prevented.

Checking whether a record already exists before insert is partly a UX pattern and partly a data-integrity pattern. The frontend can warn early, but the real duplicate-prevention rule belongs on the server or in the database constraint. In Wappler, the strongest approach is to combine a helpful precheck with a final server-side guarantee.

Frontend precheck
Useful for quick feedback when a username, email, or code is already taken.
Server guarantee
Still required, because two users can race the same value at nearly the same time.
Use early feedback to reduce wasted form effort.
Keep the final uniqueness check on the server.
Explain the conflict clearly so the user can recover.
Treat precheck and insert as related but separate steps.

The precheck helps the user, but it is not the final gate.

A lightweight lookup can tell the user that a value appears to be taken before they complete the whole form. This improves flow on signup and create-record screens.

Best use
Give early guidance where uniqueness matters to the user experience.

The actual insert step must still reject duplicates. A frontend precheck can become stale immediately, so it should never be the only protection.

Concurrency reality
Two valid-looking submissions can still collide when they hit the server.

If the final insert is rejected, return a message the form can display cleanly so the user knows what to change instead of seeing a vague failure.

Actionable error
Tell the user which field conflicts and what to do next.

Uniqueness checks belong with validation, submit feedback, and the broader server-side workflow that actually saves the record.