I asked ChatGPT, here is what it recommended:


Given your scenario - multiple developers simultaneously working on a single Microsoft Access front-end application connected to a web-hosted SQL Server back-end - I strongly recommend adopting a structured approach to avoid conflicts, data corruption, or code overwrites. Here's how you can manage this effectively:

### 1. **Split the Database into Front-End and Back-End**
- **Front-End** (Access application: Forms, Reports, Queries, Modules)
  - Each developer should have their own local copy to avoid concurrent design conflicts.
- **Back-End** (Hosted SQL Server)
  - Centralized data store accessible via web.

### 2. **Use Version Control**
- Access is notorious for limited support for direct version control, but you can leverage tools to manage your Access objects (VBA modules, forms, queries, reports).
- **Recommended Tools:**
  - **OASIS-SVN** or **Ivercy**: Specifically designed for managing MS Access source code with SVN or Git.
  - Alternatively, export modules and objects regularly as text files, managed through Git.

### 3. **Establish Clear Development Procedures**
- Each developer should work on specific tasks in isolation.
- Use a clearly defined **change-management policy**:
  - Who works on what
  - How and when changes are merged
  - Approval procedures before integration

### 4. **Regularly Merge Changes**
- Periodically integrate changes to a master front-end copy.
- Schedule frequent merge meetings to consolidate work done by developers.
- After merging, redistribute an updated front-end to developers and end-users.

### 5. **Use Centralized Deployment**
- After each successful merge, deploy a stable master copy:
  - **Recommended**: Automated deployment scripts to distribute the latest compiled front-end (ACCDE files) to end-users.

### 6. **Leverage SQL Server for Heavy Lifting**
- Place business logic, complex queries, views, and stored procedures within the SQL Server back-end.
- Reduces Access front-end complexity, and simplifies concurrent development.

### 7. **Use Remote Desktop or Virtual Machines (optional but effective)**
- Consider hosting individual development environments on Remote Desktop or Azure VMs.
- Ensures standardized environment, making it easier to manage dependencies and configurations centrally.

---

### Recommended Workflow:
| Step | Action                                                   | Responsibility |
|------|----------------------------------------------------------|----------------|
| 1    | Each developer works on local copies                     | Developer      |
| 2    | Regularly commit changes to version control              | Developer      |
| 3    | Periodically merge changes into the master front-end     | Lead Developer |
| 4    | Test merged front-end against hosted SQL Server          | QA/Test Team   |
| 5    | Deploy stable ACCDE file                                 | Deployment Team|

---

### Final Thoughts:
- Access was originally designed for single-user environments. To effectively use it with multiple developers, discipline and structured management are critical.
- Strongly prefer the structured workflow outlined above rather than ad-hoc, simultaneous edits directly on the same Access file.

This structured approach ensures development integrity, data consistency, and minimal conflicts during your development cycle.

This is actually outside my area of expertise because I don't do collaborative programming. I never have. I've always been a solo developer. I've always done my own thing. I've never worked for another company in a team of programmers, so I have no idea how to do any of this stuff. I would recommend Alex. He probably would know a lot more about it than me.

The answer is probably GitHub or similar. For some reason I think Alex has shared a tool that does this in the past.

Sami, perhaps after you research this and figure out the best way to do it, you can put together a TechHelp video.

Richars, I already started doing that.
Will keep you posted.

VCS!
Get them to watch my GitHub videos and then get the latest version of the plugin
I need to do an updated video on that
Feature branches
Planning is key
Make a Project and build up your Issues list of features then assign and work on them
You can then review each others work and merge via a PR when it's ready
Test it with a mini project first, try it out, see what works best for you
(you should do this on solo projects too)

VCS / GitHub
git Beginner Level 1

Thank you Alex

Happy to work on a few PRs and the sample db with you, if you want.

Alex, I would love that. I will email you.

Many Thanks

I use query numbering in all my databases regardless.  Q_0001_QName, Q_0002_QName, etc.  This works great if there is more than one developer so that each developer is given a 1000 query allotment.  This naming convention also works great for nested queries so that all the queries that deal with an object will be all together in the database window.

You can also use this in the other objects and then add the dev initials also.  Frm_0001_FormName_DevInitials.

Again, this works great for keeping things together.  Frm_0001_a_MainFrmCustomers, Frm_0001_b_SubFormCustomers.

Just add the initials to everything and then you would know who is doing what...

I think Sami and Alex should make a video of their implementation of VCS / GitHub

I agree with Thomas Gonder

I have :p
Links above

@Alex I watched it a couple of times before. You totally lost me.

Can you provide further feedback on the videos, what didn't make sense?
What bits needed further clarification?