|
John,
In Q&A you have (for simplicity's sake) two flat databases. Lets call them database A and database B. The records in database B, are "related" as children to the records in database A. In Q&A, that "relationship" is caused by an XLookup statements in Q&A Basic that find some of the records in database B, while you are looking at a single record in database A. This is done (usually) by field matching. In other words, there is a field in A that has a value that matches a particular field in B. In Q&A this doesn't really move the record from B to under the record in A - it can just retrieve information from the record in B - because Q&A is entirely flat.
In Sesame, you can have subform and sub-databases. So you translate A and B into Sesame - you end up with two flat databases and two flat forms. You can then merge B into A, creating a single application file containing both A and B, both still flat. So you create a subform field on A and tell it to contain records from B.
All well and good, and from what I've read so far on this thread, this is where you are now. But there still has to be a way for the A form to know which B records should appear under which A records. In Sesame there are two ways for this to happen: "natural linking" and "relational linking".
In natural linking sub-records appear under a parent record because that is where they were created in the first place - there is no need for matching "key" fields or anything else - it got made here, so here it stays. Natural linking can't immediately help you because your records have already been created elsewhere.
In relational linking (an option available when you created the subform field on the parent form) you tell Sesame which field on the parent and which field on the child need to match for a record from B to appear under a record in A. Sesame then dynamically finds and displays all of the correct B records each time you view an A record. It does this by running through the B database looking for those B records that have the same value as the specified field in the current A record.
You probably don't want to use relational linking permanently because it is slower and does require maintenance. But you can set up your system to use it once - to find the right subrecords, then using the ASCII export save that relationship. Then you can rebuild your subform field with natural linking and import the data back in.
1. Translate A.
2. Translate B.
3. Load A into Sesame.
4. Merge B into A.
5. In SDesigner, Create a subform field on A's form that contains B's form.
6. Tell SDesigner that you want it to be a relational subform and tell SDesigner which fields need to match (one field on the parent form and one field on the subform).
7. In runtime, using the export spec, export all of the fields on the parent and child to a file.
8. In Runtime delete the records from the child form and from the parent form, using mass delete.
9. In Sdesigner remove the subform field from the parent form. Then, recreate it just like you made it before, but this time select "natural linking" (the default), instead of relational.
10. In runtime, do an ASCII import from the file you created when doing the export (step 7).
When step 10 is completed, you will have the correct child records under the correct parent - naturally linked.
I know that I am being more conceptual than specific, but once you understand what is going on, the specific steps get a lot easier. The most important thing is understanding that you need to tell Sesame some way to determine which subrecords appear under which parent. In you case that may be a "lot number" field that needs to match on the parent and the child.
|
Pages: 1 [2] 3 4 
Send Topic 
Print
A big project (Read 21717 times)
