deleting unneeded file references is a standard part of the conversion process. It does not indicate a problem with your files. Filemaker 3, 4, 5, 6 all tended to have very chaotic/redundant external file references. The conversion process attempts to eliminate those not actually used as well as some duplicate entries but you'll likely find that the external data source references are still pretty messy with a lot of redundancy.
I suggest a more detailed description of this:
each time resulting in portals that are not showing complete entries from the related repeating text field.
What relationships are used for these portals? What do you mean by a "repeating text field"? A field with repetitions? Or are you referring to the multiple rows of related records in the portal?
Can you provide a sample of the data or upload a screen shot or two to show us what you have?
With more detail, we can suggest ways to correct the problem.
I created a FP db to prove I can do it (for one reason) and thinking that it might serve as a tool for memory drills (preventing memory loss), using movies as subject matter.. So, I created the first layout with fields for actors, directors, writers, etc. This actually started in ClarsWorks on a Mac IIsi. I copy and paste the information from a website called IMDb (Internet Movie Database). This all started about 10 years ago, and I'm not sure it's helping keep me sharp in general because remembering the terminolgy associated with Filemaker - which I can see is absolutely critical here - might be a sign of my age.
My db has just two related files, one for actors and one for directors. Discovering that a portal will give you exact results was the great joy because, before that, if I attempted to use the Find command in the original text field for an actor, it would yield an inaccurate found set, showing people with the same last name and the same first name, as well as the exact name. The portal, however was/is bombproof. 100% reliable. When I discovered that, I decided I had made something useful, adding a new record for each movie I see - about 4,000 since setting it up. The related files allow me to see a list of all the movies I have seen featuring any given actor or director. Memory, I beleive is a matter of review, review, review. This gives me the list to review. When I see another movie (and create a new record in what I call The Master File) , the fields that I designated to show, with their labels positioned above, will be brought into the next available lowest line in the portal. Every time. That is in version 3.0. When I do these conversions to v11, the portals are no longer accurate. I know this, because I had created in the v3.0 related files a Number Field (sortable) where I keep a count. It survived the conversion OK. That is a count of how many portal rows are filled. After converting, some are right, most are off by one, some are off by many. A total mess.
The matched fields are called Actor Full Name and Director Full Name for the two respective related files, both also occuring in the master. The term Repeating, I just noticed, is no longer mentioned in v11 next to the field type, as it was in 3.0. Now, a number in parentheses appears instead. The cast list for some movies is rediculously long these days. The field Actor Full Name in the master has 335 repetitions. You can thank Julie Taymor's "Across the Universe" for that.
The support guys in Kentucky said a clone of my db could help. I'm kind of a novice at screenshots and uploading in general, but with 3 days left, I will strive to do whatever it takes. Even if the world will see all warts. My layouts are very unprofessional. But , they work well enough for me.
My db has just two related files, one for actors and one for directors....adding a new record for each movie
That makes three files, Movies, actors, and directors?
I don't think a clone will be as useful as inspecting the actual data.
I suspect that the issue lies with using text fields with names as the match fields in your relationships. Asside from the issues this can create for two people with the same name and one person with two different spellings of their name (or that change their name). Older verisions of Filemaker match values in text fields differently than today's versions. Older versions ignore any punctuations characters for example so in FileMaker 3,
John E Smith would match to a record with John E. Smith in the related file's match field. In versions since FileMaker 7, they will not match until you delete that period. I'd inspect the data of your text fields you are using for match fields in your relationships to see if such small differences in the text are keeping the values from matching.
Repeating fields are still possible in Filemaker 11 and we still call them repeating fields. What's not clear to me is how you are using repeating fields, especially given the fact that you are also using portals. Normally, a portal is used in place of a repeating field as it is much more flexible to use that a repeating field.
Note that auto-entered serial numbers make for a better option for linking your records than names as it avoids all of the issues mentioned here and yet you can still select records by name when you link them by an ID number.
Yes, Three files in all. Movies (I keep wanting to call it the master file), Actors, Directors.
I don't know how to imagine databases that don't match names. Football coach (players), hospitals (patients) businesses (customers). Surely, that can't be it, can it? But, I am the first to admit I'm not able to think like our software coders.
I just did a test regarding the punctuation issue, I think. In related file Directors (in converted fp7 version), there were zero entries in the portal for Alfred Hitchcock! I did a Find in the field Directors in the master for Alfred Hitchcock and the found set was exact. Here, the MatchFields goes Directors (master) to Director Full Name (related). I looked for a director with an initial for midle name. William A. Wellman's portal in fp7 Directors file is missing only 2 rows. However, the found set in master actually returned one more movie than my count field indicated. The Director field is also text, repeating, indexed, same as Actor Full Name. One is layed out vertically, the other horizontally. The movie that didn't make it to Wellman's portal had him listed in the third repetition spot. I opened the original fp3.0 version and the same thing happened. So much for it being bombproof!! That could explain one missing portal row in fp7, but not both. And why is Hitchcock's portal totally empty? no punctuation issues there.
I also looked into the manual that came with Filemaker 3.0 for info about repeating fields. It says they are used for Find requests, calculating values and sorting. When the db is bringing data from related files across, is that the same as a Find?
If I can figure out how to send the actual file, I am assuming you would want to see the FMP 3.0 version, And. if I forget to say this later, thanks.
You appear to have this relationship between Movies and Directors:
Movies::Directors = Directors::Director Full Name
To see if there are issues with the text in these fields, you have to compare the data in Directors for a given Director to the data in Director Full Name for the same director. Since these are repeating fields, this get's very complicated. These fields should not be repeating fields. With repeating fields, if any value in any repetition of Directors matches any repetition of Director Full Name, the records are related and the related record should appear in your portal.
Example: If the values in [brackets] represent values in different repetitions of the same field,
Directors::Director Full Name : [apple][orange][Kiwi]
will match to all three of the following Movies records:
Movies::Directors : [kiwi][rutabaga][squash]
Movies::Directors : [squash][apple][carrot]
Movies::Directors : [Beet][Beans][orange]
This will make unraveling this quite a challenge. I suspect that this was done to enable a "many to many" relationship, there are much less confusing ways to do this by using a Join Table instead of the repeating field, but save that thought for after you get your converted file copies working.
You can upload screen shots of your database (such as the Manage | Database | Relationships window) by using the "Upload an image" controls below the "Post A Answer" box.
You can upload your database files to a file sharing site such as Drop Box and then you can post the down load link to it here. Since you have multiple files, you can make it simpler if you compress them into a zip archive before uploading them to the share site. Please DO NOT share clones of your file. I think inspecting the actual data involved will be a key necessity here. And sharing the .Fmp12 copies should be fine for that purpose.
I'm working on getting the image of Manage, Database, Relationships to the site using the Upload an image option below. I have browsed to the file that contains the 6 files (the 3 FP3 originals and the 3 fp7 converted files), selected the fp7 file of the master - now called Dave's Movies after all that wrong-tree barking about file references - and when I hit open, it just jumps back to this Post a Answer box. I think this might send the full file. I think you may just want a screenshot of the relationship diagram, however. I need to learn how to do that.
To capture a screen shot depends on your operating system. On windows, you hold down the Alt button and press Print Screen, then open a graphics program such as windows paint and paste the image. Save it in one of the formats listed below such as png and you have a file you can now upload using "upload an Image".
So. That was not so hard. Thanks.
Yesterday, I discovered another instance where the portal for a director did not have enough filled portal lines. This came as a shock to think, after all these years, those portals are not as accurate as I had thought. So, repeating fields have become the subject du jour. My old manual does not cover Join Tables, but I'm going to Help file in Trial 11 now.
Also, the full file may be more enlightening. Investigating DropBox.