Access on Remote Desktop Connection - Connection and Corruption Problems (1 Viewer)

ipdev

New member
Local time
Today, 15:26
Joined
Jul 29, 2020
Messages
6
Hi, some networking expertise is needed here I think.
  • Access 2016
  • Windows 10
  • Windows Remote Desktop Connection ("RDC")
  • GlobalProtect VPN
  • MS Access running on a remote virtual PC ("VPC")
  • frontend and backend accdb files saved on the same, remote network server
  • frontend linked to tables in backend using UNC notation
NB the user is not running Access on their local workstation, it is being run on the remote VPC; the user is only using their local workstation to run the RDC.

We're seeing an increase in corruption of the backend accdb. Is there any way the user's Internet connection being unstable could cause the remote LAN connection between the frontend and backend to be affected, possibly leading to corruption?

Sounds like a stupid question I know, but I need to rule it out.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 07:26
Joined
Oct 29, 2018
Messages
12,078
Hi. What is the Build Number of your Windows 10?
 

ipdev

New member
Local time
Today, 15:26
Joined
Jul 29, 2020
Messages
6
Hi.

On the VPC
1596038732910.png


On the user's PC
1596038784660.png
 

Minty

AWF VIP
Local time
Today, 15:26
Joined
Jul 26, 2013
Messages
7,276
In theory, the answer to your question is no, as there is no actual data being moved between the remote user and your Access application, simply screen images.

Do you have more than one user accessing the front end at a time?
 

The_Doc_Man

Immoderate Moderator, Former MVP, Retired SysAdmin
Staff member
Local time
Today, 09:26
Joined
Feb 28, 2001
Messages
17,781
Are all of your users running the same physical copy of the FE? I.e. do they ALL point to the same folder for the FE?

If so, this is a file access conflict and a case of destructive interference ("left hand not knowing what the right hand is doing.")

Using RDC to control Access is an OK idea but sharing an FE via that method is NOT. If your users can log in to separate folders on the server where they are visiting, put a copy of the FE in each such folder. Have them run their private copies.

Particularly if there is a form that each one is most likely to use, that will be the culprit. Worse would be a table or query that they can directly touch.
 

ipdev

New member
Local time
Today, 15:26
Joined
Jul 29, 2020
Messages
6
Hi Minty. Yes (maximum 5 concurrent users including me), but I have proven corruption - today - with only one user running the application.

Hi The_Doc_Man. The current FE is copied to the user's C drive before being run, so they all run their own copy.
 

The_Doc_Man

Immoderate Moderator, Former MVP, Retired SysAdmin
Staff member
Local time
Today, 09:26
Joined
Feb 28, 2001
Messages
17,781
Any action that can cause a session to terminate incorrectly, regardless of where it is, potentially can corrupt an Access DB. Which is why if anyone EVER just shuts off their machine with the app open on the screen at the time, you have every right to yell like Hell. I won't say it is impossible to corrupt a DB in a single-user case, but it is rare. An abnormal close is a prime candidate for bollixing up the works.

Typically, the mechanism of corruption is that you have a database doing something. It does that something in a buffer that contains the local copy of the data from the DB file. Multiple buffers can be (and probably ARE) involved. Then when you go to rewrite the buffers (to update the DB file based on your action), something happens during the write-back of one of them and you end up with a chunk of data in the middle of the DB no longer consistent with the rest of the DB.

The best way to figure this out is, when it happens, to immediately determine exactly what the user was doing just before the corruption occurred so that you can trace the data flow & control flow through the logic.

Given the description that you gave us, you are running Access in effect locally, the network isn't involved in the file transfer between Access and the DB file. Well, technically it is... through the LOOPBACK port, because you are using UNC mapping as opposed to drive-letter mapping. But that network operation never leaves the machine and thus is very fast. Therefore, the only thing that could cause a problem is if your remote desktop session dies, you have a copy of Access hanging, and it is the nature of the Access "beast" that if it has a buffer open but nothing else is going on, it will leave that buffer open ... and nothing will go on. That buffer is locked (in the I/O sense, not the DB lock sense) and that can cause other things to go bad.

If you have the ability to do so (but you might need the help of your IT person(s) to do this) you need to see if there is a "hanging" session of Access that has the DB open. On something that is compatible with Win10, you can do this through Resource Manager for a quick-n-dirty look, or there are some commands to show you file locks.
 

Minty

AWF VIP
Local time
Today, 15:26
Joined
Jul 26, 2013
Messages
7,276
Hi Minty. Yes (maximum 5 concurrent users including me), but I have proven corruption - today - with only one user running the application.

Hi The_Doc_Man. The current FE is copied to the user's C drive before being run, so they all run their own copy.
That answer is slightly contradictory or I've misunderstood it. In the RDP scenario are you sharing a FE or each user has their own RDP Session folder they use?
Sharing a FE under any scenario will cause corruption and is not recommended.
 

ipdev

New member
Local time
Today, 15:26
Joined
Jul 29, 2020
Messages
6
Hi Minty. Apologies, that was confusing reading it back. The C drive the FE is copied to and run from is the VPC's C drive; each user connects to a distinct VPC.

Hi The_Doc_Man. Thanks for a very comprehensive response, which I will work through in full. FYI I am using a Windows batch command (.BAT) file to copy the FE and then open it, while at the same time using that batch file to log to an external text file. I log when (i) the FE opens and (ii) returns control to the batch file (user exits the FE), so I can see whether a user's session is "completed". Corruption is occurring even during a complete session, i.e. without the RDC terminating - if it were terminating the batch file would not log the exit event. Checking for Access running in the background is not something I'd thought about, thanks for that one in particular.

I do have another (somewhat off-topic) lead; I've discovered that a couple of tables that were fairly recent additions to the corrupting database still had the Subdatasheet Name table property set to [Auto]. I understand this is the source of much-reduced performance, which I assume might lead to a timeout issue. They are not oft-utilised tables so this is a bit of a stab-in-the-dark. These have been reset to [None] so I'll monitor if that has an effect.

Thanks to both of you for your continuing input on this, it is much appreciated.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 15:26
Joined
Feb 19, 2013
Messages
12,471
it may be that once corrupted, you are not doing sufficient to remove the corruption completely, leaving a kernal of corruption to erupt again at some point in the future. This can happen if you are reverting to a backup - the kernal might exist there if the corruption was not apparent at the time.

So my question is - how are you recovering from corruption? If not already tried, I suggest create a new db and copy table definitions over as a first step, then use queries (could be a simple vba loop) to insert the data from the old tables to the new.
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Top Bottom