3 Replies Latest reply on Aug 12, 2009 8:34 AM by ninja

    CASE MANAGEMENT with FileMaker Pro



      CASE MANAGEMENT with FileMaker Pro


      I have created several d/bases using FileMaker Pro v.6.00 to track file details of complaints management. The file exists as a hardcopy and as an electronic folder. 

      I am wondering if there is a forum member who has used FileMaker Pro to track records of this or a similar type.




        • 1. Re: CASE MANAGEMENT with FileMaker Pro

          Howdy straycat,

          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.

          • 2. Re: CASE MANAGEMENT with FileMaker Pro

            Hi Ninja


            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...



            • 3. Re: CASE MANAGEMENT with FileMaker Pro

              Howdy straycat,


              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

              Hit enter


              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...