I receive about 20 folders a day, containing 10-20 jpg images each. I keep them as sub folders in a master folder. I would like to keep that structure, since other applications make use of them, too.

Right now, I copy all new folders to the master folder and then do a scripted import, by first deleting all records in my FM table, then doing a folder import with only referencing each picture file. I suprassed the 50.000 picture mark and needless to say, the script runs for about 20 min. I tried just 'adding' the new ones instead of deleting and reimporting, but what takes the time is the scanning of the folders and not the actual import.

There has to be a better (read - faster) way?

Thanks

I receive about 20 folders a day, containing 10-20 jpg images each. I keep them as sub folders in a master folder. I would like to keep that structure, since other applications make use of them, too.

Right now, I copy all new folders to the master folder and then do a scripted import, by first deleting all records in my FM table, then doing a folder import with only referencing each picture file. I suprassed the 50.000 picture mark and needless to say, the script runs for about 20 min. I tried just 'adding' the new ones instead of deleting and reimporting, but what takes the time is the scanning of the folders and not the actual import.

There has to be a better (read - faster) way?

Thanks

I noticed you asked this same question about six weeks ago.

What is the current import scripting look like?

What is the method of finding the file references?

Could the file go into an IncomingFiles folder first. The files could be imported and moved by scripting triggered from FileMaker. Only 10-20 items at a time could be imported or 200-400 items a day. That would improve your speed.

I have merged the two topic. Normally we delete the duplicates, but since this one had a response to it, I [color:red]merged it this time.

Do not double post. It isn't necessary, and it cause a lot of extra work to those who reply. If you want additional reasons, write to me using the Private Topic Feature of the Forum.

Lee

First off - sorry for the double post - it will not happen again.

This has been off my desk for a while, but now it is rearing its ugly head again.

I looked at your suggestion and cannot find a way to address it.

My images table is really simple. Just a reference number and the container field and the path as imported by FM.

The problem that i have is that I cannot influence the internal reference that FM creates to that image it puts into the container field. So yes, i could put a few images at a time in a temporary folder and import them, but when i move those later, the container fields are blank again, because FM does not update that reference. I have not found a way to manipulate the reference that FM creates in any way other than a fresh import.

Any suggestions?

thanks

Edited April 1, 200817 yr by Guest

How is fileMaker supposed to keep track of files moved outside of its system?

I know it cannot do that - I guess it came across wrong. By stating the obvious, I was actually trying to see, if I was missing the obvious in the previous poster's suggestion, which talked about moving the images after import. It really just boils down to the question, if the reference that FM creates to those images can be manipulated via a script, or if there is any other way to approach it?

Thanks

OK - I found out how to get the reference out of the container field by using the GetAsText(container) - so now the question remains, how do i get a manipulated string back in, or for that matter into another container field?

Edited April 1, 200817 yr by Guest

If you create a calculation field which produces the correct FileMaker syntax path to the image, with the result Container (not Text), then FileMaker will show that image, just as if you had used Insert. In other words, kind of reverse the process.

If you've already imported images, [x] As reference only, then you have the path. It is the last value of GetAsText ( container inserted into ). You can use this (possibly) to produce a slightly different calculation path, which will be valid if the original image has been moved.

You can also "pre" make the path, and wait for the image files to get there.

that's exactly what I needed - thanks

the calculation result is 'container' was my missing link.