× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Tue, 2015-01-13 at 15:48 +1300, PaultinNZ wrote:
Hi Evan,

Yep, we are using the vendor approved refresh/resynch but I was fishing
around to see if there was another way.

With the table containing +/- 348m records and the delta only being 700
records it would be faster by a long way just applying the delta.

I'm not sure if its possible... but if the file is journalled is it
possible to just apply the journal(s) from system A to system B since
the last save/restore?

The fact you do a restore to refresh seems to suggest that either the
file is not changed on sysB or if it is the changes can be ignored as
they are wiped out during the restore.

Now if the file is journalled on sysA it might be possible to access
that journal and then to apply a subset of the journals via a program...
so that only say add or add/delete is applied if its the existence of
the data record that is important.

If the existing records change and the changed data is important to both
sysA and sysB and assuming the changed records can be identified, as
well as added/deleted, and depending no how current that data needs to
be; it might be possible to write a program on sysA that can trawl the
file, create a "batch" file and then copy just the batch across and
apply it via another program. While it might still involve a
save/restore/apply process it would have the advantage of not requiring
locked or exclusive access to the file. I guess it all depends on how
its set up and how it fits within the data to day running.

Jon


This isn't an problem at the moment only an idea.

But thanks to you and the others that have replied so far.

Cheers
Paul

On 13 January 2015 at 07:50, Evan Harris <auctionitis@xxxxxxxxx> wrote:

Hi Paul

My concern with your suggestion is that the updates on the target ("SysB")
may not - i.e. probably wouldn't - get the same relative record number as
the source ("SysA"). I can't remember off hand if you can insert by RRN but
if you can I guess you need to make sure you do this. My gut feel is this
is not possible and if you have Re-Use Deleted Records turned on this will
be even more problematic.

You may end up with a situation where the file is logically the same but
physically different - i.e. same data, but in different positions. I
suspect the replication software will still see this as out of synch.

If it was me I would bite the bullet and refresh/re-synch the file in a
vendor approved way.

On Mon, Jan 12, 2015 at 12:25 PM, PaultinNZ <paultormey@xxxxxxxxx> wrote:

I have a table that is replicated from SysA to SysB.

The table on SysB is not in sync with the origin table on SysA - there
are
records missing on SysB.

The normal procedure for getting these back in sync would be to take a
backup from SysA, move that to SysB and restore the table. Tape would be
the transfer medium. Once the transfer is done and the table restore
mirroring from SysA to SysB would be restarted.

Or use our Mirror software and force a refresh which can take some time.

I wanted to look at using a SQL insert using remote DB directory entries.
However, it seems that even with the updates till TR7 I can only open 1
database simultaneously.

Anyone know of a way to open the "TableCommon" in both Database1 and
Database2 simultaneously and preferrably from a session on the i.

I'm trying to do a select with except to get back rows that do not exist
in
SysB.

Look forward to any suggestions.

Paul
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




--

Regards
Evan Harris
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




--
Paul Tormey
3/11 Bramley Drive
Farm Cove
Auckland
2012
New Zealand
Home: 09 576 3415 or 0064 9 576 3415
Mobile: 021 810615 or 0064 21810615



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.