Setting up network for split DB

[Yatiman Idara]

Hi everyone,

I am almost in the deployment stage of my DB.

I have a split DB with a persistent connection to the BE.

Now I have to set up the network to house this DB.

I was thinking of setting up a server/client network where the BE will rest in the server and the FEs will be placed in individual desktops.

Is this the best course of action?

Do I need a server? If so then what type would be best?

As I am new to networking can you guys please provide clear suggestions that I can google and hopefully utilize

 

[RuralGuy]

In addition to Uncle Gizmo's warning you should know that Access is a peer-to-peer system. No server involved.

 

[Yatiman Idara]

In addition to Uncle Gizmo's warning you should know that Access is a peer-to-peer system. No server involved.

So how would I then go about setting up a network to deploy my DB?

Thanks

 

[RuralGuy]

The best link I know for multi-user split databases:
http://www.accessmvp.com/TWickerath/articles/multiuser.htm

 

[The_Doc_Man]

Rural guy - I'm going to disagree slightly and on a technicality. It is true that SMB protocols support peer-to-peer traffic but the architecture of Access FE/BE is NOT peer-to-peer. That is, if I happened to be running on the central machine that is the host of the BE file and it happened to have Access on it, I still couldn't change data in someone else's FE file through the copy of Access on the machine hosting the BE file - whereas the FE copy of Access mapped to the BE (by drive-letter + path or by UNC mapping) certainly CAN change the information in the BE file.

Yatiman, you don't need a server (as in, say, Windows Server 2008 or 2012) to host the BE file, but you need to designate a specific system as your file-share repository. In this sense, the BE holder is a file server - even though that "server" might just be another Windows xxxx Premium (i.e. end-user) version. This machine will normally be the one that has to be up at any time that your FE file users needd to connect, and it is also the one that needs better security and a good backup methodology.

Do you need a "true" server? No. Do you need something that will act like a server? Yes.

RG - the technicality is not in name but in functionality. In order to be operationally secure, you need to treat the BE holder like it is a server if you want your environment to be stable. Otherwise, ... stuff happens. Calling it a peer-to-peer setup is maybe a tiny bit misleading.

 

[RuralGuy]

@Doc - I couldn't agree more. I stand corrected. Your words are *always* better than mine anyway!

 

[The_Doc_Man]

Yatiman - back to the problem at hand...

Your "server" (regardless of what kind of system it actually is) must be managed via backups, cleanups, and a regular regimen of safety features. Treat it very carefully because you are (a) putting many eggs in one basket and (b) making that basket the focus of a lot of attention.

You also need to protect it by perhaps setting up restrictive permissions so that your users would not directly log in on that system via a "local" account. If you have a site domain controller set up, I would advise setting up a domain-wide group identifier for your users. Then set the permissions such that members of the group have Modify access to the folder in question. Then assure that your users are members of that group AND have to log in through the domain.

This doesn't really stop someone from hosing your database to tears, but in a domain environment, it really makes it easy to point fingers after the fact based on domain login records. On the other hand, if you have regular backups, THAT will at least reduce the number of tears you cry when the database DOES get hosed.

 

[Simon_MT]

I would always go for a Client / Server without reservation. Try to keep the database in a smallish volume and as high up the Directory structure as you can. If you want multi-user a Client Server is a good solution if you want remote Access then using a Terminal Server can use the same structure.

Actually there is an instance where Wireless I believe can be used if you are Accessing a Terminal Server with a long Session Timeout. I have certainly been able to switch PCs with the same user without disrupting the original session.

Simon

 

[The_Doc_Man]

As Simon says, (where have I heard that before?) you can implement connections that are wireless, but you must very carefully assure that ALL repeat ALL action queries are done via optimistic locking and that ALL select queries (where plausible) do what they do with no locking at all. The implausible cases are when you have to step through recordsets with the intent of changing things on-the-fly. The plausible cases are when you run reports, since you weren't planning to update anything and would therefore not be doing something that would require a lock.

Regardless of your wireless connection time-outs, pessimistic locking = asking for trouble.