Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 7891 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

I'm new to Filemaker, and ANY help would be greatly appreciated, Police Officer by trade, and I've been assigned to upgrade our in-house computer system.

I've created two files, #1, an arrest pedigree, #2, a mugshot file. I've created a relationship between the two, by lookup, whereby making an entry into the pedigree file pulls in the mugshots, jpeg's, via matching case #'s. Works great, providing the mugshot exists. Here's my problem.

Most times, the pedigree is created prior to the mugshots being entered. What I'm attempting to do is create a startup script that will update the pedigrees once the mugshots exist. I'm having a difficult time getting the relookup script to function. The picture fields in both files are container fields, hopefully that is correct. Again, any help much appreciated.

Posted

Don't use a lookup, use a calculation field -- a calc field can return a container. Also (technobabble time), a relationship isn't a lookup, it's a relationship between two files based on a field in each file; a lookup is something done within a field to look up data from another field.

Better yet, just import the mugshot directly into a container in the main file.

You really should have two files, but they should be one for people and one for arrests. That way, if a person has been arrested before, you can see the record in a portal on his record in the People file. Also, if you take a mugshot every time someone's arrested, you can keep those in the Arrests file.

OK, one more thing: You actually keep the JPEGs in a separate folder and import them into the FMP file -- I suggest checking the "Store only a reference..." button.

Posted

As long as you don't put me in charge of law enforcement, we'll be ok! wink.gif

There are a bunch of things to watch out for here.

1) You don't want to store photos in two files and use a lookup between them. You should display the related photo record from the mugshot file in the arrest file using a relationship.

2) You probably don't want to store the photos at all, but import only a reference to the photos. The actual photos should be stored on a server volume accessible to all the users of the FM files. If you do this, an update will not be necessary, as long as a related record exists in the photo file. Imports to the photo file can be automated with a plug-in such as Troi File.

If you store photos in a FM file, you can soon exceed the maximum 2GB size for a FM file.

3) An alternative, is to store a small thumbnail in the photo file. This can work as long as the maximum number of photos x the thumnail size will never come close to the 2 GB limit. For a larger view, show the container with the the stored reference to the actual photo.

We've done a large photo storage system for a client. If uses these two approaches and also make thumbnails on the fly using Troi File. We have about 300,000 photos on 120 GB of storage. This would not be possible if we imported the acutal photos, instead of the references.

-bd

Posted

I'd like to thank both of you for your time and trouble responding to my post, I really appreciate it. I can see there are a lot of considerations involved here, nothing worthwhile is ever simple. If I could just get a little help with the calculation :??

Posted

just include a portal to your mugshot file in your pedigree file containg the picture field (mugshot::image)

make sure you checked "allow creation of records" in your reletaion setup.

This way, you can import a photo (by reference or direct) into the related file without leaving the pedigree file.

On other layouts, I would either use a calculation (image= mugshot::image) or disable entry into this field to prevent accidential modification of the image.

Posted

Taking a little advice from each of you, thanks again, here's what I did:

Created a folder on our server where the JPEG's alone will be stored, each with a unique picture identifier.

Modified the pedigree and mug shot files adding a field containing the above picture identifier.

Created a relationship between the two files,(I finally figured that out), whereby when the mug shots are imported from the server folder into the mug shot file, the pedigree containing the unique I.D. is updated from a reference to the mug shot file. AND it's WORKING !!!

Thank you one and all !

Posted

Just some thoughts...

You might want a scrollable portal to give the ability to show multiple photos that match your "suspect" - giving that you may have more than one photo of them, and that appearances change. So your portal could be sorted by decreasing date of photo, so that the most recent photo would display first, then the user could scroll down in the portal to see how the suspect looked in previous appearances.

You might also want to start some cross-referencing of your photos (using multi-line key fields) so that you could, for example, click on a button next to the photo to show a list of cases in which this suspect has been involved.

Posted

Good thoughts. I'm now creating a Master Name Index file based on a series of related files containing various personal information. A big part of my problem is that we are required to maintain a hard copy of each record for a period of seven years. Each pedigree record must be a seperate record assigned by a unique case number. Therefore, an individual may be arrested several times, have several mug shots and each incidence will have a different case number. By creating this Master Name file, all that info for each individual will be indexed.

This topic is 7891 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.