My problem on exporting/importing has been orphan records all along...I hadn't realized that there were many repairs entered in our Q&A database that were not items on our inventory....nothing to link to in the parent, so these "kids" are wandering aimlessly about. I had tons of fun exporting, importing and even designing my application from the ground up again...testing a few things and trying different design, navigation and layout element schemes. The more I work with Sesame, as with anything, the more familiar I become and the easier it is to spot my goof-ups.
I have two versions of our application saved-thanks to Ben and Ray and, of course Hammer-many thanks btw

-one relationally linked, one naturally linked. It's a matter of whether we can do without those orphans or put them on our inventory to make things right. I'll discuss that with the boss on Monday...he's not too keen on us keeping track of inventory items for other departments since we have no control over them. I can see his point for reasons I won't give here.
Running my app-naturally linked with the orphan records out of play (gone) is noticeably faster-relationally linked runs fine and doesn't take as long to search as it did when files were stored on another computer.
After going through my export/import problems, I learned a few things about how records had been kept over the years here. Repairs were done on items that were NOT on our inventory...no linking to the parent as a result; items transferred to other locations and serial numbers not acurately entered (a digit off here and there)...I plan on rectifying that problem with (I think) pick lists from inventory to make sure the serial number enetered into repair records is RIGHT

...glutton for punishment here.
Another thing that hit me is that we routinely transfer equipment to different sites. That's fine when working with the parent, but repair records exist for the location these items were assigned to PRIOR to being moved to new locations. When they move and come back to us for repair, the new location is entered in the repair database.
For example, let's say I have 25 floor burnishers on inventory, one is assigned to Timothy Leary High School in our parent database, the others are assigned to different locations. It cost $900 when it was purchased. We've repaired it 12 times and have each repair entered in our child database. The operator has been abusing this machine (buffing the asphalt parking lot at 2 AM), so my boss decides to transfer it to someone who wants it and will care for it properly. We re-assign it to Utopia Middle School.
After a few years we have 6 more repair records enetered for this machine listed under "Utopia Middle School". We would have to run our search based on the serial number to get an accurate result for all repairs done to this machine at both locations. If our search for repairs is inaccurate (we only get a result for repairs done since it was at Utopia Middle School), we would be looking at only $300 in repairs and not counting the $700 in repairs while it was assigned to it's former location.
We scrap and replace equipment occasionally, based on the amount of money we have invested in repairs and how cost effective it is to continue to repair, parts availabilty, etc., so we do need to track each and every repair as accurately as possible. Add to that the repairs we do for equipment that is NOT on our inventory and we can easily get a few orphans lining up through the years...it's one of those things that happens when working with flat databases for a decade or so and then switching to a true relational database program. Makes me really appraciate good record keeping practices after finding things that should have been done properly from the beginning

...of course, that's one reason I like this place so much. People have a nak for wanting to do things right.