not what we are thinking about cloud computing: Disappearing in the air (-:
Serious: Can not be. If You write to a DB file, alter/enhance it's funcionality - it will be written to disk. Somewhere...
Any Chance that You were working on a local copy, maybe the original file before it's been copied to the server?
Any Chance that You copied the file from the server's data directory instead of the backup directory (You created the backup using a schedule via admin console?)
with FMS 11, every server task should be done via the admin console. When You are stopping the server: Does the file show the missing content?
And making structural changes to a file while hosted on the server and used by others is dangerous. It's kind of like trying to change the fan belt for your car without turning off the engine...
When you commit changes to a table or even open certain dialogs for changing the specs for a field, the table is locked and other users (and scripts they perform) will be locked out of edits on the table until you click OK or the change commit process completes. A script with Set Error capture enabled can then fail silently.
Even without such a lock situation, the change in system appearance or behavior can catch your user's by suprise--which can result in confusion or even errors in the data they are entering/editing.
And should you get a network glitch while comitting the changes, your file can be corrupted. Some deveolopers over in Tech Net have even suggested that a scheduled backup that kicks in at this point might damage your file...
I know it sounds weird... but...
Why would FileMaker allow me to modify a file if it is so dangerous? Seriously, i see your point but if i can modify the structure of a file while it's hosted on the Server and FM allow me to do so, then it's a clear error from the FileMaker SW designers. THIS IS A BUG. in addition i was the only connected user. Should be quite easy for the server to shut down the files that are modified by a super admin and give him exclusive access.
Again, if a backup system can corrupt an open file while backing it up i would change backup software. THIS TOO IS A BUG OF THE BACKUP SYSTEM.
I personally think Time Machine is clever enough to backup files that are closed, locking the files down when it's copying... so, good idea, but this too leads to a flaw in the software design.
To Markus Schneider:
You said: "with FMS 11, every server task should be done via the admin console." is this written somewhere?
"When You are stopping the server: Does the file show the missing content?"
No, because the problem was: I saw the file remotely, and was able to work on it as if it was in a RAM Disk but it was not present in the server's data folder (and nowhere on the PC's) so i supsect a communication failure between client and server with no error messages on the server side.
...In addition comes the security update released by Apple...
I do not know that the back up system can damage a file, can only report that one or two participants in a forum have warned against it.
It is my understanding that Time Machine backs up all files whether open or closed. Backed up copies of open FileMaker files at best trigger a consistency check when opened and at worst will be corrupted copies. FileMaker server controlled backups are the only method available for backing up the file without closing it that does not have this result as far as I know.
Keep in mind that we didn't design the system but can advise you on best practices and modifying the design while the file is open on the network is not a "best practice" use of the system due to the risks involved.
i supsect a communication failure between client and server
If this were the case, others would have reported being unable to use the system at the same time you were working on the database. From my perspective, the only way you could do four hours of design work and not see any such changes in your file is if you were making design copies to a different copy of the file. Otherwise the way that FileMaker automatically saves the files to disk should have saved at least some of the changes made even if there were issues with the network or you clicked a cancel button when you should have clicked OK to commit changes. I suppose you could open manage | Database and made changes for 4 hours without clicking OK, but that seems very unlikely especially since you would very likely have been locking users out of tables at the same time.
Is the system set up to make regular scheduled back ups? did you check them?
RAM-Disk? Your Data was on a RAM-Disk that was mounted during Your operations?
To be sure: Did You run a Backup (schedule) via the admin-console or did You just opy the file from the data-directory? If You just copied the file: Stop FMS and get the file one more time.
FileMaker was always problematic when more than one file was accessible. As for the last 10.6.8 patch, I've heard of really big troubles (I don't have a patched Snow - all client machines on 10.7.x, one of the servers runs under Snow, but no patch so far)...
Admin console: Before FMS 9, we had to stop/start the FM server to have new db files 'mounted'. Now, we can do this via the console - and I strongly suggest to do so (file permissions, lot more)
As for working on a hosted DB while its available: I'm just expecting that a modern DBMS can handle this. Today, we can't ask our customers to snail-mail us the Databases (doesn't matter if snail-mail or via ftp, whatever) as we did in the 90ties. I'm aware of the problems when one is in the db definition (define fields) and I think about it as a bug - and I'm checking for online users via the admin console before going into 'field definitions'...
Phillip Hubert said, " i can modify the structure of a file while it's hosted on the Server and FM allow me to do so, then it's a clear error from the FileMaker SW designers. THIS IS A BUG."
No. It is not a bug. FileMaker allows work on a served solution because FM assumes the Developer knows what they are doing. There are situations when a Developer must work on live solution but doing so always runs a bit of risk (and in some situations such as relational changes) can be serious risk. But FM is not responsible for know WHEN it is okay and when it is not. That is the Developer's responsibility.
However, if you wish to put in a feature request, you can do so here:
I suppose the request could be restricted to 'graph changes' or something but the concept would not be embraced by all Developers ... many work in the graph while served for TESTING and not on live systems.
One suggestion that I have previously posted via the feature request form is that opening a dialog to modify a field's calculation or auto-enter property not lock the table, but instead only lock the table when a change is committed. This would allow developers to open and inspect such dialogs without locking the table while they do so.
I also suggested that FileMaker could pop up a warning dialog when developer actions within Manage Database will result in such "locks" and only if the File is open in a multi-user state. That would help inform Developers new to FileMaker as to the possible problems that might ensue if they go ahead and commit the change.
It's also possible to reduce a significant number of "live update issues" by using the data separation model as then many changes can be deployed simply by swapping out an older copy of the iterface file for a new one and not needing to import any data in the process. It's not a cure all as changes to the data file still require the import, but it helps.
Hello, everybody i was able to reproduce the error. short movie here:
I create a record, switch to safari, go back to fm, all records lost, also on the server.
Very good feature!
How can this be possible?
But.. it happens
If the file is disappearing, then my guess is that it is unclear exactly where the file is that you are using. Use Get(FilePath) to determine exactly which version of the file you are working on in the client at the time it has "disappeared" from the server.
Regarding Time Machine or any other backup product, DO NOT use ANY of these backup products on live database files. EVER. Doing so won't generally make a file disappear, but it is guaranteed to corrupt your data file eventually. Likewise, don't even try to copy a data file while it is open either on server or on a client -- this is another surefire way to eventually end up with a corrupted file.
Finally, as I posted on your other thread on this topic:
FileMaker does not lose data. And I doubt that going to a browser and coming back has anything to do with it either.
But it is difficult to tell what is going on from your movie without seeing (a) the status bar that shows how many total records there are and what the found count is, and (b) without seeing the script that runs when clicking on the Articoli or Contotti buttons, and (c) without knowing what the 6/6/6 and 7/7/7 numbers are supposed to represent.
In all likelihood, there is just something in that Articoli or Contotti script that is either deleting records or just resetting the found set in an unexpected way.