Looking for a good way to offer remote access.

[ChipC]

I've got a fairly complex database going, and I now need to make it usable by some offices that are offsite. This is something I've never done before, and I' not entirely clear on what my options are. The options I do know of are:

Replication.
I could just make a replica for each satellite office, and have them e-mail the replicas to me periodically to be merged with the master version. This might work okay for our needs, but we've got more than 20 satellite offices to deal with. My assumption is that I'd have to spend an inordinate portion of my time merging these databases and checking for merging errors, not to mention the hassle of actually getting the other offices to send me their databases.

Data Access Pages.
As I understand them, Data Access Pages can only duplicate simple, bound forms. I don't see any way to run my queries or to produce reports, and without those capabilities my database is useless.

Is there an option I'm missing? Is there something I can do to make one of these options more viable? Please help!

Chip

[puppydogbuddy]

there are other options: this link will get you started... i am gone for the weekend. I or another Expert will get back to you.

http://members.shaw.ca/AlbertKallal/Articles/split/index.htm

[maxamis4]

Well I looked at his link and it has a good explaination concerning networking and splitting a database. This is good practice for any database. However in your case my friend I would start thinking web database. This is probably the best way, but definately not the easiest. http://www.asp101.com will get you started on examples to link your data to your database. The other alternative is always VPN and using a network path to connect the database. Beware the slowness and the possibility that the database could be corrupted due to latency or disconnection.

Good luck!

[puppydogbuddy]

As Maximis mentioned, Microsoft provides two migration paths for an Access multiuser application to scale to as it grows. One path is the .Net path if your application is going to operate over the internet. The other path is the MSDE/ SQL Server path if the application is not going to involve the internet. With either path, Microsoft offers a VPN (Terminal Services) platform if you do not want to maintain your own server.

The question of when to move up along the migratory path depends on whether your workload has outgrown your present platform.

http://www.aadconsulting.com/aadtips.html
Access Databases on a Network

Generally, after an Access application has been split into Front-End and Back-End components, it can handle up to 50 concurrent users over a network without any trouble, but there are other issues to consider:

Does the server and do the client PCs have enough grunt?
Is LAN broadband sufficient?
How big is the database?
How is it split?
Keep administrative functions in the back-end
Locate all lookup tables and those with static data in the front-end
How is the back-end queried? Are you using ODBC, JET, DAO, or ADO etc...?
Don't open tables across the network. Locate back-end queries in the back-end
Open queries with the minimum recordset required. Use Snapshots where possible
What RecordLocking regime is in place ...optimistic, pessimistic... ?
Your level of experience with and knowledge of Client/Server databases. The Chapter Building Client/Server Applications in the Access documentation, Building Applications with Microsoft Access, is a good starting point.
Visual Basic and Access Development


http://msdn2.microsoft.com/en-us/library/ms811092.aspx

Table 1 shows a list of enterprise requirements and tells how each of the data engines handles these requirements. If your application has any of the needs listed in the left column (or might have any of these needs in the future), you will want to consider implementing MSDE as an alternative to Jet.