Best practice for small team 'Onedrive' or 'Dropbox' concurrent model usage.

[Rich Anderson]

Actually, I'm doing this now and it works really well, as long as your team is relatively small (2 or 3 people).   What you do is put a shared replica on a Onedrive/Dropbox that is synched to everyone's PC and then everyone synchs to that replica inside of EA.   When you do the synch from with EA, then OneDrive/Dropbox will automatically put that file on everyone's PC.  Then, when they synch to their local replica, they get the changes.  If you are  reasonably careful that others are not all editing the same elements in the model, then it works.  (You just need to monitor the replication conflicts)  I've probably done this 3 or 4 times, quite successfully, and found it much easier than setting up central server database. In my case, the other members of the team are on different continents and work for different companies, so the alternative is setting up a database on AWS using Cloud services, which I have done as well.  The problem with that is performance.  When everyone works on a local replica, the performance is much better.  This is a very effective way to exchange model data for SMALL teams and takes about 10 minutes to set up.   

[Geert Bellekens]

Do you mean you use the Master/Replica system for this?

Be careful with that however and make sure you have backups.
I've seen a few users with corrupted Master/Replicate models here on the forum. Once it's broken it really is completely broken and you can only go back to your backup (if that exists)

Geert

[timoc]

Do you mean you use the Master/Replica system for this?

Be careful with that however and make sure you have backups.
I've seen a few users with corrupted Master/Replicate models here on the forum. Once it's broken it really is completely broken and you can only go back to your backup (if that exists)

Geert

Would baselines work to mitigate this?

[timoc]

"The sure sign of that you have a kitten-class application or server? Everyone gets upset when a kitten dies."

Even if i only ever want one EA database server, infrastructure as code (the automation) is a net benefit. If the EA Kobe beef dies, i can get another.

Maintenance is easier. Extensibility, e.g. adding RAS or other automation is easier. Handing responsibility over to someone else, also easier. The cow/kitten argument for infrastructure as code works at any scale. I would argue this is especially true for database schema development and migration, in combination with vagrant or docker.

No one disagrees with the benefits of infrastructure as code, but dressing a kitten in cow hide, doesn't turn it into a cow.  Real infrastructure as code benefits from properly using underlying data and storage technology.

Is your assertion then that if i don't have more than one cow, it is by default a kitten?

[Geert Bellekens]

Do you mean you use the Master/Replica system for this?

Be careful with that however and make sure you have backups.
I've seen a few users with corrupted Master/Replicate models here on the forum. Once it's broken it really is completely broken and you can only go back to your backup (if that exists)

Geert

Would baselines work to mitigate this?

Replica/Master can corrupt your access files to the point that they are not usable anymore.
Since baselines are internal you won't be able to access them anymore in a corrupt file.

If you externalize these baselines (basically they are just xmi files that are stored in the database) that could be a way to restore broken stuff.

But if you are going that direction anyway, I would rather suggest to use an external version control system (TFS, SVN mainly) to share models across different models.

Geert

[timoc]

Do you mean you use the Master/Replica system for this?

Be careful with that however and make sure you have backups.
I've seen a few users with corrupted Master/Replicate models here on the forum. Once it's broken it really is completely broken and you can only go back to your backup (if that exists)

Geert

Would baselines work to mitigate this?

Replica/Master can corrupt your access files to the point that they are not usable anymore.
Since baselines are internal you won't be able to access them anymore in a corrupt file.

If you externalize these baselines (basically they are just xmi files that are stored in the database) that could be a way to restore broken stuff.

But if you are going that direction anyway, I would rather suggest to use an external version control system (TFS, SVN mainly) to share models across different models.

Geert

Some onedrive/dropbox options have version control of a sort, that i have found handy. The ability to revert a model file back to a previous save. The same would be true with an exported XMI.

[Geert Bellekens]

Yes, but that is not the same as connecting EA up to an external version control system.

In that case it works with exclusive locks, allowing only one person at a time to edit a package.
This system prevents accidentally overwriting someone else's changes.
It is sometimes used as a way to collaborate on the same model from different locations without the need to setup a central database, terminal solution, or cloud server.
All you need is a publicly accessible TFS or SVN
If you want to work without a database, but still want to have some robustness in the data, you can use this type of setup. Downside is that you have to check-in before your co-workers can see your changes.

Geert

[Rich Anderson]

Yes, it is always prudent to have backups, and I do that.  I use a free program called Cobian Backup to make these more automatic.  The other thing about Access replication is that while it can fail, it's also pretty well established and tested.  It's pretty mature.  I once had to run a replication across 50 instances with Access back in 2002 (nearly 17 years ago) and it (amazingly) worked much better than I expected.   

I just repeat that this can work very well for SMALL teams as long as it's properly managed.  If you have no easy way to set up a shared database and your team is small, this is WAY better than manually copying and pasting data between models.