ASP.NET, SQL Server, WPF, C#, VB.NET

I have a split DB with the FE residing on user's desktops and linking 
 
to the BE located on a server.  The FE shortcut targets a specific 
 
security workgroup file located in the same place as the BE.  So far 
 
this has remained fairly local, geographically and therefore server 
 
connection speed has not been an issue at all. 
 
Now.. The database is being migrated to a national server (located 
 
offsite) and will be accessed by twice as many people.  When I move the 
 
BE to the new server and link up, the speed is very slow.  I have 
 
deployed some methods of keep the .ldb file active and tried to 
 
maximize the efficiency of the db, but the bottleneck appears to be the 
 
network. 
 
I have only sparse knowledge of sync and replication.  I was hoping 
 
someone could provide som good insight as to options for this type of 
 
situation. 
 
I was thinking of possible duplicating the BE and place one down here 
 
on a local server and one on the national server, which would be 
 
considered local to all of the other users.  I would then need to 
 
sychronize and both BEs to update the data that has been inputted. 
 
There shouldn't be any design changes to the BE, but with expanding 
 
users further customization may be needed and therefore methods for 
 
having a master BE local to me that would sync the data but override 
 
and update any design or structural changes. 
 
Thoughts? 
 
Thanks in advance....

"Matt" <martino165@hotmail.com> wrote in 
 
news:1154634231.370157.223990@s13g2000cwa.googlegroups.com: 
 
Windows Terminal Server is the answer to your problems. The remote 
 
users would then be running the app on a server that is local to the 
 
data. This is much easier to set up and maintain than replication. I 
 
have been doing replication since 1997 and since WTS now comes 
 
builtin on Windows Server (from Server 2000 on), I'm using it 
 
instead of replication to support multiple office sites. I only use 
 
replication to support disconnected laptop users. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/

On 3 Aug 2006 12:43:51 -0700, "Matt" <martino165@hotmail.com> wrote: 
 
David Fenton has replied with an option about using Terminal Server. 
 
If you are able to implement TS, I think that is a good way to go. 
 
However, if TS is not an option for you for whatever reason, there are 
 
some pointers about replication that you should bear in mind: 
 
- only replicate the BE. The FE should be distributed via some other 
 
means. See http://www.granite.ab.ca/access/autofe.htm 
 
- purchase the Office Developer's Kit (or whatever it is called. For 
 
A2003 this is the Access Developers Edition contained within Visual 
 
Studio Tools for Office.) so that you have Replication Manager. RM is 
 
a software for managing Indirect Synchronizations between locations. 
 
Indirect Sync is the only reliable method for synchronizing over a 
 
WAN. Do NOT attempt to sync using direct synchronization (which you 
 
would be forced to do if you did not have the RM software). See 
 
http://www.granite.ab.ca/access/developereditionfaq.htm 
 
- establish a "replica farm" at each end of the sync. These farms 
 
consist of several replicas managed by the same synchronizer, and they 
 
provide a "self-repair" mechanism that improves the reliability of 
 
cross-WAN syncs. See www.trigeminal.com for additional information 
 
about farms. 
 
- establish a "production replica" at each end for you users to 
 
interact with on an everyday basis. The production replica is sync'd 
 
periodically with the replica farm. Keeping the users out of the 
 
replica farm for their production work improves reliability. 
 
- isolate your Design Master from the automatic synchronizations. You 
 
should sync your DM periodically to keep it from going "stale" (the 
 
default period is 1000 days, so it's not a huge effort), or whenever 
 
you make a schema change. 
 
- never move a replica from its designated location except by using 
 
Replication Manager. Moving a replica, say via Windows Explorer, will 
 
result in the creation of a dead replica that will eventually clog 
 
your system. 
 
Hope this helps 
 
-- 
 
jackmacMACdonald@telusTELUS.net 
 
remove uppercase letters for true email 
 
http://www.geocities.com/jacksonmacd/ for info on MS Access security

jacksonmacd <jackMACmacdo0nald@telus.net> wrote in 
 
news:qh85d2tmen612q9hkh41t6qjccet14ioq4@4ax.com: 
 
While your advice is good, I really don't think that there's any 
 
reason why with two fixed central offices why WTS should not be easy 
 
to implement. Even if there isn't a server in place that can be used 
 
as a Terminal Server, setting up a new one is not going to be more 
 
expensive than implementing indirect replication, and WTS is going 
 
to be more reliable and provide real-time data. 
 
Since the OP mentioned having already tried running the app across 
 
their WAN connection, it's clear that the WAN connection is 
 
sufficient to support WTS. 
 
To me, it's absolutely a no-brainer. 
 
It's especially so for someone with no replication experience. I've 
 
been doing this for almost 10 years and *I* would never choose 
 
replication in those circumstances, even though I have all the 
 
expertise necessary to implement it. 
 
-- 
 
David W. Fenton                  http://www.dfenton.com/ 
 
usenet at dfenton dot com    http://www.dfenton.com/DFA/