IF both computers have been installed with the same single copy license key, then no this cannot work. You'll get an error message telling you this and FileMaker will shut down on the second computer to attempt.
The file can be parked on the desktop, that it is not opened. The Macbook Air can open the file via the network to work on it. It is a matter of opening Filemaker in both computers with a single license, that is not allowed. But the single license can access the file.
If the database is on one computer with filesharing on, either computer can open it at one time.
If the database is on a flash drive, either computer can use it. Backups are good.
According to FIleMaker TS personnel, using FileSharing to access a database risks damaging the file.
Thanks all. This is not optimal but I figure it will have to do.
I think the simplest solution, when working in another room, is to use FileMaker Go on my iPad instead of the desktop app on the MacBook Air. I really can't justify paying for two licences just for this.
But is this thing about FileSharing damaging the file real, or just something to keep people away from a situation that may possibly, but very improbably, go wrong?
I have a serious backup strategy so if it does corrupt a file, it would be quite easy to get a good one back.
It's been the standard warning from FileMaker Techsupport for many years over many versions. There are two ways that it can result in damage according to them:
1) If two users attempt to open the file at the same time.
2) If you have made design changes to the remote database and you have a network glitch right at the moment the changes are being saved back to the file.
I have helped others here that seem to have ended up with a corrupted file when they were using filesharing in this manner.
I have also helped others where they were dealing with file corruption that was not discovered until many months had gone by since the event that caused the corruption took place. (They had periodic backups and had to go to a backup made just before the event that we suspect caused the corruption before they got a file that worked correctly.)
Thus recovery to a backup might not be as simple as you might think as many of your backup copies may be backups of the corrupted file before you discover the problem.
Good to know. In my case, there will never be two users accessing the file at the same time. Also, I would never make a design change to the database while on my MacBook Air. All I would do is add records or change the data in a record. Or do some searching.
So if I understand correctly, I could use it that way with minimum risk if I'm careful.
I have daily backups on various external storage devices, but the history is dependent on Time Machine (two of them alternatively during the day). I also use Dropbox for offsite backups... which also has history.
About the file corruption, how did it finally come to the attention of the user? Do you mean that a file can be corrupted and still be used normally?
While rare, file corruption can be "latent". It's damaged but the user doesn't detect any issues at first.
I can only speculate based on years of experience with database systems and a degree in Computer Science, but typically, this happens because there are parts of the database file and parts of the Filemaker application code that aren't accessed or executed every time the file is opened. In software development, this is sometimes stated at the 90% rule. The rule is that only 10% of a computer application's codes is executed 90% of the time.
Thus damage can occur somewhere in that seldom executed or accessed 90% and thus does not produce noticeable problems until the day comes that the user does something a little different with the file. That something different may produce an immediately noticeable change in behavior such as a crash or it may damage the file further in a way that results in the file now exhibiting problems every time the user opens the file.
In the case that I recall most clearly, the user had to run a recover on each backup file until he found one that did not report a problem during the recover. The date of the newest "clean" back up then suggested to us that a change made to the database on that same date likely damaged the file when the design change was committed back to the file over the network.