SQL Server merge replication with Accpac 5.4

[mcollins175]

Hi.

I have a problem where we are running two seperate instances of Accpac 5.4 as the link between locations is via satellite. At the moment we are doing a nightly database dump - transfer over satellite -and load locally for reporting. We now need to be able to post information at both locations ( not at the same time as we were advised about incremental numbering etc) but keep the databases in sync with just changes being replicated. This is all through the Accpac 5.4 Front End. Connection to a central Database is not viable over satelite.

Does the Accpac Data base tables allow for the extra replication column ID (SQL Server 2005) in order to facilitate this or will it fall over?

Thanks

 

[ettienne]

No, it will bomb out big time.

 

[ettienne]

Use terminal server or Citrix and run one database, this will still use less bandwidth than a dump/load or replication will.

 

[ettienne]

I need to expand my first reply now that I am fully awake.
You can replicate Accpac databases, that does not cause any problems and I have clients who do that for backup purposes.
If the one site is only going to do reports and inquiries then it will work fine, since they are not added records to the database.
However having entries done at both sites is courting disaster, you could create duplicate records in the Accpac database, in which case things will start to go wrong.

 

[mcollins175]

Thanks Ettienne

Just a further question then on Citrix or Terminal server. Does it need to have a continuous data connection to the database or does it hold the batch locally and write it to the database afterwards.
I work on the server remotely and screen refreshes can sometimes take upwards of a minute (bad weather not withstanding)

We are aware of the possibility of conflicts so there will be clear work shedules for the two locations. Do your clients running replication use one way transactional or merge replication.

 

[ettienne]

On the first question: neither. No data is transmitted to the remote desktop, it's simply screen and keystrokes being sent and received.
My clients never work on the replicated database, it is purely for backup and disaster recovery. I have one client who does a dump and then a load of the database at a remote site, this is purely for reports and inquiries. They cannot replicate because they are not using MS SQL. They do capture some batches and then export this and send it back to the main office where it is imported.
Replication is always one way, merge replication is not going to work. No matter how clear the work schedules are, someone is going to screw up and then you have a mess to deal with. Do you really want to contend with sorting out a mess somewhere in the remote African bush? I've been there and done that with mining operations in Central Africa, just about everything was moved off site where the servers can be better managed and controlled. One particular incident comes to mind when an enterprising user loaded Doom and some virus onto the main server, but I degress...

 

[mcollins175]

Thanks for the clarification

I am runing the merge replication in my test arena now and no problems for the accpac front end however I do take your advice and the "everything will work fine until you introduce a user" philosophy is a strong on.

I will see about the batch export as that may be a way to get around the large nightly data dumps.

we are suppling the copper belt so you know more then most the challenges we are facing.

 

[ettienne]

Some of my favorite drinking holes are in Kitwe & Ndola