Tips on General DB Deployment and/or Management

[isladogs]

OK - remember its not fool-proof by any means...

Open using the shift bypass
Replace the two linked tables with your own linked network table(s) and modify the code accordingly
There are two different procedures. One is mine, the other is adezii's
It will detect whether a linked network table is connected but can't tell whether Ethernet or WiFi is actually in use if both connections exist

 

[FrankRuperto]

Unfortunately nobody has yet devised code that can reliably detect with certainty when Wifi is actually being used

I thought a solution for that was recently solved by you and ADezii in a UA thread?

 

[isladogs]

At the time of the UA thread, I thought it worked but further tests confirmed what I wrote above.
The zip file includes that code.

Similar code was provided recently here by @arnelgp. See Solved - Confirm LAN connection. | Access World Forums (access-programmers.co.uk)
However, whilst the OP was happy with that, it also failed in exactly the same situation I have described when I tested it

 

[FrankRuperto]

At the time of the UA thread, I thought it worked but further tests confirmed what I wrote above.
The zip file includes that code.

Similar code was provided recently here by @arnelgp. See Solved - Confirm LAN connection. | Access World Forums (access-programmers.co.uk)
However, whilst the OP was happy with that, it also failed in exactly the same situation I have described when I tested it

Hmm, there are PowerShell cmdlets for reliably detecting if ethernet is connected:

If ( (Get-NetAdapter -Name 'Ethernet').MediaConnectionState -eq 'Connected' )

See: https://devblogs.microsoft.com/scripting/use-powershell-to-disable-wi-fi/

Maybe it was not reliable because WiFi adapters are not all named the same among different computers, or adapter type enum can vary with different Win versions?

 

[isladogs]

No.
As I stated earlier, this type of code can reliably detect if a workstation has an Ethernet or Wifi connection (using searches for Wi*Fi or Wireless).
However many devices such as laptops have both available.
Testing shows that the code cannot detect reliably if Ethernet is being used for network connection when Wifi is also switched on.

If that isn't a concern, then any of this type of code would probably suffice.

Thanks for the PowerShell link

 

[FrankRuperto]

That being said, if the main objective is to ensure that a wifi connection is not being used when opening an Access FE, then how about disabling wifi with a PS script that runs when users click on the shortcut that launches the Access FE?

 

[isladogs]

That may well be an acceptable solution but it would be essential to switch WiFi back on again when the app is closed.

 

[FrankRuperto]

That may well be an acceptable solution but it would be essential to switch WiFi back on again when the app is closed.

When the FE closes, control returns to the cmd script that launched the FE and a PS command can enable the wifi.

 

[JMongi]

Wow, you guys already worked out a possible solution I had come up with yesterday but didn't want to post about until I had done more research. There are a lot of threads on the internet about disabling WiFi when connected to the Ethernet. Many assume that plugging in an Ethernet cable automatically disables WiFi but it does not. There are a few programs that don't play nice in this "Bridged Mode" connection. Once I found an elegant solution for the "disabling WiFi" idea via powershell, then I was going to investigate incorporating that functionality into an Access based solution.

@isladogs - Thanks for posting the code and the brief how-to for modification.

 

[FrankRuperto]

Wow, you guys already worked out a possible solution I had come up with yesterday but didn't want to post about until I had done more research. There are a lot of threads on the internet about disabling WiFi when connected to the Ethernet. Many assume that plugging in an Ethernet cable automatically disables WiFi but it does not. There are a few programs that don't play nice in this "Bridged Mode" connection. Once I found an elegant solution for the "disabling WiFi" idea via powershell, then I was going to investigate incorporating that functionality into an Access based solution.

@isladogs - Thanks for posting the code and the brief how-to for modification.

Yeh, one cannot do it all with vba inside an open Access FE. Disabling wifi and backups are recipes for corruption.
If you can't determine whether ethernet or wifi is being used for the Access table links, then temporarily disabling all network adapters except ethernet before launching the Access FE is best approach. There are devices which automatically switch from one adapter to another if the there's a bad connection. The best solution is to use RDP. If the connection goes bad, when you reconnect the screen will be at same spot when disconnection occured, and no corruption. Ethernet is not exempt from causing Access corruptions. We have a client with 12 Access users on a LAN. Although a 1GB switch was being used, some workstations had 100mbit NIC's, others had 1gbit NIC's, mixed Win7 Win10, couple workstations were 400 feet away, and they were using unshielded cables.

 

[JMongi]

Bringing this thread back to life to get some more input. A majority of the topics in this thread are in various states of accomplishment. I appreciate the discussion on wifi, it was very helpful. I'd like to turn attention to point #7 because I haven't seen too much on this in my searching.

7.Crash Handling
TBD, This needs some work and I need to better understand what Access is doing. Active processes after app shutdown need cleaned up.

So, I'm aware of the crash w/ persistent lock file situation that needs remedied. But, I've never had to deal with that in a multi-user environment with multiple front ends. Is it the FE that gets the lock file on crash? the BE? I simply can't recall from the last time I dealt with it.

So, general commentary on crash recovery is much appreciated. I'll throw some questions out, but, I don't know what I don't know.

1. When Access crashes with an error that will cause a close once "OK" is clicked, are there any events that trigger that can be used for logging or notifications?
2. If the user force quits using task manager, are there any triggers?
3. If a user crashes their FE and goes to relaunch it, what checks should I incorporate to care for previous crash states?
4. How do you handle the left over processes? i.e. When I've crashed Access, then gone to delete the lock file, there are two processes running still that I have to kill before being able to delete the lock file and relaunch the FE. How do you handle this?

 

[Isaac]

When Access crashes with an error that will cause a close once "OK" is clicked, are there any events that trigger that can be used for logging or notifications?

Do you mean the fact that any Access database running in Runtime mode will generate "Execution of this application can't continue and will be shut down" upon any unhandled error? If so, the solution is to learn never to ignore error handlers

If the user force quits using task manager, are there any triggers?

Do you mean do any Events (form, control, etc) fire? I would hazard a guess: No.

How do you handle the left over processes? i.e. When I've crashed Access, then gone to delete the lock file, there are two processes running still that I have to kill before being able to delete the lock file and relaunch the FE. How do you handle this?

For me, if Access actually crashes (exits), there are no processes running. You can manually delete the Locking file, but there is really no need to. The database will re-open and re-acquire the lock file and begin using it in the normal manner.
Personally, I have never done anything special vis-a-vi crashes, nor needed to. The only ill effect I've seen my systems suffer is people being left inaccurately in my Current Users table, which is annoying, but not really critically impactful.

 

[JMongi]

Maybe I'm inadvertently running in modes that aren't reflective of final deployment permissions. When I crash out (I do need to clean up my error handling a bit) I can't relaunch Access. But, maybe that is more related to the running processes (that don't let me delete the lock file). I can't recall if I tried relaunching Access after deleting those processes.

If Access crashes are all processes supposed to be terminated? I get two processes running in the background even without the application window anywhere.

Edit: I'm running with local FE and BE on a separate server share.

 

[Isaac]

That's definitely problematic. Is there more going on, in this picture, that we aren't aware of? To clarify, my comments were applicable to the simplest of scenarios (which is where I generally stay BTW) - a single, simple, Access FE file which has been opened once, and isn't opening any other Access files or doing anything else weird.

If your situation has gotten more complex, this might be just one more reason as I often preach where there is great value in using something other than Access to open your FE, like a VBScript file shortcut on the desktop. In this way, you have a nice layer of separation from Access and everything is in your power. Copy the latest FE from the network, check on lock files or other Access processes, do just about anything you want to do, check trusted locations, check wifi, whatever the case may be--all before you attempt to open the core file.

In my experience once you start this method you just end up finding more and more things that can be fit into this startup script and it ends up being pretty useful. I'd say I end up using this approach perhaps fully half the time.

 

[JMongi]

Hmm...that's a good idea. Woudn't hurt to get that script sorted and start using it to even better mimic future use.