[AccessD] "Faked" replication

Hi Marty:

That is definitely an area that I will have to get into...seems to have some
great possiblities. Could you recommend a good book that would get a person
up to speed quickly?

The one problem that I see it the issue with not transferring the data but
with the application, at each end, being smart enough to know whether to
data being received, is an deletion, addition or and update and how to
handle it.

Jim

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of MartyConnelly
Sent: Friday, December 19, 2003 8:59 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] "Faked" replication


How about using XML updategrams via FTP and sqlxml or ado into an msde
It is not difficult to handle jpg's or binary data inside xml; there is
a method internal to ms xml
that handles this.
The updategram xml file would  look like this:

<?xml version="1.0" encoding="UTF-8" ?>
<ROOT xmlns:updg="urn:schemas-microsoft-com:xml-updategram">
  <updg:sync>
    <updg:before>
    </updg:before>
    <updg:after>
      <Employees LastName="Madsen" FirstName="Claus" Title="Developer"
TitleOfCourtesy="Mr." BirthDate="12-10-1973" HireDate="01-01-2000"/>
 </updg:after>
    </updg:sync>
</ROOT>


Jim Lawrence (AccessD) wrote:

>Hi Gustav:
>
>Sounds interesting, that might be the even be the best solution. :-)
>Maybe we should compare notes one days.
>
>As I said before I have not discovered a simple, 'out of the can' solution
>to synchronization and every site had a whole new set of problems. Never
did
>enough to become a master but a fairly good cobbler...
>
>Jim
>
>-----Original Message-----
>From: accessd-bounces at databaseadvisors.com
>[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Gustav Brock
>Sent: Friday, December 19, 2003 11:47 AM
>To: Access Developers discussion and problem solving
>Subject: Re: [AccessD] "Faked" replication
>
>
>Hi Jim
>
>Quite an impressive list Jim! Of all those I have only dealt with
>simple FTP transfer.
>
>However you miss one async method: e-mail.
>Neither is this bulletproof (but close) nor NESS (except on paper).
>I've used that method for one project which has run and does run very
>reliably.
>This is for collecting statistics from remote resources once every
>month so traffic is low of course. But through 2½ years it hasn't
>failed a single time.
>
>/gustav
>
>
>
>
>>There is a lot of ways to get remote synchronization. I have been able to
>>
>>
>do
>
>
>>it with a lot of sites using various methods, for over fifteen years. DSZ
>>and GSZ scripts with DOS to DOS, Kermit scripts PC to Mainframe, Novell
>>server and CoSession script-files, Xenix and Dos LAN stations, Linux to
>>Linux to LAN, PCAnywhere to LAN, Access Synchronization, Windows to VB to
>>telnet to Server, PC to VPN to PC, SQL to SQL sync, LAN to web to web to
>>LAN, TermServer software and hardware etc..... The one rule with remote
>>access is that nothing is bullet-proof but at least it can be made
>>reliable... and that is where the programmer comes in.
>>
>>
>
>
>
>>The only issue is down to 'How soon' and How much' for there is NESS (No
>>Easy Simple Solution).
>>
>>
>
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com
>
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com
>
>
>

--
Marty Connelly
Victoria, B.C.
Canada



_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com