Omnis data transfer
gzieman54 at gmail.com
Sat Jun 18 08:01:14 EDT 2016
I've been watching this thread for a few days and I thought I'd throw my
two cents in.
I have been using Omnis since 1995 and I have *never* relied on the RSN as
the primary index because of exactly the sort of situation that has been
described in this thread. I have always created extra unique indexes that
are assigned with a method during record creation, such as a customer ID,
Invoice number, etc. These are the indexes that then link back to the
parent, grandparent (or however deep you need to go). So for an Invoice
Line, the creation method would also record which Customer ID and Invoice
number that line belongs to.
This requires a little extra thought when you're setting up a database at
the outset, the creation of extra methods, and changing the insert methods
to always call the methods to assign the extra indexes. I use a file which
I usually name as a Master File to keep track of what the next Customer ID,
Invoice Number, etc. is going to be and increment it each time one is used.
I still use the RSNs internally for some things, but I never rely on it as
a parent-child link.
It seems like extra work and that you're building a lot of unnecessary
indexes — until the first time you have to export and re-import your data.
If you've done the extra (procedurally assigned) indexes, the fact that all
of the RSNs may change does not matter at all.
On Fri, Jun 17, 2016 at 9:58 PM, Mischa <mischa at omnislab.com> wrote:
> I've once written a tool that takes care of all file-connects when
> transferring the data. The basic idea is quite simple - it ensures that
> each record has the same RSN in the new df1 as it had before. The tricky
> thing however is the export order, first all parents must be exported, then
> all children, sub-children and so on, otherwise the connection gets lost,
> when the child does not find the matching parent.
More information about the omnisdev-en