retention/expired replica "bigpond" <calafradulistic[ at ]hotmail.com> 28.07.2006 11:31:15 HI All This has probably been asked a million times but I can't find any archives with ansers so please be patient on that. I have a replica that has expired. Need to get the new data out of it. Is it possible to recover/re-activate the database at all? I have coverted it to a design master but it won;t synch with the previous deisgn master - no common point to start the synchronisation. The files are not on the original computer/folder. That can be tried latter but is it worth the bother or is is it a lost cause? TIA

Re: retention/expired replica "David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> 28.07.2006 16:09:44 "bigpond" <calafradulistic[ at ]hotmail.com> wrote in news:7Amyg.2352$rP1.2271[ at ]news-server.bigpond.net.au: [Quoted Text] > I have a replica that has expired. Need to get the new data out of > it. Is it possible to recover/re-activate the database at all? I > have coverted it to a design master but it won;t synch with the > previous deisgn master - no common point to start the > synchronisation. The files are not on the original > computer/folder. That can be tried latter but is it worth the > bother or is is it a lost cause? Once it's expired you can't get the data into your replica set with synchronization. You have to do manual APPEND and UPDATE queries. This requires either that your data have date stamps on it that show when records were updated, or that you figure out how the generation numbers work and use that to determine the updated data in the replica. I don't quite understand how an actively-used replica could ever expire. If replication is needed, synchronization should happen more often than every 3 years, don't you think? -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: retention/expired replica "KB" <calafradulistic[ at ]hotmail.com> 30.07.2006 05:53:07 HI I was afraid that the answer you gave was what it would be - no hope. The replica was a DAO/JRO creation with a default of 60 days. While I was going to make some changes to this I hadn't gotten to it yet. Someone went on holidays and of course the 60 disappeared rather quickly before they returned to work on the database again. Copy/append is problematical due to subordinate linked tables that use values in primary fields from the main tables. Once appended the number increments and of course the subordinate records no longer match. I would have to undertake a complex and lengthy task to re-match all of the records. Ah well they will just have to re-enter it by hand, bugger. Thanks KB "David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message news:Xns980E7BB85E515f99a49ed1d0c49c5bbb2[ at ]127.0.0.1... [Quoted Text] > "bigpond" <calafradulistic[ at ]hotmail.com> wrote in > news:7Amyg.2352$rP1.2271[ at ]news-server.bigpond.net.au: > >> I have a replica that has expired. Need to get the new data out of >> it. Is it possible to recover/re-activate the database at all? I >> have coverted it to a design master but it won;t synch with the >> previous deisgn master - no common point to start the >> synchronisation. The files are not on the original >> computer/folder. That can be tried latter but is it worth the >> bother or is is it a lost cause? > > Once it's expired you can't get the data into your replica set with > synchronization. > > You have to do manual APPEND and UPDATE queries. This requires > either that your data have date stamps on it that show when records > were updated, or that you figure out how the generation numbers work > and use that to determine the updated data in the replica. > > I don't quite understand how an actively-used replica could ever > expire. If replication is needed, synchronization should happen more > often than every 3 years, don't you think? > > -- > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/

Re: retention/expired replica "RB" <robert[ at ]brokerforce.com.NoSpam> 04.08.2006 15:42:14 Good reason for 60 day retention period is that when you go longer, the number of potential conflicts piles up and no one remembers which version should have been the winner after 60 days. Resolutions can be componded exponentially by relationships. RB "KB" <calafradulistic[ at ]hotmail.com> wrote in message news:7PXyg.3243$rP1.2563[ at ]news-server.bigpond.net.au... [Quoted Text] > HI > > I was afraid that the answer you gave was what it would be - no hope. The > replica was a DAO/JRO creation with a default of 60 days. While I was > going to make some changes to this I hadn't gotten to it yet. Someone went > on holidays and of course the 60 disappeared rather quickly before they > returned to work on the database again. > > Copy/append is problematical due to subordinate linked tables that use > values in primary fields from the main tables. Once appended the number > increments and of course the subordinate records no longer match. I would > have to undertake a complex and lengthy task to re-match all of the > records. > > Ah well they will just have to re-enter it by hand, bugger. > > Thanks > > KB > > "David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message > news:Xns980E7BB85E515f99a49ed1d0c49c5bbb2[ at ]127.0.0.1... >> "bigpond" <calafradulistic[ at ]hotmail.com> wrote in >> news:7Amyg.2352$rP1.2271[ at ]news-server.bigpond.net.au: >> >>> I have a replica that has expired. Need to get the new data out of >>> it. Is it possible to recover/re-activate the database at all? I >>> have coverted it to a design master but it won;t synch with the >>> previous deisgn master - no common point to start the >>> synchronisation. The files are not on the original >>> computer/folder. That can be tried latter but is it worth the >>> bother or is is it a lost cause? >> >> Once it's expired you can't get the data into your replica set with >> synchronization. >> >> You have to do manual APPEND and UPDATE queries. This requires >> either that your data have date stamps on it that show when records >> were updated, or that you figure out how the generation numbers work >> and use that to determine the updated data in the replica. >> >> I don't quite understand how an actively-used replica could ever >> expire. If replication is needed, synchronization should happen more >> often than every 3 years, don't you think? >> >> -- >> David W. Fenton http://www.dfenton.com/ >> usenet at dfenton dot com http://www.dfenton.com/DFA/ > >

Re: retention/expired replica "David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> 04.08.2006 19:33:18 "RB" <robert[ at ]brokerforce.com.NoSpam> wrote in news:Og$HUx9tGHA.4872[ at ]TK2MSFTNGP02.phx.gbl: [Quoted Text] > Good reason for 60 day retention period is that when you go > longer, the number of potential conflicts piles up and no one > remembers which version should have been the winner after 60 days. > Resolutions can be componded exponentially by relationships. That's a horrid reason for setting short retention period. Anyone who doesn't bother to resolve conflicts shouldn't be using replication. Unresolved conflicts mean the data in your replicas may or may not be identical, and that's corruption, as far as I'm concerned. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/