Welcome to the forum.
I've used FMP to track technical service requests...sorta the same structure I'm guessing, but friendlier than complaints.
What are you interested in?
I'm on PC/XP, FMP7-9.
Thank you for replying to my post. I am using a networked PC/XP FileMakerPro v6.00. I am the administrator for the various d/bases I have created and which are used at various times by my work colleagues. I have created all the d/bases as flat files - mainly because I am not sure about the 'relationship' aspect of using FileMaker. I have two d/bases for the same subject matter but different time range.
1. DISCIPLINE - up to 2007
2. DISCIPLINE - 2008-2009
I want to be able to perform a FIND that would return records from both d/bases. I have tried creating a relationship between the two files using a field called ID NUMBER which exists in both d/bases, but do not get what I expect which is that I would have a found set of records from both d/bases. I'm probably going about it too simply. I do not have a separate FIND layout and have not SCRIPTED the FIND in any way.
However I think I need to re-think the entire architecture of my d/bases. I have Steven Schwartz's book "FileMaker Pro 6 Bible" and have some ideas about what I might need to do, but it's pretty difficult when there is no-one else to provide input and knowledge.
Here are some examples of FIELDS I have created for the DISCIPLINE d/base. Some have associated VALUE-LISTS.
LAST NAME GIVEN NAMES ID NUMBER EMPLOYMENT CATEGORY (drop down value-list) SCHOOL~VPS LOCATION PRINCIPAL~VPS MANAGER REGION (drop down value-list) FILE TYPE -radio button-Discipline-Local FILE OPEN FILE CLOSE
and so on.
I don't know how to capture an image of the layout so you could see it.
I also understand this question with its associated issues may be more than you wish to deal with and that's fine...
I've toyed between two different approaches, flat-file vs. related action items to a job.
Strengths of flat file: User can read all items more conveniently in a single field (a big one) since the individual entries may be as much as a page of typing. User just adds on to the bottom with a blank line separator and the pertinent date. Find can be done for any word in the field for looking back later at "didn't we do this before?". I wouldn't want to do this for a million records, but the dbase will never get that big so I'm not worried about it.
Strengths of related items (Job record with related records in another table for the actions taken per case): User doesn't have to remember to date it...auto timestamp takes care of it. Also, when you search for something, you only find the pertinent entry instead of having to scroll through pages of typing for each found record.
Honestly, I'm still torn between them but the users tend to prefer the flat file (they don't care if they forget to date entries...management does).
Your find would likely not work the way you describe it. If your dbases are unrelated, you'd have to do the find in each dbase. To relate them, each record would need to be tagged with an ID, and each record would be related to other records in the other table/dbase to records tagged with the same ID. If your two dbases have different ID#'s, then the records won't know who to relate to. Even if they have the same ID#, Field1 in Dbase1 is a different field than Field1 in dbase2.
Depending on how well you've related them already...try this manually:
Create a searchable field from Dbase 2 on a layout from dbase1.
Enter find mode
type in your criteria into the dbase1 field
select "Add new request" from the requests dropdown
type the criteria into the dbase2 field
If your found set is larger now than it was when only doing the find in dbase1, then you're on the right track and we'll work down the road further. You can get what you want, but I'd actually suggest another approach altogether...
Put a field in your main "Complaint" table for the year. Instead of moving your records out to another database, leave them all together and work inside a found set of Table::Year = Year( Get(CurrentDate)). Now when you want to do a find, you'll look across all years at once. If you only want 2006 stuff, do your find for the normal criteria AND Table::Year = 2006. This will give you a lot more flexibility moving forward.
Let me know if this makes sense or if I talked past you...