Remote access - TS, pcAnywhere?

[Mike MacSween]

Sorry if this is a bit off topic, but I can't seem to find a 'remote
control' newsgroup on my news server. And anyway I know Tony has some
experience of this.

The app is split FE/BE. I'd like remote access to at least the server,
hopefully the whole network. And to be able to upload/download, to install
new versions of the FE to the server (which then get sent up to the clients
at runtime).

What experience does anybody have of this. Is this doable via TS? There
doesn't seem to be any FTP feature in RDP, or have I missed it?

TIA, Mike MacSween

[Mike MacSween]

Sorry, not enough info there was there? The clients have a cable connection,
always on and a single server, not a dedicated db fileserver. They're behind
a firewall, though I don't know anything about it. They have part time
sysadmin who comes in as required. I'm on a DSL connection here, behind NAT.
When I can afford it I'll probably get a firewall so I can have a permanent
IP.

Yours, Mike MacSween

"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f*********************@pubnews.gradwell.net. ..

Sorry if this is a bit off topic, but I can't seem to find a 'remote
control' newsgroup on my news server. And anyway I know Tony has some
experience of this.

The app is split FE/BE. I'd like remote access to at least the server,
hopefully the whole network. And to be able to upload/download, to install
new versions of the FE to the server (which then get sent up to the clients at runtime).

What experience does anybody have of this. Is this doable via TS? There
doesn't seem to be any FTP feature in RDP, or have I missed it?

TIA, Mike MacSween

[paii]

Access FE/BE over a VPN with the FE on the remote and the BE on the server
will be very slow and possibly unreliable. I have Access on Windows 2000 TS
with Citrix using the VPN to make the remote terminal connection. This keeps
the FE/BE on the same network.

Be aware that TS is expensive and Access pushes the server hard. Treat each
Access users as a power user when sizing the server.

"Chuck Grimsby" <c.*******@worldnet.att.net.invalid> wrote in message
news:0q********************************@4ax.com...

Wrong technology, Mike. TS is for remote control of a PC. What you
need is a VPN (Virtual Private Network) so you can link the drives on
your system to those on the other system.

Is it do able? Yes! I've used it quite a number of times. There are
a number of ports that will need to be opened in your NAT box and at
the client's Firewall (which ones will depend upon the VPN you
choose), but that's not really a huge task. (Changing the Network
Admin's thoughts on this tends to be the hardest part!)

On Sun, 21 Sep 2003 08:41:32 +0100, "Mike MacSween"
<mi******************@btinternet.com> wrote:

Sorry, not enough info there was there? The clients have a cable connection,always on and a single server, not a dedicated db fileserver. They're behinda firewall, though I don't know anything about it. They have part time
sysadmin who comes in as required. I'm on a DSL connection here, behind NAT.When I can afford it I'll probably get a firewall so I can have a permanentIP.

"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f*********************@pubnews.gradwell.net ...

Sorry if this is a bit off topic, but I can't seem to find a 'remote
control' newsgroup on my news server. And anyway I know Tony has some
experience of this.
The app is split FE/BE. I'd like remote access to at least the server,
hopefully the whole network. And to be able to upload/download, to install new versions of the FE to the server (which then get sent up to the
clients at runtime).
What experience does anybody have of this. Is this doable via TS? There
doesn't seem to be any FTP feature in RDP, or have I missed it?

--
Don't Look Back, They Might Be Gaining On You.

[Steve Schapel]

Mike,

"They" don't need to FTP files down. You can FTP files into their
system for them via your TS connection.

- Steve Schapel, Microsoft Access MVP
On Sun, 21 Sep 2003 21:00:43 +0100, "Mike MacSween"
<mi******************@btinternet.com> wrote:

I don't want to have to go to their site, and I don't want them to have to
FTP files down. Really I want to be able to do complete maintenance with no
involvement from them.

Cheers, Mike

[Tom Mitchell]

"Mike MacSween" <mi******************@btinternet.com> wrote in message news:<3f*********************@pubnews.gradwell.net >...

I don't want to have to go to their site, and I don't want them to have to
FTP files down. Really I want to be able to do complete maintenance with no
involvement from them.

Cheers, Mike

I've used a combination of PCAnywhere and FTP. I FTP updates to my
site, logon to their computer using PCANywhere, download the updates
to their computer and run the updates/installs. It can be painfuly
slow l at times, but it works, is cheap and is realively maintenance
free. It also has the side benefit of allowing you to actually see
the exact problem that they are trying to describe over the phone when
troubleshooting.

Both pieces are key. PCAnywhere without the FTP is just too darn slow
over a 56K modem when transfering large files, zipped or not, and as
you pointed out FTP doesn't allow you to access to their end without
physically being in their office.

HTH

Tom

[Tony Toews]

Steve Schapel <sc*****@mvps.org.ns> wrote:

"They" don't need to FTP files down. You can FTP files into their
system for them via your TS connection.

Right.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Tony Toews]

Tony Toews <tt****@telusplanet.net> wrote:

From thier system FTP from some FTP site somewhere to their
server.

Replace with

While TSed into their system FTP from some FTP site somewhere to their server.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Steve Schapel]

I only have a TS relationship with one of my clients. In this case, I
can use IE to FTP directly back and forth from my computer to their
server, (or more accurately, a specific folder on their server),
without the need of a two-step process.

- Steve
On Mon, 22 Sep 2003 23:53:48 GMT, Tony Toews <tt****@telusplanet.net>
wrote:

While TSed into their system FTP from some FTP site somewhere to their server.

Tony

[Dimitri Furman]

On Sep 22 2003, 08:32 pm, Chuck Grimsby
<c.*******@worldnet.att.net.invalid> wrote in
news:mk********************************@4ax.com:

I've had too many problems using a Access FE
to SQL Sever BE over a VPN network.

Hi Chuck,

What kind of problems did you have? Were they related to limited bandwidth
or of a different nature? What kind of bandwidth did you have available?
Was it a bound app?

I might have to implement something like this, so would appreciate if you
could share your experiences. Thanks.

--
(remove a 9 to reply by email)

[Dimitri Furman]

On Sep 23 2003, 07:44 pm, Chuck Grimsby
<c.*******@worldnet.att.net.invalid> wrote in
news:nn********************************@4ax.com:

On 23 Sep 2003 04:10:54 GMT, Dimitri Furman <df*****@cloud99.net>
wrote:

On Sep 22 2003, 08:32 pm, Chuck Grimsby
<c.*******@worldnet.att.net.invalid> wrote in
news:mk********************************@4ax.co m:

I've had too many problems using a Access FE to SQL Sever BE over a
VPN network.

What kind of problems did you have? Were they related to limited
bandwidth or of a different nature? What kind of bandwidth did you
have available? Was it a bound app?
I might have to implement something like this, so would appreciate if
you could share your experiences. Thanks.

(Sorry for the late reply on this. I thought I had hit send this
morning, but apparently I hit save instead.)

For what it's worth, I wrote:

"I can't say as I've had too many problems using a Access FE
to SQL Sever BE over a VPN network."

The "I can't say" part is small too be sure, but it's important!
<Grin>

<snip>

Thanks Chuck, that was very helpful, and sorry for oversnipping <g>
For SQL Server back-ends I prefer to use unbound forms, and code
intensive front-ends. Usually, no linked tables or queries at all and
DSN-less, Trusted connections. (Users who figure out how to see the
"Tables" window discover that there's nothing there!) ADO over DAO
although in most cases the speed difference between ADO and DAO is
almost invisible. I also try and move as much processing as I can to
the server, so that as little as possible has to come over the
wire(s). Stored Procedures to do the more complex stuff, although I
do tend to do a lot of code out of habit.
Same here, all communication is via ADO, DAO for local storage, if any,
most processing via stored procedures.
I like to "pre-load" things like combo boxes and list boxes whenever
possible, turning them from table/query based, to value lists
populated by a query in the Form Load event. It makes the forms
slower to load, but faster to use. Once open, they usually don't have
to be closed again, and that makes the app faster as well. (They hide
well however!)
I like to get an ADO recordset on startup of a form, disconnect it, and
bind it to combo/list. No need to change the code when lookup tables
change.
I avoid the use the subforms, continuous forms, datasheets, etc. like
the plague! But I should mention that I do that in all my apps, not
just the SQL Server ones. (The last time I mentioned that I got
blasted by other members of the group here. I remember the last
discussions on it people, no need to repeat them.) Personally, I just
don't like the "look and feel" of such things, but in "remote"
databases such things lock more records then are really needed and
tend to do nothing but slow things down. Users may want to *see* a
bunch of records, but they are only going to work with 1 regardless of
how many are on the screen. A unbound list box takes care of that,
and won't lock the records.

Not to start that discussion again <g>, but binding a disconnected ADO
recordset to those things solves a lot of the issues with locking and such.
I do show a single record for editing though.

--
(remove a 9 to reply by email)

[paii]

The problem is trying to use a JET backend on the server. I agree there
should be no problem with a SQL server backend.

"Chuck Grimsby" <c.*******@worldnet.att.net.invalid> wrote in message
news:mk********************************@4ax.com...

Depends. I can't say as I've had too many problems using a Access FE
to SQL Sever BE over a VPN network. I've updated quite a number of
client's FE's (Forms, Reports, Queries, Modules, etc.) using
automation over the VPN as well (as I mentioned in my previous post).

Neither TS or Citrix were required for either operation.

I'm not certain exactly what problems with this methodology you've
experienced are without more information, all I can say is that it's
worked well for me.
On Mon, 22 Sep 2003 09:48:43 -0500, "paii" <pa**@packairinc.com>
wrote:

Access FE/BE over a VPN with the FE on the remote and the BE on the server

will be very slow and possibly unreliable. I have Access on Windows 2000 TSwith Citrix using the VPN to make the remote terminal connection. This keepsthe FE/BE on the same network.
Be aware that TS is expensive and Access pushes the server hard. Treat eachAccess users as a power user when sizing the server.

"Chuck Grimsby" <c.*******@worldnet.att.net.invalid> wrote in message
news:0q********************************@4ax.com.. .

Wrong technology, Mike. TS is for remote control of a PC. What you
need is a VPN (Virtual Private Network) so you can link the drives on
your system to those on the other system.
Is it do able? Yes! I've used it quite a number of times. There are
a number of ports that will need to be opened in your NAT box and at
the client's Firewall (which ones will depend upon the VPN you
choose), but that's not really a huge task. (Changing the Network
Admin's thoughts on this tends to be the hardest part!)

On Sun, 21 Sep 2003 08:41:32 +0100, "Mike MacSween"
<mi******************@btinternet.com> wrote:
>Sorry, not enough info there was there? The clients have a cable
>connection,
>always on and a single server, not a dedicated db fileserver. They're
>behind
>a firewall, though I don't know anything about it. They have part time
>sysadmin who comes in as required. I'm on a DSL connection here, behind >NAT.
>When I can afford it I'll probably get a firewall so I can have a
>permanent IP."Mike MacSween" <mi******************@btinternet.com> wrote in message
>news:3f*********************@pubnews.gradwell.net ...
>> Sorry if this is a bit off topic, but I can't seem to find a 'remote
>> control' newsgroup on my news server. And anyway I know Tony has some >> experience of this.
>> The app is split FE/BE. I'd like remote access to at least the server, >> hopefully the whole network. And to be able to upload/download, to
>> install
>> new versions of the FE to the server (which then get sent up to the
>> clients at runtime).
>> What experience does anybody have of this. Is this doable via TS? There >> doesn't seem to be any FTP feature in RDP, or have I missed it?

--
Copywight 1994 Ewmer Fudd. All Wights Wesewved. Heheheh...

[David W. Fenton]

c.*******@worldnet.att.net.invalid (Chuck Grimsby) wrote in
<nn********************************@4ax.com>:

I avoid the use the subforms, continuous forms, datasheets, etc.
like the plague! But I should mention that I do that in all my
apps, not just the SQL Server ones. (The last time I mentioned
that I got blasted by other members of the group here. I remember
the last discussions on it people, no need to repeat them.)
Personally, I just don't like the "look and feel" of such things,
but in "remote" databases such things lock more records then are
really needed and tend to do nothing but slow things down. Users
may want to *see* a bunch of records, but they are only going to
work with 1 regardless of how many are on the screen. A unbound
list box takes care of that, and won't lock the records.

I don't want to rehash the old discussion, but short lists (<100
records) are very much a needed feature in any application.
Single-attribute lists can be presented in an unbound form with
listboxes. But once you get to several attributes that can become
unwieldy. Also, if you edit a record that has been presented in a
listbox, you still have to hit the server to update the unbound
list.

Have you looked into disconnected recordsets in ADO? I haven't used
them myself, but the whole point of them is to address precisely
the problem you are raising.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

c.*******@worldnet.att.net.invalid (Chuck Grimsby) wrote in
<8m********************************@4ax.com>:

Comments in-line...

On Wed, 24 Sep 2003 16:12:00 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote:

c.*******@worldnet.att.net.invalid (Chuck Grimsby) wrote in
<nn********************************@4ax.com>:

I avoid the use the subforms, continuous forms, datasheets, etc.
like the plague! But I should mention that I do that in all my
apps, not just the SQL Server ones. (The last time I mentioned
that I got blasted by other members of the group here. I
remember the last discussions on it people, no need to repeat
them.) Personally, I just don't like the "look and feel" of such
things, but in "remote" databases such things lock more records
then are really needed and tend to do nothing but slow things
down. Users may want to *see* a bunch of records, but they are
only going to work with 1 regardless of how many are on the
screen. A unbound list box takes care of that, and won't lock
the records.

I don't want to rehash the old discussion, but short lists (<100
records) are very much a needed feature in any application.
Agreed, but so are long lists. . . .

I disagree with that in regard to UI implementation. You should
never present more than 100 or so items to a user, and any time
you're presenting more than 10 or so, you must have a clear
organizational principle for ordering them that is organic to the
kind of data you're presenting (e.g., invoices should be in invoice
number or date/reverse date order).
. . . What is optimal (for a list box)
seems to depend on the application, so I'd rather not put a number
on it.

Well, I think the issue is lists, not widget, and it doesn't really
make any difference whether it's a subform or a listbox or a combo
box -- more than 100 is something you should design around. I won't
go into the details of how to do that, as it's been discussed a
great deal in the newsgroup. But I will say that it's a pretty
important principle for designing not just user-friendly UIs, but
also helps you to be efficient with resources, since you won't be
dragging lots of unnecessary data across the wire.
Single-attribute lists can be presented in an unbound form with
listboxes. But once you get to several attributes that can become
unwieldy.

I can't say as I've had many problems working with multi-column
list boxes myself, David. As I mentioned earlier, I often use code
or a Stored Procedure to do most of the work for me so perhaps
that's part of it? No idea.

It's not the data retrieval part of it that is problematic. It's
the presentation that I have problems with, and the updatability of
it once you've edited a record in a detail form and then need to
refresh the listbox that displays the same data in the list
version.

Also, if you edit a record that has been presented in a
listbox, you still have to hit the server to update the unbound
list.

That will rather depend upon *how* you populate the list box. If
you use a "User-Defined Function" to populate the list box (or
combobox for that matter, although I've never had a need to use a
UDF on a combo box), there's no need to hit up the server at all
once you're past the initial load. The UDF can update the list
box without the need to link up at all. (Admittedly however, I
usually do though. It gives me and the user some confidence that
whatever they did actually happened.) There's a fairly good
example of using a User-Defined Function in Access help if you
want to give it a try. *Really* nice for long lists of
information, like progress and error reports!

But for multi-column lists of any number of rows, a UDF is far, far
slower than SQL. Yes, I've used UDFs because sometimes what you
need to display can't be done with SQL (or, not efficiently).

But I don't see how that's a fix -- the data still must be
retrieved, it still needs to be refreshed. It's a hit on the back
end, and that's what you were worrying about causing you to avoid
continuous forms.

Have you looked into disconnected recordsets in ADO? I haven't
used them myself, but the whole point of them is to address
precisely the problem you are raising.

I have, and I've used them, I just prefer the other methods. It
isn't a problem however. I should also note that List Boxes are
also rather nice for those cases where the user has to do updates
to multiple records. They can select which records to update
(including the whole screen) and just click on one button, rather
then scrolling through multiple screens of records in a 'hit and
miss' methodology. With a list box they only 'touch' the records
they need to, and don't touch the records they don't need to at
all, regardless if they've narrowed down the selection enough.

That would be a good justification for it, yes, I agree.

But I still don't see any reason to avoid continuous subforms, none
whatsoever.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc