Both approaches have their pros and cons, and the choice depends on maintainability, security, and how user access rights are managed. Let's break down the considerations:
Approach 1: Connection on Main Form or DataModule
- Workflow:
- A record is selected.
- Data is retrieved and passed manually to another form (non-DB-aware controls).
- The form allows users to edit the data.
- On save, changes are sent back and applied to the database.
Pros:
More Control Over Data Handling
- You explicitly manage when and how data is written back, reducing unintended updates.
- Allows business logic validation before updating the DB.
Security & Access Control
- Since editing occurs in a detached dataset (e.g., using local variables or objects), users without write access can view data without modifying it.
- You can validate user permissions before sending updates to the database.
Better Concurrency Handling
- Prevents locking records unnecessarily (since changes happen locally and are only written back when the user confirms).
Easier to Work with APIs or Multiple DBs
- This model is similar to handling REST APIs or multi-database architectures, making it more flexible.
Cons:
More Code & Complexity
- Requires additional code for transferring data between forms.
- Need to manually track changes and update the record accordingly.
Can Be Less Responsive
- If the dataset is large, pulling all the necessary data first before opening the form can slow down performance.
Approach 2: DB-Aware Controls & Direct Interaction with the DB
- Workflow:
- A record is selected.
- A form opens with DB-aware controls (e.g.,
TDBEdit
,TDBGrid
), which are directly connected to the dataset. - Any changes are instantly reflected in the dataset.
- The form can commit or cancel updates directly.
Pros:
Faster Development & Simpler Code
- Less code is needed because DB-aware controls automatically reflect and update data.
Live Data Editing
- No need to manually pass data between forms; changes are instantly applied.
Ideal for Small to Medium Applications
- If users are always expected to have write permissions and concurrency issues are minimal, this method is straightforward.
Cons:
Potential Security Issues
- If a user has edit access, they can modify data without additional validation, unless explicitly checked before saving.
- Access control must be enforced at the dataset or DB level.
Concurrency & Locking Issues
- If multiple users edit the same record, who wins?
- DB-aware controls might keep a record "locked" while editing, leading to blocking issues.
Harder to Manage Access Restrictions
- If different users have different permissions, you need additional logic to disable controls dynamically.
Access Rights & Choosing the Right Approach
If users have different access rights, Approach 1 is the better choice:
- It allows granular control over who can edit data.
- Read-only users can view data without affecting the database.
- Write access can be validated before committing changes.
If all users have uniform access rights, Approach 2 is faster and easier to implement.
Which One to Choose?
Criteria | Approach 1 (Manual Transfer) | Approach 2 (DB-Aware Controls) |
---|---|---|
Security & Access Control | ![]() |
![]() |
Concurrency Handling | ![]() |
![]() |
Performance | ![]() |
![]() |
Complexity | ![]() |
![]() |
Scalability | ![]() |
![]() |
User Experience | ![]() |
![]() |
Final Recommendation
- If you need strict control over access rights and concurrency, go with Approach 1 (Manual Transfer).
- If you want rapid development and simplicity, Approach 2 (DB-Aware Controls) is fine for small-scale apps with uniform user access.