Wow, filemaker 2.1, that's a flat file database, no portals. No alternatives but to use repeating fields. The only option I can think of for that version would be to define several repeating fields instead of just one long repeating field.
Using "newer" versions of Filemaker (Filemaker 6 is still pretty ancient), greatly reduced the need for repeating fields. In most case, you use a portal that displays a table of related records instead.
I thought of that and it might work in other circumstances but not in this case. The problem here is that the content in the repeating fields is being looked up from another longer repeating field in another file.
I add new information weekly to the records in the other main file with it's the repeating field. At the end of the month I use a macro to look up only the most recent month's information and transfer it to the repeating field in the document that I fax out. I have about 50 of these documents that I fax, one for each individual client, that go to different referring agencies. Each month I update the documents to show the latest months information. I've now been asked by an outside agency to reformat the document so it shows information for not only the current month, but the prior months as well. That's why I need 50 repeating fields displayed instead of 10 or less.
With your suggested solution of separate repeating fields on separate lines, I would need to be able to selectively look up the first months content for the first line, the second months content for the second line, etc., from the repeating field in the main file. Unfortunately, I tried that, and the program won't allow me to look-up selective portions of the other repeating field. It will allow me to limit how many of the repeating fields are showing in the documents I fax out, but I can't just lookup and display portions 11-20 for a separate repeating field on line 2, or 21-30 for a separate repeating field on line 3. If I could, your solution would work. Thanks. Any other suggestions are welcome.
I work in social services where we are continually underfunded. I paid for a used Mac Quadra 650 with a two monitor display (landscape on one, portrait on the other) and the Filemaker Pro 2.1 out of my own pocket in 2001. It was 6 years old then, relatively cheap, and has allowed me to do what the agency's Windows system couldn't. It cut my paperwork time in half. Even 2 years ago the head of our information services department looked at what I put together with the idea of migrating it to their updated Windows system. But she said they couldn't recreate it on their system with the same functionality much less the same ease of operation. So until now, it's been a simple yet sophisticated, user friendly oldie-but-goodie that someone like me with little technical know how could put together. It has performed like a champ for 9 years.
I hear you. I understand your limitations, but...
You are frantically trying to soup up a Model T to get it able to compete in the Indy 500. No surprise that you'd have trouble. Is there a way to get what you want out of Filemaker 2.1? Possibly, but very, very few people are available who even have a copy that old, let alone know all it's ends and outs. My first version was 2.5--if my memory is correct. I haven't had a copy that old on a computer in decades and can only go by memory to make the suggestions that I have to date.
They've upgraded Filemaker through the years precisely so users like you can do more things with their databases, but you have to acquire the updates to do so.
If you are a nonprofit organization, Filemaker Inc. has a "gift in kind" program that donates free copies of their software to qualifying organizations. If you fit that description, you could search their website for more info. (I researched that option for a organization that I'm volunteering with, but as they are a church, they don't qualify.)
Yes, it's a model T. But if there isn't a work-around, we may just let the outside agency know that we can't provide everything they want. If we upgrade software, then we also have to upgrade hardware that can handle it. I'm running Mac OS 7.5.3 on a pre-power Mac. (So yes, dinosaurs still do roam the earth and have met our needs up to this point very well.) Also, we'd have to migrate all our records going back 9 years to the new software. I'm not sure how difficult that would be (and they are in the repeating fields format).
However, I don't think I'm asking for an Indy 500 special, really. It strikes me as odd that the program wasn't written in that version or subsequent versions to allow a repeating field to display on more than one line. I'm guessing that writing that operation into the code would not have been rocket science, even 14 years ago. But I figure this question is at least worth asking before I look at other options. That's for the heads-up regarding grants to non-profits. Yes, we'd qualify.
I've never worked with version 2. Isn't there some calculation you can perform to split the repeating field into 5 parts, like:
GetRepetition ( FieldR ; 1 ) & "<tab>" & GetRepetition ( FieldR ; 2 ) & "<tab>" & GetRepetition ( FieldR ; 3 ) ...
I'm not familiar with 2.1 but could you not have five instances of the same repeating field, each with 10 repetitions? Instance 1 shows repetitions 1-10, instance 2 shows repetitions 11-20 etc. Then all five instances can be stacked vertically and labeled if necessary.
Excuse me if this feature is not available in 2.1.
I should be clear that I'm speaking of displaying (and therefore printing) this field. This is a layout technique and has nothing to do with changing your data structure. And I agree with David's post below. Get a PowerPC at least and see if your organization can pick up a free, or nearly free, version of FM Pro.
I have run across info on the web that describes the process for transferring the contents of repeating fields into other formatting. I will check it out and see if it can be of help in my situation. I think it's designed for transferring the contents of a repeating field into a table, but it may have some applicability here, too. If it would allow me to take select parts of the repeating field in the main file and transfer them to separate repeating fields on each line of the secondary document, then it could help. This is a flat database, before Filemaker became a relational database and I don't know how much of that procedure can be utilized i this version. I'll check it out and let you know how it goes.
A 400Mhz G4 sells for $75 in Seattle.
Your non-profit is that strapped for cash?
Clients give them to me to clean and dispose.
The shipping would be close to the cost.
(I have a IIci Mac that still runs, so I understand)
There is a non-profit non-profit helper here, One Northwest. Nothing like that in your area?
Like I say, I'll see if there's a work-around first. If that doesn't pan out, I'll look at other options. Thanks.
Thanks Rick, for the idea. I think I'm replying to your post out of sequence. Unfortunately the lookup function in FMP 2.1 only allows me to transfer all the data from the repeating field in the main file to the repeating fields in the secondary documents that I fax out. If I had 5 vertically stacked columns of 10 horizontal repeating fields, the best I can do is display the same items 5 times: 1-10, 1-10,1-10, etc. FMP 2.1 doesn't allow me to select portions of the repeating field in the main file for transfer, just the whole thing. What it does allow me to do is limit the number that are displayed in the secondary document that I fax. When I limit it to 10, then 1-10 only will show. Separate additional repeating fields in the secondary document would only show the same info: 1-10.
Thanks to one and all who contributed questions and suggestions in response to my query. Between Super Contributor pointing me in the right direction with scripts, Rick Whitelaw's ideas about a series of different repeating fields on different lines looking up parts of the information, along with desperation, determination, divine inspiration, and ingenuity on my end, I've got a work-around. I guess my model T Filemaker Pro 2 will continue to work for some years more. I was unfamiliar with the Scriptmaker function on FMP. I never used it because the early Quickeys application I used did such a marvelous job of recording short and simple and long, complicated sequences of operations, that I didn't need to use Scriptmaker...until now (remember the straight loo-up function couldn't selectively import data from another repeating field in another document. A Script can.) It will be a lot slower to put together all the pieces of the script rather than record and play back a sequence, but I've done a preliminary test that shows it will work. FMP 2.0 doesn't have as many options for scripting actions as later versions but it's still enough to get the job done. But the script is only half the story. To me it looks like the scripting is limited to the database I'm currently using. Since I need to import data from the primary database, I still use the look-up function first. I created a repeating field in the secondary document that looks up and displays the latest 50 dates from the primary document. I created another repeating field that looks up and displays latest 50 for the status (present or absent). The problem, if you recall, was that so many repeats lay out horizontally and run off the page, then don't display on the secondary document when faxed or printed. I resized the new field down to as small as possible (6pt font) and so tiny that it can display only one character of type, not the complete data from the other field. There are no borders on the fields. All 50 of the repeats must display, I found for the complete process to work. What I get are two horizontal strings of characters so small that they can not be read. They run horizontally for two-thirds the width of the page, so there's no running off the page. I place them at the top and bottom of the document such that it looks like nothing more than an unusual decorative border. It's barely noticeable and not something that draws attention. With the data transferred to those fields on the secondary document, I then created additional repeating fields of regular readable size such that there are 5 separate lines with 10 repeats each for both date and status information. With Scriptmaker I've been able to "relookup" discrete information from the too-small-to-be-read field of 50 and display it on the appropriate line at a readable size: the first repeating field of 10 for "date" displays the latest dates 1-10, the second line / repeating field of 10 displays 11-20, etc, etc, until all five lines of ten are filled with the appropriate data. It's time consuming to put the script together (much faster using Quickeys to record sequences) but once it's done, it will be a breeze to update the secondary document monthly, fax a copy and print a copy for the required paper chart. I should be able to record a Quickeys sequence that does both parts in one action: the initial look-up and then plays the Script. The only glitch (and it's one we can live with) is that after every transfer of data from each repeat of the too-small-field to the line of 10 repeats, the script stops with a dialogue box that says, "There are no fields that look up values based on the field 'Too Small'. It does that after each transfer from each repeat. All we have to do is press the return key and keep it pressed down and the script continues until it is complete. So, I'm happy that I don't have to try and migrate everything to a newer system and software. Some dinosaurs refuse to die. My only concern is that since I have 50 separate secondary documents with different names, I will need to duplicate the script for each and every document, and every time I add a new one. Since each secondary document is used for a year, it's still worth it, but since all these secondary documents are layed out the same (duplicates) I wish there was a single script that could run on any and all of them. On a side note, I downloaded a demo of a newer version of Quickeys (3.1.1 to run on my Mac OS 10.3.9 at home) and found that they totally lost sight of the concept of being "user friendly". It was so non-intuitive, frustrating, and hard to work with. It didn't even seem like the same application. I was really dreading a huge learning curve if I needed it as part of an upgraded system. They have even newer versions, but I did give them the feedback they requested on the old unsupported QK 3.1.1. Thanks again, especially to Super Contributor and Rick Whitelaw.
especially to Super Contributor
"comment" is his handle.
Super contributer is just the forum title.
I sort of like the ring of "SuperContributor". There will be comic books available shortly and a major film later in the year.
Yeah comic book movies are totally in. :p