We need to know a lot more about your database design and exactly what optoins when importing this photo.
Did you use Insert Picture?
Do you have just one table in your file or do you have more than one? If more than one how are they related? Into which table did you "import" your picture?
Just one table.
Yes, only using insert picture - the same way we have been doing for years -- without this problem.
The photos are imported - as opposed to being stored as a reference. We are adding photos to existing records.
What you describe sounds very close to impossible. I'm not saying it didn't happen, but I'm looking for an explanation that would explain how this might happen...
Are you inserting the picture manually by putting the cursor in the container field and then choosing Insert Picture or are you using a script?
When you work with this container field on your layout, is this container field from the same table as specified in Layout Setup...|Show Records From or is it from a related table?
If you were inserting the picture "by reference" I could think of a very simple explanation, but you've indicated that you aren't inserting the picture in this way...
Yes - it is crazy - but I have repeated the problem in front of other witnesses here - so I know it's not me that's crazy.
We are doing a find for a specific record - using a button with a simple script of - go to container field - insert photo.
However I just looked at the tables and there is now a Table Name "Recovered Library"; details: 1 field, 0 records; Occurrances in Graph: Recovered Library
Sounds like someone recovered the file at some point. If this is a recovered file, all bets are off as to what results you may get when you try to use the file.
So . . . there is no solution and a year of work is gone because FileMaker program corrupted?
Surely you have back up copies?
If you have an undamaged, older back up copy of your file, you can save a clone (empty of records) of that file and import the data from your recovered copy.
Best practice is to never use a recovered copy of the file, but to replace it with an undamaged back up copy if that is at all possible. The recover process attempts to repair a file when it is damaged, but does not always do so successfuly and might modify the design of your file in an unexpected way. Much of the time, a recovered file will work just fine, but there's always that chance that it won't.
If not, I think you will need to rebuild your file. This doesn't have to be done from scratch, but it will take time and effort to do. You can import tables from your recovered file with the new table command to pull the entire table into your new file. You can import the scripts. You can set up new, blank layouts and then copy and paste all the layout objects from the damaged file. Each of the actions, however, could bring corruption with them so you have to make frequent back up copies and run a recover after each stage to confirm that the file is OK. If a recover reports fixing problems with the file, you toss the recovered copy and your latest version, reverting to the previous back up and then you rebuild that portion of your system from scratch.
This is not a simple process, which is why maintaining numerous backup copies stretching back over time can be so important to protect both your data and also your database design integrity.
Yes we have back up (saved copies on a weekly basis - and timemachine backup going back until May 2010) -going through them the last file without the "Recovered Library" table was on 1-25-2011. However speaking with another user, he said the file crashed and was recovered sometime in November.
Do we need to go back to the November version before the first recover - and recreate all the work since then?
or from the point mentioned above where the additional table was created?
Test a possible back up file's integrity by performing a recover on it to see if any problems are found. There's also a third party product called FMDiff you can investigate that can also do this.
and timemachine backup going back until May 2010
Hate to say it, but that might be the cause of your file corruption here. If Time Machine is backing up your entire computer where this file resides at a time when the file is opend, both the back up copy created by Time Machine and the original file can be corrupted. Third party back up software should be set up to only back up FileMaker files that are closed at the time that they are backed up.
I've been using Time Machine for a couple of years and never heard of or encountered this problem. It's almost certain TM has done incremental backups dozens of times when FM files have been open. I've used TM to replace files backed up an hour previously as an alternative to undoing work that's gone awry. I've never had any problems. Given TM does incremental backups every hour, and I routinely have FM files open for most of the day, you'd think I'd have encountered a problem if what you're describing is in fact an issue. Even if FM were writing to disk at the time of backup, I don't see how the original could become corrupted by Time Machine.
I'm repeating what the Technical Folks at FileMaker Inc. have posted here repeatedly in the Forum. You'll need to ask them to explain further. I've wondered about how backing up an open file could damage the original myself, but have assumed that the techs have seen cases where this seemed to have happened.
Of course, the big conundrum when file crashes and you find it's corrupted is: "Did the corruption cause the file to crash or did the crash corrupt the file?" And that can make it difficult to sort out cause and effect with any kind of certainty.
Josh Ormond over at FMForums gave me a great idea for users of Time Machine. Rather than allowing your open FM files to be backed up by TM, and possibly introducing corruption, exclude the (original) FM files from TM backups (see Time Machine preferences) and include a "SaveAsCopy" step to the Closing Script of each file. These saved (in another location or disk of course) files are then static . . . not writing to disk because they're not open. Allow these files to be backed up by TM. This way hourly backups will be made and available based on the file status when closed.
Tomorrow I'll post a generic set of script steps if anyone's interested. I'll sleep better at night knowing Time Machine is backing up unopened "static" files.