The company has a desktop application powered by SQL Server from the head office that is dependent on an internet connection to our remote sites. Usually when we move to a new site there is a good internet connection 5Mb+
We have a new site that is connected by a very slow satellite internet connection in the middle of nowhere. As you can expect our application is really suffering.
Unfortunately we cannot just install a SQL Server box locally to power the application on site.
The application database has been designed (by a now non-existent 3rd party) that all separate contracts live in the same database and share common tables.
We have 3 projects running all writing to the one database, updates are about 500MB a week during active projects for all 3 projects.
Also there is a project status website powered from the head office SQL Server. Management would not be happy if this new remote site showed no progress for the duration so we need to factor in getting data back to head office to power the website, again all from the one database.
It is outside the scope of this question to start re-designing the database. (hopefully that’s a project for later in the year)
Is it possible to install and operate a local SQL Server / application server for the remote site clients that can update back to the main head office SQL Server as and when it either has an internet connection and / or enough bandwidth to do so?
How would one achieve this using SQL Server given the super slow Internet access?
What kind of timeframes would be involved to setup and test?
As usual other than money for a desktop box to act as a local server and a SQL Server 2008 Standard licence the budget is £0
EDIT: Added the tracert to show network latency from the remote site, unfortunately we are not the main contractor at this site and have little say in the provisioning of the comms.
1 1 ms 1 ms 1 ms 192.168.2.1 2 544 ms 552 ms 564 ms 10.190.9.206 3 543 ms 701 ms 655 ms 188.8.131.52 4 1461 ms 542 ms 641 ms 184.108.40.206 5 658 ms 564 ms 555 ms ae1-143-ycr2.mcr.cw.net [220.127.116.11] 6 601 ms 617 ms 588 ms so-3-3-0-dcr1.lsw.cw.net [18.104.22.168] 7 577 ms 568 ms 564 ms xe-7-2-0-xcr1.lsw.cw.net [22.214.171.124] 8 580 ms 564 ms 656 ms xe-0-1-0-xcr1.lnd.cw.net [126.96.36.199] 9 566 ms 565 ms 570 ms ge-3-3-0.mpr1.lhr3.uk.above.net [188.8.131.52] 10 605 ms 594 ms 569 ms ge-5-1-0.mpr1.lhr3.uk.above.net [184.108.40.206] 11 574 ms 569 ms 573 ms so-0-0-0.mpr1.ams1.nl.above.net [220.127.116.11] 12 570 ms 573 ms 570 ms xe-0-0-0.er1.ams1.nl.above.net [18.104.22.168] 13 635 ms 598 ms 581 ms 22.214.171.124 14 588 ms 582 ms 582 ms glfd-bb-1b-ae0-0.network.virginmedia.net [126.96.36.199] 15 599 ms 618 ms 596 ms manc-bb-1a-ae3-0.network.virginmedia.net [188.8.131.52] 16 592 ms 609 ms 576 ms manc-core-2a-ae0-0.network.virginmedia.net [184.108.40.206] 17 * * 592 ms manc-lam-4-tenge11.network.virginmedia.net [220.127.116.11] 18 583 ms 596 ms 636 ms m229-mp4.cvx2-c.man.dial.ntli.net [18.104.22.168] 19 * * * Request timed out.