The QA db application which I translated consisted of three databases in QA. I thought the reconcile feature was very nice, and would help me perform this translation/migration while minimizing user impact.

To make a long story short, I translated the three databases from QA to Seasme,  and then combined them into one application. It took me a few weeks to design the interface and work out the code changes that were necessary. During this time, the user continued to update QA.

When I completed the work, I needed the new data from QA to use in the Sesame application I designed. So, I retranslated the QA databases into a new Sesame application, and then tried to apply my design to this application, figuring I would get the new forms I had designed, combined with my old data. It did not work at all. I'm guessing this is by design, but would like to confirm it. Can you please explain?

I ended up copying the data over through the intra-application inter-database copy feature, but I am wondering if I had to do this. There weren't enough details about the reconcile feature for me to figure out the internals of it in the user's manual and online.

Lastly, what do you recommend in the future, when doing translation projects like this? Do I need to rely on the copy feature always? When multiple databases are involved?

After taking a look at the source code, I think I have an idea as to what is going on. When Sesame creates an application it tags pertinent parts of the design with a unique ID. The Q&A translator usually is creating a new application and so tags the elements, forms, reports, etc, ... with new ID numbers.

The Reconciler uses the ID number to determine if an element, form, etc, ... is derived from current design. So when you translated from Q&A originally, Sesame assigned the ID numbers. SDesigner retained these ID numbers to use when reconciling any application that was (or would be) built using that translated application as a starting point. But when you retranslated the Q&A databases, you essentially started a new (and as far as Sesame can tell) unrelated application, with new and different ID numbers.

So, yes, it is by design. But the intent of the design is not so much to prevent what you are doing (which we really want to encourage) but to provide some way for Sesame to tell if elements in an application design are related.

In terms of recommendation, many customers translating from Q&A will translate, merge databases, and then remove all but a few test records from the resulting Sesame application. They will then redesign as needed. Then, when it is time to switch over to Sesame, do an ASCII export out of Q&A and an ASCII import into Sesame for each of the databases in Sesame.

One of advantages of this approach is that while designing, you are working on much smaller files and your ongoing Q&A users are not disrupted.

Remember to save a copy of the .dsr and .ddt files without data records, and use those as your masters for further changes and updates.