Child Item

Conflicted Copy different scenario without a solution

I've recently moved away from One Drive (there are some serious privacy concerns with it in my opinion) and I'm trying get around the Dropbox Conflicted Copy "problem". Dropbox creates a CC file where its newer than the existing file if it's open somewhere else (shared folder). In my scenario that simply doesn't work and creates significant problems. I have one Access file that's is primarily used at one remote location. If someone else (in the share group) opens the file (Access saves or sets the archive bit for a file just by opening it) to have a look at the data and the open file (at the primary remote location) is closed, its then saved as a CC file and desktop link on the remote PC now references the wrong file (with missing data) the next time it's used.

My suggestion is to have options. 1. Have a switch to turn the function off (I'm far better off without it). 2. If we must have it, create an option to rename the older file to the CC name thus creating an archive and keeping the current name as the newest. At least with that option we can go back over history of who's changed it and when. 3. Lock the open file (read only) so it can't be altered.

I hope this gets an airing as my solutions are becoming slim.

Cheers

Dayle...

Find more posts tagged with

Sync

Closed - Partially Delivered

Comments

Mark

Just a heads up. You are going to run in to huge problems running an Access database on Dropbox I'm afraid - in fact on any cloud storage system. Its just not designed to do that.

The issue with Conflicted Copies is you have two different data sets. So in the two files of the Access database you'll have 2 different records - these need manually fixing hence the conflicts. It wouldn't work to just archive one and continue using a version without looking at the other.

daylef

Hi Mark

I've been using this scenario on One Drive for years which has been working OK with some reservation. I've moved all our volatile files to Dropbox and this is the last hurdle. I hasten to add that I have a NAS that copies the Dropbox content on a differential basis so as not to rely on cloud storage alone and to have a "local" backup. This issue with conflicted copy is a very bad outcome (for me) and one that could be easily fixed. In this scenario the field agent just populates the data fields and a local guy extracts the data on a daily basis. The problem starts when the local guy opens the file when it's still open in the field as he has no idea it hasn't been closed. Previously (with One Drive) I ran a batch file on a 5 minute timer that copied the live file to another folder for him to extract and that's what I'm looking to do now. It's a backward step but will work.

Jay

Hi @daylef, in general and as @Mark said, we recommend that people do not sync live databases with Dropbox. Most databases have remote access methods anyway, so you don't need to sync the live database. You can sync saved snapshots, however, with no issues.

That said, you can use Dropbox to share the data, but you need to take great care and understand how file syncing works.

Most programs create a "file lock" on any file that they are using, and this lock will prevent Dropbox from syncing the file. In some cases you must fully quit the application before Dropbox can sync the data. You must then make sure Dropbox has finished syncing before trying to access the file from any computer.

If you are sharing the data between computers you must NOT run the application on more than one computer at a time. You will generate file conflicts and other problems.

Thus, the pattern needs to be:

Let files sync
Start application
Save files
Quit application
Repeat on different computers.

If you have any further queries, feel free to message back.

daylef

Hi Jay

I should probably clarify a couple of things. Firstly Access is not my forte. I've created some fairly intricate Excel spread sheets in my working life but I've never had a need for Access. On this occasion the file in question is a log sheet and is stored as .accdr (runtime). In the field, the operator clicks on the link which was a local file to that machine but is now stored in a shared Dropbox folder. He populates the fields as required and has the file open for the best part of a working day. Quite often the file isn't shut down and is left running for the following day with just a date change and more data (same file but just gets bigger). There is no input data at any other location. Meanwhile back in the office, one individual opens the file to see what has transpired during the day and processes the data (by hand). It appears that by opening the file with the remote file open, it creates a conflicted copy and my understanding is Access sets an archive bit just by opening the file. Based on that scenario, it should work and would work if I didn't get Conflicted Copies of the newer file. If the file was marked CC for the older file, the problem would disappear. As I said previously, this worked with OneDrive for years but was managed differently. My plan at this stage is to do a file comparison (using the command line "fc") and run a batch file to copy it to another shared folder for access back at base. I know that works but is messy and wasn't my preferred solution. Cheers Dayle...

Jay

Since OneDrive might be more integrated with Access, given that they're both Microsoft products, it's possible that they have workarounds built into their systems.

For Dropbox, opening an Access database, while already open elsewhere, would result in a conflicted copy since the act of opening a database could write information to it (such as logs for the last date opened, or an archive bit set as you mentioned). As such, there isn't a way to avoid conflicted copies when this occurs.

There is, however, a feature on some plans called file locking, which prevents other users from editing a file while it is locked. Only the person who locked the file, or team admins, can edit it while the file is locked. Perhaps this might help out in your situation, since the operator can lock the file and edit it, and the office individual can still open the file to view it, without writing anything to the file.

While this does work for normal single files, it should also work for databases (if they don't expand into subfolders that are visible on Dropbox), so I would recommend testing it first, just in case.

daylef

Hi again

I've developed a solution which relies on file differences to create a rolling backup. As I said, it wasn't my preferred solution but unless I can find a way to make CC the "replaced" file, it simply can't work for me which is very disappointing and lessens my full intentions for Dropbox. Thanks for your help. Dayle...