none
wireless RRS feed

  • Question

  • greetings.... just was wanting the group's input on the use of wireless PCs for an Access multi user application...  in the past I had seen some dialog that there were issues of hanging and such.  But it's been awhile and that may be old news.

    would welcome others' experience in this infrastructure environment....  

     
    Tuesday, August 20, 2019 10:23 PM

Answers

  • I think we're all concerned about data corruption. WiFi is not as stable as a wired connection, hence the reluctance to go there. A very brief 10 msec interruption at the wrong moment may corrupt your database.

    Now here is a thought: if that database were upsized to SQL Server, you have my blessing. With 10 users the free Express version is likely good enough. In this scenario the same interruption could generate a nasty runtime error, but no database corruption.

    Another thought is to get a USB-to-Ethernet converter and wire the laptops as well.


    -Tom. Microsoft Access MVP

    Wednesday, August 21, 2019 1:53 PM

All replies

  • Nothing much has changed on this front in years.  I still refer people to http://www.devhut.net/2016/09/24/access-back-end-location-wan-online-server-onedrive-dropbox/

    The simple fact of the matter is that wireless technology has improved, but still remains what it is.  Are you willing to risk you data?  It may work, it may not.  It may work for months and then sudden corrupt your db...  It may not... Are you will to take that risk?  Only you can answer that question.  What I will affirm is that backups are even more critical in a wireless, WAN environment.


    Daniel Pineault, 2010-2019 Microsoft MVP
    Professional Support: http://www.cardaconsultants.com
    MS Access Tips and Code Samples: http://www.devhut.net

    Tuesday, August 20, 2019 11:27 PM
  • haven't yet looked at the link you provided....

    just wanted to clarify - - not involving a WAN... the wireless should have been better described by me as WIFI.....

    definitely not putting a WAN between front and back....

    it is a matter of ethernet wires or local wifi router


    Tuesday, August 20, 2019 11:33 PM
  • I think if you access the db on a remote pc through wifi it will be fine.

    In other words don't have the fe on the local pc. Have the fe on a networked pc that you can remote into through wifi. This way you are not accessing the be across a wifi from the fe. If you feel you must risk using wifi without remote to another lan pc then you could try a wrapped transaction or an encapsulated upload through the use of disconnected objects.

    Bottom line  as Daniel pointed out...just not good practice. Not only do you risk bad data but also application failure.


    Just takes a click to give thanks for a helpful post or answer.
    Please vote “Helpful” or Mark as “Answer” as appropriate.
    Chris Ward
    Microsoft Community Contributor 2012

    Wednesday, August 21, 2019 8:34 AM
  • I believe I have introduced a major misunderstanding that I would hate for other newer developers to get confused by..... and also it is important as this is becoming such a common scenario.  The dialog above - and the link provided - involves a WAN.  The post was NOT intended to discuss a WAN but only discuss a WIFI / local wireless situation.

    The facility has 10 ethernet wired PCs in this multi user split Access application.  It is planned to add at least 3 wireless laptops.  The ultrabooks only are wireless they have no ethernet connectors.  So the FE is going to be on the wireless laptop PC in the facility.

    Just was checking that others ran in this config without issues before purchase of the ultrabooks.

    Because this scenario is so common - I assume it will work but wanted to double check this point.....

    Wednesday, August 21, 2019 11:22 AM
  • Wireless (WiFi), WAN, ... all are the same in the eyes of Access to be avoided.  The post/link provided explicitly mentions Wireless in it.  It's a gamble.  Wireless has improved, but I wouldn't ever gamble my data on it, and certainly not without a very robust backup plan in place.  Personally, wired is the only way I'd run Access.

    Daniel Pineault, 2010-2019 Microsoft MVP
    Professional Support: http://www.cardaconsultants.com
    MS Access Tips and Code Samples: http://www.devhut.net

    Wednesday, August 21, 2019 12:28 PM
  • I do appreciate the input.  I must quibble though - - your article in the link does not contain the word 'wifi' - only 'wireless'.   There is wireless Verizon cell service which is a WAN.  Then there is wireless wifi which is a LAN.  Thus the point of confusion.  The article's title is definitely all WAN - and leads one to that point of reference as well.

    With so many office variations now and the wide spread deployments of wifi LANs - plus their improved performance at 5G.  I would really be surprised if this doesn't work, as the response time should be fine.

    but this is partially my own fault on not being more clear in my original post.

    if there are any Access applications running on wifi LANs out there - - would really welcome input.....or equally if you tried it and had troubles.

    Wednesday, August 21, 2019 12:42 PM
  • Access requires a consistent connection to the database which Wi-Fi doesn't offer. The slightest glitch and you may receive the fatal Disk or network I/O error.

    If you must connect via Wi-Fi, run the application on a machine you can reach via Remote Desktop Connection.

    Alternatively, run the frontend on the laptop and use SQL Server (the Express edition is free) as the backend - this will work with the server connected via Wi-Fi (and/or a WAN, by the way).


    Gustav Brock

    Wednesday, August 21, 2019 1:25 PM
  • I think we're all concerned about data corruption. WiFi is not as stable as a wired connection, hence the reluctance to go there. A very brief 10 msec interruption at the wrong moment may corrupt your database.

    Now here is a thought: if that database were upsized to SQL Server, you have my blessing. With 10 users the free Express version is likely good enough. In this scenario the same interruption could generate a nasty runtime error, but no database corruption.

    Another thought is to get a USB-to-Ethernet converter and wire the laptops as well.


    -Tom. Microsoft Access MVP

    Wednesday, August 21, 2019 1:53 PM
  • Interesting input GB that SQL Server would work as the BE.  The error is thrown by the FE - at least that was my assumption.  … and wouldn't have thought a change in BE would affect that.....

    I have never thought the BE was issuing a keep-alive ping and so the error would occur as an event triggered by the FE, due to a time out when a connect attempt did not successfully complete within time period X  (I don't know what X is....)

    Work in many campus situations where there is differing LAN technology i.e. copper, fiber - and so the medium is not the issue but rather the time interval for the hand shaking control blocks.

    Since wifi is just a medium like copper or fiber - I was thinking the issue was timing only.....and that the newer wifi technology 5Ghz might be viable

    Wednesday, August 21, 2019 1:59 PM
  • thanks TvS - didn't see your reply initially.

    a nasty runtime error is still not acceptable.

    so there is still something that doesn't compute in that the PC and the application don't know what medium separates front from back end - - and so it really should come down to timing in the end...

    I guess WiFi is going to need to eliminate that 10 msec gap to be use-able.....

    it's a lot less expensive to deploy WiFi than wire for ethernet so I really think this topic is going to resurface a lot.....

     



    Wednesday, August 21, 2019 2:02 PM
  • > Since wifi is just a medium like copper or fiber

    But that's what it isn't. If it was, no issues.

    > and that the newer wifi technology 5Ghz might be viable

    It might be, so as any other Wi-Fi connection. Problem is, that it must be, and it isn't.


    Gustav Brock

    Wednesday, August 21, 2019 2:05 PM
  • I do appreciate the input.  I must quibble though - - your article in the link does not contain the word 'wifi' - only 'wireless'.   There is wireless Verizon cell service which is a WAN.  Then there is wireless wifi which is a LAN.  Thus the point of confusion.  The article's title is definitely all WAN - and leads one to that point of reference as well.

    I think with a statement such as:

    Microsoft Access databases are only meant to be run through wired LANs.  This point cannot be over emphasized! 

    it is quite clear if it is a good idea or not.

    I've added to the article, but wireless if wireless and that includes Wifi, all flavors of it.


    Daniel Pineault, 2010-2019 Microsoft MVP
    Professional Support: http://www.cardaconsultants.com
    MS Access Tips and Code Samples: http://www.devhut.net

    Thursday, August 22, 2019 11:06 AM
  • The problem is that Access is working in a connected state...when you have a form and an underlying table is used as RecordSource then there is a "connection" that cannot be broken...if there is even a slight network hiccup ...this is gone thus the error.

    Although untested an form that uses a local temp table that is populated on the fly might be a solution ...but it would require some design changes along with some extra coding to handle the data manipulation.

    Thursday, August 22, 2019 11:13 AM
  • I welcome all input and am happy to continue to follow this thread.  Given the growth of WiFi LAN deployment this surely is a topic of interest.

    In regard to 'a connected state' - I agree & understand - and yet 'connected' is defined by some signal (or electrical current) & timing mechanism.  For the front end to throw an error it must detect the connection is gone.  Or if it doesn't throw an error it could just hang.  The back end would think the front end simply left, no different than shutting down.

    I've never seen the explanation of the handshaking protocol between front/back, whether there is some sort of acknowledgement block needed within a specified time period.

    The LAN and the WAN are the same thing - just different scale representing very different response time intervals (let's assume VPN so we don't have to get into addressing).  The medium is independent (ethernet, copper, fiber, microwave).

    A WiFi LAN could be able to work if the manufacturers met the specs of the split Access db - but they don't read this forum and probably the cost to guarantee such a response time isn't profitable - who can say.  One of the reasons I opened the post is that I knew the WiFi LAN technology is improving and now using 5GHZ which perhaps was working.  So I was wondering if the forum response was going to include people that are using WiFi LANs without any issues......

    fyi - the local table idea works - except you have to send the data eventually to the back end, and then have the same dilemma as before so that would be a conundrum.

    Thursday, August 22, 2019 12:50 PM
  • Local temp table is a good idea. So are unbound forms. But that requires a ton of extra code. Might as well use .NET instead of Access if you have to go that route. Access's power is that the code is internal and makes for a very RAD development environment.

    All in all, keep it wired if it comes to important data.


    Bill Mosca
    www.thatlldoit.com
    http://tech.groups.yahoo.com/group/MS_Access_Professionals

    Thursday, August 22, 2019 12:54 PM
  • The problem with LAN vs Wifi ...is latency...with LAN you expect when you ping from one computer to another that its < 1ms ...its "natural"...its what the "system" expects...in Wifi there is absolutely no guarantee that the signal gets undistorted...you might have everything setup perfectly ...the antenna have the best possible coverage and its even directional so that ...its a connection from heaven...but suddenly something gets in the way...you ..a colleague..the cleaning lady and the signal gets "damaged".

    Take for granted that even minor hiccups in LAN connections can cause severe issues...i had a very old server that couldn't cope up with the load (VM on an old almost unsupported host)...the pings would go go fine for 10-20 or even 100 packets before it would loose 1..and so ping was fluctuating...NOT much but enough to cause issues...when we replaced the server and ping was solid <1 ms ..0 zero issues


    Thursday, August 22, 2019 6:59 PM