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

[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.*******@worl dnet.att.net.in valid> wrote in message
news:mk******** *************** *********@4ax.c om...

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**@packairin c.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.*******@worl dnet.att.net.in valid> 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************ ******@btintern et.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************ ******@btintern et.com> wrote in message
>news:3f******* **************@ pubnews.gradwel l.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.*******@world net.att.net.inv alid (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.*******@world net.att.net.inv alid (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.*******@wor ldnet.att.net.i nvalid (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