Filemaker crashes after using applescript to insert over 3000 pict images into new records

[xyz3]

Title pretty much so says it all. Happens to a local database or a hosted server database. Tested in Filemaker Pro 8 and Filemaker Pro 10 demo and Mac OS X 10.5.6 (PPC or Intel).

Has anyone else ever hit this bug, or have ideas?

Basic code:

set imagePreview to read (filePath as alias) as picture from 513--get the image data

tell application "FileMaker Pro" to set data cell "imagePreview" of record ID theRecordID of theDatabaseRef to (imagePreview as data) --insert the data into the filemaker record

[Simon Brown]

I'm guessing that the earlier code is opening the file? If so, do you ever close the file that you are reading from?

Simon.

[xyz3]

No. No Closing. I tried using the commit records script, and a flush cache script, but neither seem to help. The script doesn't open the file, but I suppose it could store a database file ref and close the database then re-open every x number of records...

Would be super nice if I could figure out who to report this bug to so it could be fixed. :(

[xyz3]

Hmm. If you only have an open database, if there an applescript property to get the location of the database file?

[xyz3]

this is silly...

set openDatabaseFilePath to POSIX file (do shell script "lsof -bw | grep FileMaker | grep 'myDatabaseName.fp7' | awk '{ print $9 }'")

[Fenton]

I don't really know why it's crashing. Sounds like a memory overrun kind of thing; which I'd have to leave to the AppleScript experts. But I can think of a couple methods which use FileMaker more, which would likely be more stable.

If the PICTS are all in the same folder (or subfolders) you could use the Import Folder step, which supports picture files. You could Show All Records, then use (•) Matching records, matching on the file name or path. It can also create a thumbnail, if you need one.

A more flexible methods similar to your earlier method, would be to do the files individually, but instead of setting them into a field calling a FileMaker script, with the Insert Picture command. You can call a FileMaker script from AppleScript with: do script FileMaker script

You would need to use a FileMaker syntax path however, but that can be calculated from the AppleScript path; the full absolute path, not the short Unix one, unless you add the hard drive name back; also add the "filemac:/" prefix.

filemac:/Macintosh HD/Users/fej/Desktop/somefile.ext

If possible, I'd run all this within a FileMaker Perform AppleScript step. AppleScript seems to run faster from within FileMaker than Script Editor, in my experience.

P.S. There is a Get (FilePath) function in FileMaker, to get the path of the current file, in FileMaker syntax; wouldn't work so well on a hosted file however.

Edited April 17, 2009 by Guest

[xyz3]

Hi Fenton! Thanks for the advice. The picts are generated by me using coreimage, source files are camera raw. Basically I want a path to the raw in the database, for opening, etc.. But want a preview as well.

I did a few tests yesterday; adding references to the files, which is slightly better, but makes the database slower once the process is complete, and less standalone than I want. I added code to close the database after 500 images, then re-open. That is probably the best bet thus far..

I tried the internal script a while back, and it crashes just the same. Pretty sure its a memory leak gone bad, as after about 500 images the whole process seems to slow.

You know, Filemaker is a really, really, great app/database, but it really needs some love in the way of how it deals with images. I was going to make my own cocoa app for this, but filemaker is *almost* all the way there; super handy for searching, flagging, exporting pdf contact sheets, etc..

Anyhow - its frustrating to be so close. More frustrating that Filemaker 10 continues to be broken.

Apple, this is my close friend Filemaker (and your distant cousin!); You should do a power lunch together soon. :o

[Fenton]

Have you considered use JPEG or PNG instead of PICT? They should be considerably smaller, and look about the same, for limited screen viewing anyway. I am surprised that calling Insert Picture with even large PICTS would have a memory leak, but I've not done it with 3000 large PICTs, so maybe so.

Since you're linking to the original files (which are likely huge), I would think also creating a screen-size JPEG or PNG file for linking via reference might be a good idea. Since it sounds like you have the knowledge to do that via AppleScript. Not so much fun if you're constantly editing the original image however, and need the sized one to match it. But that could also be AppleScripted to run from the FileMaker record on demand.

[xyz3]

If I remember right, the only image format I can set a container to using applescript is pict. I know the internal filemaker scripts somehow support other formats, but I think they read and store as pict. (?) I will look into it again, but I think that is still how it stands.

The database is for an offsite photo editor, so the needs are pretty specialized, and they often need to open the raw file to check the resolution and focus for print quality. The previews in multiple sizes work for most, then they view the raw, hence the link to the raw file.

[Fenton]

Yes, the internal FileMaker Insert step support several others, notably JPEG and PNG. Yes, you cannot set the field directly with raw code that way, but since you're having problems with that, you might want to try the more modern methods.

I did not question the need for the link to the raw file, in order to open it. But there is no reason to view it within a FileMaker container field. I was just saying that a link (reference only) to a screen sized file, JPEG or PNG would be better for such a view; since you were saying that was slow. It would likely be faster and better to just open the raw file with a graphics app than view it in FileMaker, where you couldn't work on it anyway.

[xyz3]

Yes, the internal FileMaker Insert step support several others, notably JPEG and PNG. Yes, you cannot set the field directly with raw code that way, but since you're having problems with that, you might want to try the more modern methods.

Shouldn't Filemaker open the scripting to the more modern methods?

I did not question the need for the link to the raw file, in order to open it. But there is no reason to view it within a FileMaker container field. I was just saying that a link (reference only) to a screen sized file, JPEG or PNG would be better for such a view; since you were saying that was slow. It would likely be faster and better to just open the raw file with a graphics app than view it in FileMaker, where you couldn't work on it anyway.

The links were pointed to the jpegs that were created from the raws. I noticed it being slower than when the previews were inserted directly into the database. The images also all reside on a firewire 800 drive when used by production, though for my tests I also noticed the links being slower when stored locally.

Basically, this is an applescript forum, and while I am looking for workarounds, I also feel applescript support could/should be better. :o