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

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
3 Pages V  1 2 3 >  (Go to first unread post)
   Reply to this topicStart new topic
> Network Interruption Error, Access 2010    
 
   
Brepea
post Sep 22 2017, 05:00 AM
Post#1



Posts: 515
Joined: 11-January 09
From: UK


Hi All

I currently have split FE & BE - real basic setup but am worried about an aspect of it. Users all use laptops. Some via WAN (i guess there is no real difference when using the LAN or WAN in terms of speed re: normal office applications (like Word/Excel,etc.) - so there is no real reason for users to plug in LAN). Of course - Access via WAN is data corruption waiting to happen - which i NEED to avoid at all costs.

Is there a way to pick this 'network interruption' before it happens (i'm not sure that even makes sense)...? Like a before-update event which you can use to cancelEvents. I just know that people will forget to plug in their LAN and access the application - causes corruption and headaches for me.

Is there an approach to this i can take?

Thanks
Go to the top of the page
 
Minty
post Sep 22 2017, 05:29 AM
Post#2



Posts: 70
Joined: 5-July 16



The short answer is no, the best route with the need for remote Access users is to use some form of remote desktop application.
MS Terminal server , Citrix and others will all give you a "Local" experience without the corruption issues.
Go to the top of the page
 
Brepea
post Sep 22 2017, 05:33 AM
Post#3



Posts: 515
Joined: 11-January 09
From: UK


Thanks Minty - are there any other considerations when do that from a development point of view? Is this a slower application as a result? Do I need to change anything - would an .accde run fine?
Go to the top of the page
 
Minty
post Sep 22 2017, 05:52 AM
Post#4



Posts: 70
Joined: 5-July 16



On a good RDP set up there is hardly any noticeable slowdown, you are only passing the screen information over the WAN network, all the data traffic is local between your RDP server and your other internal network BE storage.
If you install the Access runtime for all remote users, you will save loads of money on licencing - it's free smile.gif
Go to the top of the page
 
GroverParkGeorge
post Sep 22 2017, 06:42 AM
Post#5


UA Admin
Posts: 31,211
Joined: 20-June 02
From: Newcastle, WA


With regards to the question, "will an accde run fine", the answer would be that, properly designed, it will run as well as an accdb. Of course, it must have adequate error handling because any unhandled error drops the user out of the application.

--------------------
Go to the top of the page
 
Brepea
post Sep 22 2017, 07:36 AM
Post#6



Posts: 515
Joined: 11-January 09
From: UK


What about when a user accesses the application from home - so on a VPN - would the application run as if the user is on a LAN in office - or this regarded as a corruption magnet?
Go to the top of the page
 
GroverParkGeorge
post Sep 22 2017, 07:50 AM
Post#7


UA Admin
Posts: 31,211
Joined: 20-June 02
From: Newcastle, WA


That configuration would work fine.

--------------------
Go to the top of the page
 
Brepea
post Sep 22 2017, 08:18 AM
Post#8



Posts: 515
Joined: 11-January 09
From: UK


But they'd have to be connected to their internet via Ethernet and not via wifi - right?
Go to the top of the page
 
Minty
post Sep 22 2017, 08:25 AM
Post#9



Posts: 70
Joined: 5-July 16



VPN'ing in from WAN will not work reliably unless your application is extremely well thought out, and/or you have super fast, super stable connections.
On a normally bound form type Access DB, You possibly won't experience any BE corruption but you will get dropped connections, incomplete data records and possibly corrupted front ends.

Even over less than perfect local LAN WiFi, you can get poor performance and timeouts on data intensive forms.

Edit: Remote VPN into a locally hosted RDP would be fine.
Go to the top of the page
 
Brepea
post Sep 22 2017, 09:33 AM
Post#10



Posts: 515
Joined: 11-January 09
From: UK


Sorry - i think i need a little more clarification if you can...

Setup A: User in office (LAN connection) - preferred and ideal

Setup B: User in office (WAN connection) - corruption waiting to happen (because of dropped connections, user walking around floor with laptop, etc.) - what happens in this case (is this random - obviously the connection gets dropped, but the record they may have been editing is lost or part saved).

Setup C: User at home (access via Network Connect [must be a Citrix equivalent - i think]) / User uses his wifi to connect to his router which in turn access the Network Connect: open to corruption? or ok (so because the user is unlikely [although i suppose possible] to lose connection at home)

Setup D: User at home as per C, but they plug in Ethernet cable.

Am i correct in saying A or B are the only options. This is a business solution - so i need to be good with the advice provided.

Thanks

Sorry - i meant A & D as only option
Go to the top of the page
 
Minty
post Sep 22 2017, 09:53 AM
Post#11



Posts: 70
Joined: 5-July 16



A & C are actually your only options. D is the same as C just a better local connection.

Any direct WAN access will be troublesome. The idea is that you don't have open data connections over any WAN.
Possibly helpful picture

So ALL your remote users connect to a service that is running Access on your servers local network.
They don't move the data backwards and forwards, just the Desktop image and keyboard/mouse inputs, so the quality of connection is not so important.
If their external connection drops, the remote desktop session will still be there running, as it is local to the server, hence no data loss.
They simply reconnect and provided the RDP server hasn't terminated their session they will be back where they were pre disconnect.
Go to the top of the page
 
Brepea
post Sep 29 2017, 04:40 AM
Post#12



Posts: 515
Joined: 11-January 09
From: UK


A quick revisit on this subject: I asked another member of staff (who has a team of 10 users and uses WAN only) - how he doesn't end up with corruption issues on his Access application:

QUOTE
"I wrote my database so that the forms aren’t linked to the tables, then using the list boxes to display the records etc it doesn’t lock the records in the tables until the precise moment you click the save button. Which is why I haven’t had any issues with the database corrupting"


Does that even make sense? Form must be getting data from tables? Or does he mean forms created on queries...?
Go to the top of the page
 
GroverParkGeorge
post Sep 29 2017, 06:26 AM
Post#13


UA Admin
Posts: 31,211
Joined: 20-June 02
From: Newcastle, WA


He is using what are called unbound forms. That means his code has to do ALL of the work in retrieving data, assigning values to controls on forms, and then writing any changes back to the tables. This is akin to the work done in other development environments where bound forms are not avaliable.

--------------------
Go to the top of the page
 
Minty
post Sep 29 2017, 06:31 AM
Post#14



Posts: 70
Joined: 5-July 16



That is pretty much what I meant by a suitably designed database.
Effectively you end up using virtual unbound forms - display the data in a way that is a snapshot at that point in time.
Any editing is done locally, and only saved with a specific action - e.g a save button updates the record back to the table.

List boxes by definition are read only - there is no live data interaction with them.

This keeps the actual "live" data connections to a minimum.

There are other things you can do that are considered not normally good practice - for instance lets assume you have a table of Countries you use as a drop down combo in a address form.
In a split DB you will be dragging this table data over your network every time, so you can store this very rarely changing data as a local table, and simply update every time the local db is opened.
You can then get cleverer with this - keep a record of the more 'static' tables and when they were last updated. Compare this with your local versions last update and then only update the local 'static' tables accordingly.
Go to the top of the page
 
Brepea
post Sep 29 2017, 06:57 AM
Post#15



Posts: 515
Joined: 11-January 09
From: UK


Oh my goodness...this is not great news...I really thought Access was capable to handle multi-users over network...I have a whole load of new work to do to change how it's currently setup...
Go to the top of the page
 
Brepea
post Sep 29 2017, 07:38 AM
Post#16



Posts: 515
Joined: 11-January 09
From: UK


Grover:
QUOTE
That means his code has to do ALL of the work in retrieving data, assigning values to controls on forms, and then writing any changes back to the tables.


Is this a recommended approach, because i now have to consider redoing my forms....
Go to the top of the page
 
GroverParkGeorge
post Sep 29 2017, 07:41 AM
Post#17


UA Admin
Posts: 31,211
Joined: 20-June 02
From: Newcastle, WA


You've leapt to the wrong conclusion.

Access is capable of handling multi-users across networks. Millions of working accdb/mdb applications do so every day of the week all around the world. Some are based on the unbound approach, but most rely on the basic, Access way, i.e. bound forms.

Your colleague has chosen the most labor intensive way to do the job. Nothing more. You don't need to go down the same path unless you like, really LIKE, writing lots of code.

Minty offers a couple of highly practical ideas, neither of which involves moving to unbound forms.

I suggest you look elsewhere for solutions, again, unless you really like writing lots of code.

--------------------
Go to the top of the page
 
Brepea
post Sep 29 2017, 07:59 AM
Post#18



Posts: 515
Joined: 11-January 09
From: UK


Ok - thanks Grover...

Still not too sure what approach to follow...i will carry out some more tests in current setup - but i really don't think having WAN/LAN mix will work - so my only option is Citrix / SQL BE...
Go to the top of the page
 
Minty
post Sep 29 2017, 08:07 AM
Post#19



Posts: 70
Joined: 5-July 16



I agree, you have jumped to the wrong conclusion.

What this might do however is push you into design more "robust" and network friendly designs.

Some basics like - Don't load every record into a form when you open it. Open it with an empty recordset, then only populate it with what your user is looking for.
If a form is only used 99% of the time for "Viewing" information rather than editing it, open a snapshot of the records and make the forms controls locked. If you need to, add a refresh command button.
Go to the top of the page
 
Brepea
post Sep 29 2017, 08:23 AM
Post#20



Posts: 515
Joined: 11-January 09
From: UK


I've resolved most of my speed issues which were mainly about having Dcount ("[ID]","table/query", "condition") changed to DCount("*","table/query","condition"); and removed (where i could) any "me.requery" in AfterUpdate event handlers i had (some were overkill). On one form issue where listbox was flashing i created a continuous subform instead of the listbox. So that all works well.

It's just about this network interruption issue - as explained above most users will work as they usually do = on laptops via WAN - WAN is not a recommended approach - so I have little option but to go with Citrix (least amount of development or delay in getting system out there - although i'm not sure how long that will take to setup for each user) OR i have to redo my forms...

What I think I will first do is test this with 10 users during the week and see how it performs - if their are network interruption issues i know i'll have to go to plan B or C. What would you do (ok - maybe not be here in the first place, but now that you "are"...)?
Go to the top of the page
 
3 Pages V  1 2 3 >


Custom Search
RSSSearch   Top   Lo-Fi    14th December 2017 - 11:42 AM