UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Is There Any Way To Mitigate Against A Ts Forced Logoff?, Access 2010    
 
   
appro
post Sep 14 2017, 02:15 AM
Post#1



Posts: 158
Joined: 23-January 05



I have a 10 user database that all users access via remote desktop. The client has been hit by ransomware at least once and their IT support has implemented a solution that has the undesirable consequence of sometimes dropping the RD connection for users.

When this happens the user loses any unsaved data. The IT support person has asked me if there is anything I can do to prevent data loss in this scenario. I'm assuming not, as what is happening can probably be likened to pulling the power plug of the computer.

Can anyone suggest anything that I can do? I'm thinking that there's not and that it is up to IT support to implement a different system where the dropped RD connections don't occur.
Go to the top of the page
 
Minty
post Sep 14 2017, 03:18 AM
Post#2



Posts: 70
Joined: 5-July 16



If the remote desktop is exactly that, then the application won't drop out, just their connection to the remote desktop?
Unless I've grasping the wrong end of the sticky thing...
Go to the top of the page
 
appro
post Sep 14 2017, 03:23 AM
Post#3



Posts: 158
Joined: 23-January 05



Thanks Minty. No, no misunderstanding on your part, but wrong information on my part. I've just finished getting more info on this and what is happening is that they are being actively logged off RD by the solution that IT has put in place.

In that case, would I be correct in saying that they'd lose any unsaved data? This is what I have been told is happening.

Also, would this have any ramifications as far as corruption of the BE file is concerned, similar to a user losing their connection in a standard client server environment?
Go to the top of the page
 
Minty
post Sep 14 2017, 04:03 AM
Post#4



Posts: 70
Joined: 5-July 16



Normally a remote desktop session is simply a view onto a hosted desktop.
When the connection to the RD Session is dropped the underlying desktop is still running, if IT are forcibly closing the underlying desktop session then yes you could well effectively be closing the access db FE as if you ended it with the task manager.
I doubt you'll get BE corruption but you could get FE corruption, and possibly incomplete data.
Go to the top of the page
 
raykor
post Sep 14 2017, 01:35 PM
Post#5



Posts: 135
Joined: 5-April 09
From: Seattle, WA


Unless I missed it, you didn't explain the front end/back end layout of your project. I am assuming it is an Access FE writing to to an Access or SQL Server BE as those are the two most common.

You could create a local copy of the tables in the FE and store the values every time a field is edited. Then create a procedure that transfers the temporary data (stored in the FE copy of the tables) to the "real" BE database. The procedure would delete the local copy of the data if successfully transferred to the BE. The procedure could be triggered whenever the user moves to a new record, closes the record editing form, closes the FE, or presses a "Save Changes" button. Lots of options for how you want your UI to behave.

In the event that a connection is lost, another procedure could detect (upon re-opening of the FE) that a temporary record exists in the FE table and give the user the option to continue editing, delete, commit to the BE, etc.
Go to the top of the page
 
Katty
post Sep 15 2017, 01:24 AM
Post#6



Posts: 169
Joined: 1-February 10
From: Lincolnshire UK


I have this problem a lot although not from a data loss perspective most of the time. RD connections to our server time out after a specific time period that to me is very short. Users, despite being told to close the database after use, leave the database open and then their RD session is forcibly terminated. This leads to the front end database regularly corrupting and needing to be re-downloaded as our versioning solution doesn't download a new one unless there is a version change. Our IS see this as a user problem, as they shouldn't leave the application open when they are not using it.

If IS can avoid the RD termination (especially if it happens randomly) then that would likely be your safest bet to not have FE corruption. From a purely data point of view, the local record solution suggested by raykor is probably your best bet.

Katty
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    11th December 2017 - 09:41 PM