Article View: borland.public.vdbase.data.sql
Article #1578MS SQL SERVER and replication
From: Dennis Levy / Maxine Levy
Date: Wed, 22 Oct 1997 00:00
Date: Wed, 22 Oct 1997 00:00
73 lines
3741 bytes
3741 bytes
We are doing some RAD programming and have a VDB program
presently running in 4 sites throughout the US successfully.
We are on a mission from God to bring the program up in MS-SQL
immediately and are attempting to bring up our program made up
of more than 50 files and our databases (more than 60) within
the month.
At the same time we are working with "replication" which
includes "publishing" and "subscribing." Does anyone have
good experience doing this, especially with VDB. Our
reading indicates possible stumbling blocks with the subscribing
articles (tables) going into a 'read only' mode. Our planned
architecture includes three layers:
----------------------------------------------
SQL Database
----------------------------------------------
COMPLETE DBASE DATABASE AT EACH LOCATION
----------------------------------------------
OUR COMPILED PROGRAM
----------------------------------------------
This architecture will be repeated at each location.
We want to use publishing to replicate our changes
and additions to the database as often as practical
and as close to real time as possible. We do not as of
yet know the frequency of publication but hope that it
can be as soon as each few minutes.
My plan is that one location would be considered
the "primary location." this means that although all locations
will have the complete databases (in dbase and SQL), the primary
location will first be the subscriber to all of the secondary
locations which will send down their changes and additions.
Then after all of the replications are received, the primary
location will then publish (transmit) the sum of all the articles
received
from all locations back to each location sans the records originally
transmitted from the original publishing location to avoid
duplicate records being sent back to the original publishing location.
An example of this is that:
Secondary location 1 publishes data 'aa' and 'bb' to primary
subscribing location 4. Secondary location 2 publishes data
'cc' and 'dd' to primary location 4. Secondary location 3
sends 'ee' and 'ff' to primary location 4. Primary location 4
also creates data 'gg.' After primary location 4 receives all this
data, it then publishes all the data it has received or created
(i.e. 'aa' through 'gg' back to each location which becomes the
subscriber sans the data that was originally published from that
location to avoid having duplicate records at each location).
One of the neat things about this arrangement is that if primary
location 4 crashes or is destroyed, any of the other locations
can become the primary location. Also each location can take over
the duties of any other location if there is a work overload
at any of the locations, creating a "virtual office" concept.
Some issues are:
1)Indications are that the subscribing files automatically
become 'read only. Is this true. What are the work arounds?
2)Text files (memo fields) cannot be replicated but only
brought to the other locations through synchronization.
Is this true? Does synchronization require the system to
be brought down to do?
We would appreciate any thoughts or dialog on these concepts.
Technical Details
Message-ID:
<344EE1AF.24B4@ix.netcom.com>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailShow Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: ff5a1,859531562956d25,start X-Google-Attributes: gidff5a1,public From: Dennis Levy / Maxine Levy <lcibiz@ix.netcom.com> Subject: MS SQL SERVER and replication Date: 1997/10/22 Message-ID: <344EE1AF.24B4@ix.netcom.com> X-Deja-AN: 282608209 Reply-To: lcibiz@ix.netcom.com Organization: LCI COMPUTERS SOFTWARE ENTERPRISES Newsgroups: borland.public.vdbase.data.sql