Mobile Workers

[dfenton]

This is something I am starting to look into because wireless internet is now very common in Australia. I use wireless and the modem just plugs into a USB port and will work on any computer.

I see that you've decided to go with MySQL as your back end (dunno why, though), so Jet replication is no longer relevant, but I just wanted to point out that with a WiFi environment, you'd not want to use the simplest form of Jet replication (direct) as it's just way too dangerous, in the same way you wouldn't deploy an Access app with a Jet back end across a wireless network.

 

[Simon_MT]

There is nothing wrong using wireless if the base station can't be managed remote, it has a password and does not broadcast itself. Security can be enhanced with VPN. I use Access with remote PC wirelessly connected to remote Terminal Server.

Simon

 

[dfenton]

There is nothing wrong using wireless if the base station can't be managed remote, it has a password and does not broadcast itself. Security can be enhanced with VPN. I use Access with remote PC wirelessly connected to remote Terminal Server.

Sorry, but that's just wrong. With a Jet back end (which is, by definition, what's in use when synching), it is completely unsafe to use any kind of network that is not 100% reliable. Wireless networks are not even close to being safe enough to open a Jet database across the wire.

If you have an Access app with a Jet back end in a wireless environment, I'd suggest quite strongly that you would be wise to port the back end to a server database if the WiFi is non-negotiable. Failure to do that *will* result in corruption (and downtime and possibly loss of data), the only question is whether it's sooner or later.

 

[Simon_MT]

The wireless is local, Access is on a remote Terminal Server, the Terminal Server WILL allow session disruption as it has the capability of resuming a Session if the Session Time-out has tolerance to do so. This has been done many time without any corruption.

Simon

 

[dfenton]

The wireless is local, Access is on a remote Terminal Server, the Terminal Server WILL allow session disruption as it has the capability of resuming a Session if the Session Time-out has tolerance to do so. This has been done many time without any corruption.

Sorry, but I don't see anywhere in your post where you said that you were running the app on a Terminal Server. Naturally, that's fine.

But it's not what I said: I said that you don't want to run an Access front end connecting to a Jet back end across a wireless network. When you're running on a Terminal Server, you're not running any part of the data retrieval across a network (well, assuming you have your back end stored on the Terminal Server; otherwise you'd definitely want to make sure the network connection between the Terminal Server and the file server with the Jet back end is wired and *not* wireless).

You seem to be responding to something I didn't write.

 

[Simon_MT]

I did mention a Terminal Server, I don't see a problem with a wireless connection into a Terminal Server either mainly because it's capable of Session resumption. Without this I take your point. I do believe that the later models of the Buffalo Air Stations are much more robust.

Simon

 

[dfenton]

I did mention a Terminal Server, I don't see a problem with a wireless connection into a Terminal Server either mainly because it's capable of Session resumption. Without this I take your point.

Everything I wrote was clearly about *not* using Terminal Server. It wasn't ambiguous.

I do believe that the later models of the Buffalo Air Stations are much more robust.

No wireless or WAN connection is reliable enough to run an Access app across it connecting to a Jet back end on the other end of the network.

 

[Mike375]

No wireless or WAN connection is reliable enough to run an Access app across it connecting to a Jet back end on the other end of the network.

Is this determined or influenced by what the DB is doing.

The reason I ask is I have a telemarketing DB that is used across a wireless network and by a few groups. There is typically about 4 to 7 computers on each network in each group. The wireless does drop out but all that happens is "clicking" obviously does not work. Then normally the hub is turned off and back on and sometimes the computers need to be rebooted. But there has never been any corruption problems.

99% of the activity on the DB is a "click" will opening a form for a Many table and SetValues the fields. The DB has been used for a few years this way.

Some of the telemarketers will select an option where some macros/queries run when they move to each record and this updates the call results on their screen.

The BE is a full DB, that is, not just tables and is also used for the telemarketing.

The DB has been used both as A95 and for the last few years as A2003.

I am not wanting to debate or argue the correctness of your what you have said but wondering if corruption issues are determined by the DB. As a side note these DBs are going all day. Each telemarketer will make about 30 to 40 phone calls per hour and that would be for about 5 hours and there will be as I said from 4 to 7 computers running at the same time.

The telemarketing section of the DB has no VBA, all macro driven. Queries are all simpel, made in Query design.

 

[dfenton]

Is this determined or influenced by what the DB is doing.

No. If the connection drops, Access gives the "disk or network error" and has to be closed -- it is a non-trappable, non-recoverable error. It doesn't always corrupt the back end, since the connection that's dropped may not have been in the middle of an operation that could cause corruption (a read operation is not going to corrupt the back end).

The reason I ask is I have a telemarketing DB that is used across a wireless network and by a few groups. There is typically about 4 to 7 computers on each network in each group. The wireless does drop out but all that happens is "clicking" obviously does not work. Then normally the hub is turned off and back on and sometimes the computers need to be rebooted. But there has never been any corruption problems.

If Access does not detect the dropped connection, it won't give the "disk or network error." If you're not seeing that it would indicate that you've either got a completely unbound app, or are somehow extremely lucky.

I find your report, well, completely implausible. If the network connection is being lost, users would have to force quit Access (because of the "disk or network error") and restart it. If they aren't experiencing that, then the network connection is actually not being lost at all.

But with WiFi, it's very easy for it to be lost, and thus, way too dangerous to ever attempt.

I am assuming one thing, though, that you're not running the app on a Windows Terminal Server. Everything I'm discussing here is in regard to having a front end on the local workstation and a Jet back end on a file server. If you're using SQL Server or some other server database for the back end, or you are running the app on Windows Terminal Server, none of my comments apply, because you're not opening a Jet back end across a wireless connection.

 

[Mike375]

I find your report, well, completely implausible. If the network connection is being lost, users would have to force quit Access (because of the "disk or network error") and restart it. If they aren't experiencing that, then the network connection is actually not being lost at all.

Dosk network error is what will happen

I am assuming one thing, though, that you're not running the app on a Windows Terminal Server. Everything I'm discussing here is in regard to having a front end on the local workstation and a Jet back end on a file server. If you're using SQL Server or some other server database for the back end, or you are running the app on Windows Terminal Server, none of my comments apply, because you're not opening a Jet back end across a wireless connection.

All Access only. I would guess that the vast majority of times that the wireless drops there would be no process being done. It becomes apparent when someone "clicks" and it is disconnected. For each hour of telemarketing I would guess the telemarketer's computer is processing for pehaps 60 to 90 seconds maximum.

I have read plenty times on the forum about potential corruption although I have neve worried about it with the telemarketing DB because of the convenience of the wireless and it is continually backed up with a date/time stamp. But I was curious why we have not experienced corruption. Probably just a simple case of drop outs not occurring while processing is occurring.

 

[Simon_MT]

Mike and David,

This has been an illuminating discussion as pressure is exerted by users on deploying wireless, whilst it can be successful, it does come with caveats which are very helpful.

This is the type of issue that should be a Sticky.

Thanks again

Simon

 

[dfenton]

This has been an illuminating discussion as pressure is exerted by users on deploying wireless, whilst it can be successful, it does come with caveats which are very helpful.

If WiFi is a requirement, then you need to upsize the back end to a server database, like MySQL or SQL Server. There is no safe way to operate over wireless otherwise.

 

[jsv2002]

I've just started playing around with VPN connections again after having some troubles before might be a solution/option for those on lower budgets and not wanting to go to the expense of Terminal services have a look at my post here:

http://www.access-programmers.co.uk/forums/showthread.php?t=171635

Any comments would be appreciated John