Need Help - "Search Center Database"

[UtahViper]

Hello All, First off I am new at doing any of this. I volunteer with a group called U-Search. What we do is set up, organize, and run search centers for missing kids in Utah. The goup is in need of a good database system to help operations. I have started looking at filemaker 8.5 and it seems it will do what I need. First let me describe the basics that we need in the database.

1. Volunteer Registration: Tracks all volunteer Information. Name, Address, Phone Numbers, Skills, Picture, Status, Duties. Volunteers come in 2 basic types, Staff and Searchers.

2. Search Planning: Database of search information. Search Maps, Address, Search types, Notes, Map ID. Some of this will be Pre-Planned, Most planning will be dynamic and on-site.

3. Dispatch, Incident Command: Current status of Volunteers and Searches. Assign available volunteers to specific search. Create a team Roster for each search. Print roster and search information. Record and report statistics on searches, volunteers and operations.

The first two I have the basic idea of how to do, I have created small example of each but still need assistence. The third part is where I am most lost. I know that we need to relate the Vollunteer and Planning together. I am not completely sure how to do this. I would like to know if there are any systems already made that may complete these functions. I would like any advice, Ideas, or other help in getting this system ready to run. U-Search is a Non-Profit and the core staff are all Volunteers, Including myself. I hope to get a system ready just in case there is another kidnapped or missing child in Utah that needs to be found and brought home. You help is greatly apreciated.

Damon

U-Search, Operations

Edited September 23, 2006 by Guest

[Genx]

What is more important here is that you work out how a relational database works. Before you start trying to build this, search google for some free whitepapers on "relational database structure" or relational databases. It will speed up your creation 10 fold.

Way to make people feel guilty .

[aldipalo]

You'll find some good training material here:

http://www.foundationdbs.com/downloads.html

Also, would suggest you upload your development file so others can look at it and take it apart.

You are doing a very worthwhile thing and I'm sure you will get lots of assistance.

HTH

AL

[UtahViper]

Well I have started getting some reading done. I also have got a start on the database. I still have alot to do and changes to make. I have included a striped down version of the 3 files I have made. these have none of the graphics added. I am sure that my Tables need to be reworked. i have ran through it all, there is 1 problem with the script for "Find Status". I used a standard find script and only changed the "Go To Layout" and now it locks yp and you have to click continue. Other then that please have a good run through on it and let me know how I can improve what I am doing.

The next phase of the project is to bring "Contact" and "Map" data together to be dispatched as Teams with Specific assignmenys. any on with a good idea how to do this would be aprecitaed.

scs.zip

[aldipalo]

Just took a quick look see, haven't really gotten in to it. However, first question, why do you have three databases? It is easier to work with one database a put all your tables in the one db. If you are looking at a separation model, usually, one builds that when they are very proficient and have a VERY LARGE database.

I'll try to look at it over the rest of this week, but, Let's hope some more experienced eyes pitch in as well.

Al

[Ender]

i have ran through it all, there is 1 problem with the script for "Find Status". I used a standard find script and only changed the "Go To Layout" and now it locks yp and you have to click continue.

There are different ways to do this type of thing. One simple modification would be to change the button option to "Resume Script" and add a Halt Script to the end of the Find Status script.

Personally, I think the user interface is better if you use a dedicated layout for performing Finds. This way you can show only the fields that you want to allow searches on, and you can add visual cues to make it clear that the layout is for Finds and not data entry. In this case, the scripting is a little different. The Find script simply pauses, and the button on the Find screen simply Resumes the script.

I think getting your Maps and Contacts together will be a little more complicated than what you seem to have planned for so far. I'd suggest you spend some time pondering the attached ER Diagram to give you a sense of what will likely be needed.

Edited September 25, 2006 by Guest

[UtahViper]

I have somewhat thought over the idea of treating it like a Invocing system. In this case though the Searchers would be the "Items" and the maps would be the Invoice "owner" I hope that makes sense. i still need to look at how to make it work but i think the concept is sound.

[Ender]

A one-to-many relationship, like an Invoice-LineItems situation, is very common in database structures. But that one relationship does not a solution make. That may be all you've thought about so far, but try to think about what the next request for the database would be. "Hey that's great, but can you make it dance too?"

Now it may be I've included things that will never come up, and I may have missed some entities. Not knowing your business, I can only guess about the exact requirements. But based on your description, what you had in your files, and what I would imagine such a solution would need, I came up with that ER Diagram.

For example, that model allows for the same Map grid to be used in multiple Searches. I imagined this might be useful if a grid needs to be searched more than once, and the search teams may be different. I've also guessed that you might have Contacts volunteer for a particular Missing Person search, but some might volunteer for searches of different Missing Persons. The Person-Contact join table allows for this flexibility.