Split DB (Jet) - Will read only access still corrupt over WiFi?

[JMongi]

A question, if the access to the database is strictly read only, would the mechanism that corrupts when connecting via WiFi still occur?
Since no data would be passing TOO the BE for writing, I wondered if laptop/WiFi users could still view data in a JET DB without the increased risk of corruption or with substantially less risk even if its slightly more than wired.

Don't know if the nature of JET transactions still risks corruption even if read only on a split DB.

 

[CJ_London]

there is a risk and connecting FE to BE over a wifi network is not recommended. Even just viewing data by connecting to the BE causes a change to the file - look at the file date, if there were no changes, the date/time won't change.

Having said, that, look at the db properties around file locking - se FilE>Options>Client Settings>Advanced. Note that client settings are specific to the user, not the file so you would need to use vba to set these as required.

 

[JMongi]

I just know there is a certain subset of future users that have laptops that won't be good about reconnecting the LAN even when back in the office. I've got some scenarios kicking around in my head on how to manage that situation but wanted to make sure it was "worth" the hassle. My first idea is to have two separate pairs of split FE/BE. The master pair and a copy of the master pair that will be slightly out of date for the WiFi users to connect to for read only access.

My launch script should be able to detect an active WiFi connection and will launch the appropriate FE/BE pair depending upon the connection. Ideally, we will migrate to a BE that can handle such access, but, baby steps...

 

[isladogs]

I think its less likely that corruption will occur as that normally happens where data is being entered/edited when the connection is broken.
However, I wouldn't say corruption couldn't occur.

Besides which, you haven't said how you are making it read only.
1.Using a shortcut to open the file using the /ro switch? If so, users can get around that easily.
2. By setting forms to be read only. But can users access tables or queries or the VBE?

 

[JMongi]

@isladogs - Good question. I envision flagging their status on startup and then determining what is available via the flag. One possibility.

There is also the possibility of VPN and letting them deal with the slow performance. We use FortiNet VPN currently. As a related question, I know normally you would avoid VPN due to performance, but does VPN protect (mostly) against the WiFi corruption issues?

 

[isladogs]

@isladogs - Good question. I envision flagging their status on startup and then determining what is available via the flag. One possibility.

There is also the possibility of VPN and letting them deal with the slow performance. We use FortiNet VPN currently. As a related question, I know normally you would avoid VPN due to performance, but does VPN protect (mostly) against the WiFi corruption issues?

Sorry, don't have a definitive answer to that but I wouldn't have thought so

 

[JMongi]

Just referencing this thread and trying to meld the two ideas:

Well, this isn't pressing anyway. Just got me thinking about it...

 

[The_Doc_Man]

While I cannot make a definitive statement about VPNs and Access riding one, there is this to consider.

The primary reason that DBs get hosed over WiFi is the protocol used by Windows for file sharing, called Server Message Block or SMB. This is one of the (many) TCP sub-protocols that have negotiation ports and strict sequence numbering on messages. IF you are updating something that takes more than one network message frame (and for Access, that is EXTREMELY LIKELY) and you start sending frames but trip over a network drop, you now have a partially updated Access back-end. This is now a corrupted database.

IF you have a VPN, that is an encapsulation method that ALSO uses negotiated ports/sockets and a sequence-numbered message. If you drop the WiFi you drop the VPN. Now, VPN software may indeed do its damnedest to re-establish its connection, BUT both VPN and non-VPN WiFi drops have the same problem. Any sequenced connection has to be re-established in a context where the previous connection still has to time out. So that socket is not available UNLESS the IT staff has made it legal to do a reconnect. Sadly, I haven't seen a site that allows a reconnect in at least 20 years. It is considered an extreme security risk to do so.

The net result (you should pardon the pun) is that you cannot resume the previous connection so can never complete the update. Therefore, unless the VPN somehow remains connected after a drop, I think - and this is an OPINION - that the VPN over WiFi bought you nothing.