With transactional replication, the serverports table gets updated within
seconds of the master DB recieving an accounting record. It's been working
beautifully for me for about 2 weeks now. We're about to do 2 more replicas
for other locations.
Neither the CPU on the main SQL server, or the bandwidth for either site
took a noticable hit. It's working great.
As for setting up the replication, I just turned to my SQL book (and the
books online) for assistance. Once I realized that the version on my
workstation was different than the version on the server, it only took about
5 minutes to set the thing up and get it working.
** -----Original Message-----
** From: email@example.com
** [mailto:firstname.lastname@example.org]On Behalf Of Greg Lowthian
** Sent: Monday, February 21, 2000 4:20 PM
** To: email@example.com
** Subject: RE: [RadiusNT] Redundancy
** Can you go into transactional replication a little deeper.
** What I have is one SQL server in NV and the other in CA. The NV server is
** the one that billing is being done from.
** The problem is when the connection in NV goes down (Sprint) the
** RadiusNT in
** CA can't get to the SQL for authentication. The SQL server in CA
** has a copy
** of the DB but I don't want to do a full transfer every night.
** > I would not recommend doing a nightly transfer unless you're short on
** > bandwidth, or don't care about concurrency control. A transactional
** > replication would be much better for this. I'm doing it now, and it's
** > actually very light on the CPU and Bandwidth.
** For more information about this list (including removal) go to:
For more information about this list (including removal) go to: