Access across the WAN

[Larry Linson]

. . . I have to wonder if the DAP situation
has been misunderstood, as well. I can't see
why they'd support A2K3-format MDBs for
replication and ULS but *not* support A2K3-
format DAPs.

I don't even bother to speculate, usually, about "why" questions --
particularly when they relate to inclusion or exclusion of features and
functions. I've worked in a megacorp that produced software, and even
knowing background, some of those decisions didn't make any sense to me.

As I haven't personally used, nor had a client who was interested in using,
DAPs, I just took the blog at what I perceive to be "face value."

DAPs never seemed quite "finished" to me, and their limitations are such
that they certainly didn't seem to create any "groundswell of enthusiasm"
among users -- their using vbscript instead of VBA was one of the stumbling
blocks (observed with my clients, and in the user groups with which I am
associated). If they'd been enthusiastically supported by users, that might
have made a difference.

Larry Linson
Microsoft Access MVP

 

[John Nurick]

Then Tom's patience must exceed mine and that of my users!

I worked on a project with some remote users on a WAN attaching to an
Informix database via a 256KB leased line. I feel certain that they
periodically had sweep the facilities to remove the remains of those users
who had died of boredom waiting for response. There was a significant, and
very believable, increase in the users' happiness when their employer
upgraded the WAN to a T-1 connection.

I just can't imagine "adequate" performance at 28KB, or 56KB which in the US
is limited to actually 53KB, (or even 128KB ISDN) after hearing the moans
and groans from those users.

AIUI Tom only achieves those results by going to a lot of trouble to
minimise the amount of information going up and down the line. I got the
impression it was all unbound forms with VBA code to craft SQL queries
to return the smallest possible datasets. On that basis, and assuming
that the work was mostly gentle looking-up and data entry (e.g. a depot
or small company store), you may normally only need to transfer a few
kilobytes per user per minute - so a shared dial-up connection isn't
unimaginable.

 

[aaron.kempf]

you can do Access Data Projects across a WAN quite well.

MDB is obsolete; you can't really run it across ANY network

-aaron

 

[aaron.kempf]

Larry

MDB sucks across all networks... SQL Server works great across lots of
different networks.

Isn't there a wizard to upgrade your MDB to ADP?

ROFL

 

[aaron.kempf]

Larry

yeah.. DAP are a pretty SWEET solution

maybe you should broaden your horizons and stop being a 1-trick pony
lol


I used them for a couple of pretty complex finance / budgeting apps..
basically spreadsheet replacement

Of course; using MDB with DAP is laughable; you should use ADP with
DAP; it's a great environment; but for sure-- hard to dive into

-aaron

 

[Tony Toews]

Then Tom's patience must exceed mine and that of my users!

<chuckle>

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]

But Windoes Terminal Server is by far the *easiest* solution for a
WAN.

True enough. Although it does depend on how complex the app and how
much work it would be to upsize it to SQL 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

 

[Larry Linson]

AIUI Tom only achieves those results by going to a lot of trouble to
minimise the amount of information going up and down the line. I got the
impression it was all unbound forms with VBA code to craft SQL queries
to return the smallest possible datasets. On that basis, and assuming
that the work was mostly gentle looking-up and data entry (e.g. a depot
or small company store), you may normally only need to transfer a few
kilobytes per user per minute - so a shared dial-up connection isn't
unimaginable.

Tom is very, very sharp with SQL.

And, the fact is, that our client wanted to spend all their money on
increased features and function, and would not invest in changes to improve
performance, in the case I described. Still, I would regard it as a
significant challenge to do an Access client - server DB over a dialup
connection!

 

[aaron.kempf]

it works like a charm with ADP

MDB is for chipmunks and retards

 

[David W. Fenton]

True enough. Although it does depend on how complex the app and
how much work it would be to upsize it to SQL Server.

No, WTS is *still* far, far simpler and faster, as all you have to
do is set up the Terminal Server and you're done. You don't need to
do anything at all to your app to deploy it on Terminal Server. For
most organizations that are big enough to use a WAN, having a
Windows server that can be used as a Terminal Server is not a big
deal.

 

[aaron.kempf]

yeah except that you have to buy WTS LICENSES you lazy assholes
MDB across terminal is laughable

ADP can run anywhere you want it -- across the public internet - with
or without a VPN.

MDB can't run across half of the networks because they're either wired
or wireless

MDB is for retards; lose the training wheels kids

-Aaron

 

[aaron.kempf]

for most people WITH A CLUE; moving to ADP is 'no big deal'

-Aaron

 

[aaron.kempf]

Larry
im so sorry that you had a bad experience with MDB / Informix

maybe you should have lost the training wheels and used SQL Server /
ADP 10 years ago; maybe?

I started using it in the fall of '99

-Aaron

 

[Tony Toews]

No, WTS is *still* far, far simpler and faster, as all you have to
do is set up the Terminal Server and you're done. You don't need to
do anything at all to your app to deploy it on Terminal Server. For
most organizations that are big enough to use a WAN, having a
Windows server that can be used as a Terminal Server is not a big
deal.

Yeahbut <smile> ... If they don't have a Terminal Server setup then
the licensing costs can be significant.

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]

AIUI Tom only achieves those results by going to a lot of trouble to
minimise the amount of information going up and down the line.

Good point. Yes, he is quite an expert on SQL queries.

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

 

[aaron.kempf]

and he's using SQL not Access.. RIGHT?

MDB is for losers

it doesn't run across ANY network without disclaimers and excuses and
workarounds.

keep your DATA in a DATABASE instead of leaving it on the side of the
road.

-Aaron

 

[David W. Fenton]

Yeahbut <smile> ... If they don't have a Terminal Server setup
then the licensing costs can be significant.

You'd have to have a huge number of CALs at $40 each before it adds
up to the cost of porting your app to use SQL Server for the back
end. Even adding in the cost of setting up a brand-new box to be a
terminal server you're still only talking a few thousand dollars.
That doesn't get you very far at all in realistically converting an
Access app to use a SQL Server back end over a WAN.

 

[aaron.kempf]

porting is free, so is sql... wuss

You'd have to have a huge number of CALs at $40 each before it adds
up to the cost of porting your app to use SQL Server for the back
end. Even adding in the cost of setting up a brand-new box to be a
terminal server you're still only talking a few thousand dollars.
That doesn't get you very far at all in realistically converting an
Access app to use a SQL Server back end over a WAN.