Access and WANs/VNC (2000/2002)

Topic

New Reply

I have a customer using an Ac2002 db shared between 2 PCs. He now wants to let a remote site share the db too. My first thought was some sort of remote access (small ‘a’) setup with a thinnish client, say using TridiaVNC or TightVNC (both free and open-source). Has anyone tried this kind of thing? Is a broadband connexion necessary? The alternative is a fast connexion and a mapped drive, but of course if the connexion is lost then db corruption may follow – the beauty (I hope) of VNC would be that that would not be an issue, since it’s the local machine that’s actually accessing the mdb, not the remote one.

Maybe you have experiences, thoughts or other ideas… TIA

James

Reply | Quote

Replies

Access was NOT intended to work over a WAN. It can work on something like Citrix or Terminal Server but I know nothing about the products you mentioned so I can’t speak to them. In any case, don’t try this over a dialup because you are absolutely setting yourself up for disaster. Access is incredibly sensitive to any blip in a network connection and it does not recover from that momentary loss of connection.

Reply | Quote

Yeah, I wouldn’t even try networking it over dialup. That was why I was considering a Terminal-Server-alike solution. If no one here has tried it then I guess I’d better start doing some tests…

James

Reply | Quote

We’ve actually done it for a couple of clients, and if you you have a decent broadband connection (256KB or better) it’s not too bad. We’ve actually even done development using Terminal Services and found it workable on a 512KB connection. But we’ve had less satisfactory results using some of the lower speed wireless connections.

Another alternative is a replicated database – though there are lots of issues with that approach that you need to consider. The principal advantage is that the remote user can work even when there is not a connection to the central site.

Reply | Quote

We’ve tried several approaches to this situation. The best went as follows:

Split database app with frontend on however many workstations linked to the backend on a server on the lan

Remote user links via dialup (via pcAnywhere) to one of the lan workstations (which also has pcAnywhere) and runs the frontend on that station via remote control.

Advantages: All processing takes place “in house” on the lan. The only things transmitted back and forth via dialup between the lan and remote user are keystrokes and screen refreshes.

Reply | Quote

Thanks Dick — sounds just like what I had in mind. The db is already split like that. You find it’s usable over 56k dialup? I’ll soon find out with my tests here…

James

Reply | Quote

We’ve run it successfully through 56k modems which obviously don’t perform at that speed due to the variables in available pots lines.

Reply | Quote

Good stuff, thanks. James

Reply | Quote

Tests so far with VNC show that it works. But it’s so slow, even after tweaking compression settings &c., and even just over my 2-PC LAN, that I wouldn’t expect a customer to put up with it. Over dialup it’s appallingly slow, just unusable. Maybe I’m missing a trick, or maybe PCAnywhere works better. More tests required…

James

Reply | Quote

How are you configuring your arrangement? You don’t want the front-end on the remote workstation – put it on the VNC host. Doing it that way should give you better performance.

Reply | Quote

No, the front end is on the VNC host, honest. However, I realised just after I posted that the host was set to 1280×1024. I knocked it down to 800×600 and it was quite usable across the LAN. Maybe a broadband connection would be OK. However, reports would print at the host site… this would nuke the VNC idea, and may force me to go for replication. Unless you have any ideas…

James

Reply | Quote

In our situation the “acceptable” performance was relative to running the front end on the remote laptop linked via WAN to the “home” server back end. This was totally unacceptable, as others have stated.
Using remote access software (pcAnywhere) to run front end and backend “under the home roof” was at least useable for our purposes. It was considerably slower than running the app “at home” over the LAN because screen refreshes and keystrokes were being transmitted back and forth between the remote and host via modem over a pots line.
It got the job done for us, but may in fact not be acceptable to a paying client unless he had experienced trying to link to a back end via pots from a local front end.
I apologize if my comments have confused your approach, but was relating our experience in what seemed to be a similar situation.

Reply | Quote

No, don’t apologise, you’ve been very helpful. It looks like the remote-printing issue will kill this idea anyway. I may be back shortly to ask for help with replication

James

Reply | Quote

would it be possible to print the reports to Snapshot and email them to the remote user for printing?

Peter

Reply | Quote

Possibly. But these reports are estimates and invoices which they’ll want immediately, so for this project perhaps not. Neat idea for a different project though.

James

Reply | Quote

Except for the odd fact that Microsoft have pulled all the snapshot viewers from their web site!!

Reply | Quote

Thanks for that Wendell — the good news is that this is a small db, only a couple of forms and fairly low traffic so the load will be low. I can do some trials but I only have dialup (no broadband here yet). Just spoken with the customer and they’d be happy with a daily update, so maybe replication is also a possibility. I’ll do some reading, although if you know any especial gotchas I’d be glad of the warning!

James

Reply | Quote