Save a copy - self-contained - could not be created

[Ziphius]

I have a database with a container field linked to photos stored externally. I want to create a self-contained database but I get the error:

 

"could not be created on this disk. Use a dfferent name, make more room on the disk, unlock it or use a different disk."

 

I've tried different names, there is plenty of space on the disk, and it's not locked. Filemaker's help page has this to say:

 

 

ISSUE:
When attempting to export data from FileMaker performing an action such as Save Records as Excel, Exports field Contents or Export Records you receive the following error:

““<filename>” could not be created on this disk. Use a different name, make more room on the disk, unlock it or use a different disk”

EXPLANATION:
There can be multiple causes for this generic error message. The following is a list of some possible scenarios:

• You are attempting to export to a location that does not have read/write privileges for that user account.
• There is not enough space to save the file in the desired location.
• You are attempting to export a file with an account that doesn’t allow for exporting.
• An invalid character is used in the file name that you are attempting to export.
• There is another file with the same file name in the location your attempting to export to.
• An invalid file path was saved in the script step to export records.

But none of it seems to apply.

Any suggestions?HMMMantaOnlineDatabase2013.fmp12.zip

 

[Rick Whitelaw]

I can't view your file now on an iPad, but from experience this message usually results from using illegal characters in the file name.

[Ziphius]

The file name is: 

 

HMMMantaOnlineDatabase2013.fmp12

 

I don't suspect this has any illegal characters?

[IdealData]

Rick was actually referring to the message you are getting, not the name of the file you posted.

 

Your file has only one script in it which has no exporting steps.

Exactly how are exporting the photos?

[bruceR]

He's not trying to export. Save as.

 

"I want to create a self-contained database..."

[NLR]

I looked at your file, and see the problem...

 

I tried the various "Save a Copy as..." options and all but one worked.  As you say, that error message pops up if you attempt to save the file as a "Self-contained" copy.  On looking at your field definitions, I see a container for photos that uses "external" storage.  I suspect that's where the problem lies.  

 

See also

 

http://help.filemaker.com/app/answers/detail/a_id/10797/~/could-not-be-created-error-when-saving-a-self-contained-copy

 

 

Regards

Ralph

[bruceR]

Ralph: no, that's the entire POINT of save as self-contained.

 

It pulls externally referenced files into the file. So that it can be used as a self contained file. Or so that it can be loaded somewhere, such as on a server, and external storage can be turned back on.

[bruceR]

Ziphius: once you clear out all the bad photo references it seems to work fine.

[NLR]

Ralph: no, that's the entire POINT of save as self-contained.

 

It pulls externally referenced files into the file. So that it can be used as a self contained file.

 

I know that Bruce...   

 

When I mentioned the container using "external" storage was the likely problem, I didn't intend to give the impression that it was the wrong thing to do...  Rather, that there may be a link type of problem, one that prevents Filemaker from getting the information it needs from those external sources - to allow the file to bring in those photos.

[bruceR]

Ralph: I think you're correct, but that certainly wasn't clear (to me anyway). Yes, fix all the records where there is an error for the externally linked picture and it works fine.

[Ziphius]

Thanks for the possible solution but I don't see any bad photo reference files on my end. I wish to upload the main database to an online Filemaker Host, therefore trying to create a self-contained file for upload, the attached file was an example of that database. Unfortunately when I try to attach a 12mb zip file that contains the database and reference files, it won't attach to this message. Maybe I'll try to shrink down the image file sizes.

 

 

 

 

[bruceR]

I think you should look harder at your photo files.

 

I just did a simple replace on all your images with valid externally stored images and save self-contained worked perfectly.

[Ziphius]

Bruce,

 

Original filenames have the following naming structure: HAMR2012SEP24-MHD-8308.jpg

 

I took out the "-" from the filename to get HAMR2012SEP24MHD8308.jpg and dropped the file back onto the container field.

 

When I tried to save a self-contained copy, it still didn't work and the links to the photo were now broken. I can never understand if the storage reference for the container field never changes, and the table name, and the field name that the photos are in also never change, how can the reference links get broken?

 

Interestingly enough I have one photo in the database that has a different naming structure, which is "DSC04315.jpg". If appears that the database is happy with that file as the link never gets broken. What is the difference between a file named "HAMR2012SEP24MHD8308.jpg" and one named "DSC04315.jpg"?

[bruceR]

There is no problem with those file names. You really need to fix all the image files. The file saves fine if files with those name are used. It worked with the DSC files because you inserted valid files.

[Ziphius]

Bruce,

 

If you can explain to me why the DSC04315.jpg is a legitimate file and therefore displaying properly in the container field, but all my other jpegs (e.g.,HAMR2011AUG10MHD5834.jpg) are not legitimate files, and therefore not displaying properly in the container field, that would be very much appreciated. They all seem like legitimate jpeg files to me, and each of them was added to the container field "photo" by dragging and dropping it.

 

Thanks,

 

Mark

manta.zip

[bruceR]

You have provided no password.

[bruceR]

I used the FileMaker file from your original link but the picture folder from the recent ZIP file.

 

This is getting really tiresome.

 

There is no problem.

 

There is no problem when using any valid file including the one with the long name. You DO have a problem if you have "leftover" unattached images in the image folder.

[Ziphius]

username: manta

password: manta

[Ziphius]

You are correct, this is tiresome but I very much appreciate your helping me with this problem. When I drag the photos back over the container fields, they show up and a copy is made in the exact same reference folder, only the filename adds _1 since it is a duplicate file. If the images are legit jogs and the reference is the exact same as the file already in the reference folder, why would it not show the images in the first place? And why it seems happy to show the one image with the short filename is beyond my understand of plain logic.

 

I've also uploaded this database to a host server and having the same issues. Not that I would expect anything different but it does recreate the problem in a different scenario.

 

http://hmmp.pointinspace.com/fmi/iwp/

username:manta

password:manta

[bruceR]

THERE IS NO PROBLEM WITH THE FILENAMES.

LOOK ELSEWHERE FOR THE PROBLEM.

THE FILE NAME IS NOT THE PROBLEM.

 

I see that you are using Dropbox. I don't think you mentioned that!

Dropbox folder management is the issue.

 

I see that you can delete all the photo records this photo folder will still contain a copy of this image.

It looks like you need to reconstruct this folder.

 

 

file:/Little Mac 2/Users/markdeakos/Dropbox/Mantas/Manta Database/Online/HMMMantaOnlineDatabase2013.fmp12

 

This is my last reply.

[Ziphius]

ok, can't use dropbox. thank you!

[Ziphius]

Just FYI if anyone can assist with the broken links, the "Get(Filepath) doesn't recalculate so the link to the dropbox path was inaccurate since the database resides on my desktop. Seems if the container reference points to the proper folder, it should see and display the images fine, but it's not.