Hi There,

 

I have a database that my company uses for inspections. It is running very successfully, syncing data between iPads and the main database using MirrorSync. All of the initial difficulties we experienced have been fixed and for the most part, we have a very smooth solution.

 

The problem I have now is the database size. During an inspection, we need to take photos of non compliant items. As the sites are quite large, there could be up to 700 tenancies in any one site, and in each of those tenancies, there may be anything up to 7 non compliant items. As you can imagine this makes the database expand very very quickly, and it is currently sitting at 5.5Gb 

 

What I want to be able to do is move all of the container fields to external storage. The only problem is, if I do this, I am not sure that MirrorSync will still sync all of the data. How would i best handle this situation to make sure I can still sync the required images and still manage to keep the size of the actual database file down?

 

 

There are a couple of general options, without knowing your specific use case

 

1) Start filing closed jobs to an external storage, that way you can run your operational database as pr today

2) Use super container, not sure how this will sync

3) Use web viewer with some selv made system, I have between 500GB - 1TB of data in such a repository, will require access

4) Others?

On the server side, you can simply switch to externally stored containers, and everything will continue to work for all of your existing offline users - they won't be able to tell the difference, and MirrorSync doesn't care either way.

 

You may run into an issue when distributing new offline files, however. Let me ask a few questions:

1) Are your offline users running a copy of the server file, or have you created a separate mobile file for them to use?

2) If it's a copy of the server file, are you distributing an empty clone, or a full copy of the server file?

Hi Jesse,

 

I am distributing a full clone of the database to the offline users.

 

Cheers

When you say a "full clone", can you clarify that? Do you mean a copy of the database will all records, or a copy of the database with no records?

Hi Jesse,

 

I mean a full clone of the database at that present time with all records, including photos that are in containers. This is why it is such a big issue. the database is far too large to be used effectively on a regular basis from the iPad running a remote database.

 

I need a way to store the photos externally on the server, but I also need the ability to sync the photos that are taken on the iPad on site as these make up part of the inspection. 

 

does that make sense?

Yes, I understand now. I was confused because typically the word "clone" implies that it's empty (no records).

 

There is an extra step that needs to happen any time you're copying a FileMaker database with externally stored container fields to an iOS device. This is a FileMaker requirement, not a MirrorSync one. We've documented the process here: 

 

http://docs.360works.com/index.php/MirrorSync_advanced_topics#Does_MirrorSync_sync_external_container_fields.3F

Ahhh lol, I wasn't aware that a clone was an empty database. Apologies for the confusion.

 

I will go through the info in the link you provided and test it out. See how I go :-)

 

Thanks

Sorry Jesse, Just going through that info, and I have a question. If the self contained file has all data available to it, does this mean that the file will have all of the container field files written into the actual self contained database?

 

If this file will have all of the data stored internally, would it not work out to be the same size on the iPad?