Is mdb safe to travel through vpn?

[David W. Fenton]

And Tom's good at that. He once told us he had a Access FE talkng
to a SQL Server BE via dialup connection.

But I wouldn't say it's good advice for a general Access newsgroup.
The vast majority of readers of these posts would not have the chops
to design such an app.

(which, of course, in no way questions Tom's ability to do so -- the
point is that you have to have special skills and understanding to
do it because it works against all the default setup of Access)

 

[Arvin Meyer [MVP]]

If you're connecting by VPN, you're already local, so there is no
need for an outward-facing IP address.

That is, unless your VPN is not a direct connection to the LAN you
need to get to. In that case, though, I don't see how you're getting
to the workstation, unless there's some form of IP or port
redirection on the Internet-facing router.

There is, not not being the administrator, I can't tell you how he did it.

If connecting via VPN, I can't understand why you would be worrying
about external IP addresses. The whole point of a VPN is that it's a
secure tunnel to a protected port available on the Internet. Once
you've connected, the usual configuration of a VPN is that you now
have an IP address local to the inside of the LAN, and have all the
LAN addresses available to you.

And your explanation doesn't account for how you get to the
workstation from outside the LAN.

I get to the workstation with a VPN to it's fixed IP address. One other
thing: Not being the only administrator on the network, I didn't set the
password. I think the admin password was 8 or 10 characters. It was as
secured as that can be having all 4 parameters (upper and lower case,
numerals, and special characters) but anything less than 15 characters can
be cracked relatively easily. My workstation password was a 28 character
pass-phrase, which is essentially uncrackable without a teraflop processor.
Everyone thought I was crazy, but I had the only password that hasn't been
cracked (at least yet).

 

[Todos Menos [MSFT]]

Performance, Ease of Maintenance, Ease of Development, code reuse,
extensibility?

ADP solves problems like yours without trying

 

[Todos Menos [MSFT]]

ADP doesn't work 'against all the default seup of Access'

the default setup of Access does NOT involve linked tables and
frontend / backend

ADP is considerably easier for newbies than MDB is



it's just that the old crotchety MDB dorks around here are too fat and
lazy to learn ADO

ADO is always faster BECAUSE MDB is not reliable enough for a single-
user application

 

[Todos Menos [MSFT]]

David

ADP pulls the RESULTS

MDB scans the whole table at the client side

ADP pulls DATA
MDB pulls a FILE

it's an order of magnitude better architecture

 

[Todos Menos [MSFT]]

the chops to build an ADP?


ADP is _EASIER_ than MDB

instead of teaching people linked table crap and refresh, reconnect
and connection strings?

action queries in ADP are more powerful than action queries in MDB
you've still got insert, update, append, delete

but then you've got things like table variables and triggers and real
constraints--

ADP is a much much better architecture

I'm sorry that newbies like Tony Toews don't have the balls to learn
ADP
it doesn't mean that it's not the right solution for a newbie

Tony is hard to teach because he is fat and lazy and retarded

I for one--- state that ADP is easier to use than MDB for a variety of
reasons

Queries don't just 'crap out'
and there are a plethora of professional-level tools like SQL Server
Management Studio express that are head and shoulder above Access QBE
window

 

[Tony Toews [MVP]]

A a r o n K e m p f wrote:

Note that this person is really A a r o n K e m p f and that he is not an employee
of Microsoft.

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 [MVP]]

We once connected two computers with a serial cable as a network and ran the
test of our application. While not VPN, this allowed us to see just how
much bandwidth was needed for "data entry," i. e. forms.

We started dropping the baud rate: 38400, 19200, 9600, 4800, 2400. At 2400
we could begin to see some sluggishness, but it was definitely usable for
data entry.

Ah, I stand corrected.

Thanks, 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

 

[Tom Ellison]

Dear David:

The differences are dramatic. With MSDE, the text of a query is sent to the
server or just the name of a view or procedure to be run, possibly with
parameters. All the processing happens on the server, which then returns
only the finished results.

With Jet, the local machine makes requests for rows of data it wishes to
examine. In extreme cases, a table scan may result in entire tables being
sent across the network. Over a connection with a low bandwidth and some
latency in the connection, it can really take a great deal of time.

Each time a "transaction" occurs between the workstation and the server, the
latency of the connection is involved in both directions. If such a latency
is 3 seconds each way, it will add 6 seconds to a MSDE response. If there
are 1000 round trips with a Jet query, it will add nearly an hour. I
guarantee you, I've watched it happen, complete with blinking lights on the
cable modem.

Tom Ellison
Microsoft Access MVP

 

[David W. Fenton]

The differences are dramatic. With MSDE, the text of a query is
sent to the server or just the name of a view or procedure to be
run, possibly with parameters. All the processing happens on the
server, which then returns only the finished results.

With Jet

That wasn't my question. I was talking ADP->MSDE/SQL Server vs.
MDB->MSDE/SQL Server. Everyone already understands that Jet can't be
as efficient as a server back end.

But I'm only addressing the front end question, since you brought up
ADP.

 

[David W. Fenton]

ADP solves problems like yours without trying

What problems am I having, Aaron?

 

[Tom Ellison]

Dear David:

OK, sorry. Not so much difference in which FE design tool you choose.

Tom Ellison
Microsoft Access MVP

 

[Arvin Meyer [MVP]]

MDBs will always use JET, but connecting JET to a SQL-Server back-end is the
difference. If you use JET queries, they will always be slower. But if you
use Pass-thrus so that the Server is returning a reduced recordset, the
difference is slight. The advantage of using the JET overlay to SQL-Server
is that you can run a local JET query on top of a SQL-Server pass-thru. Why
would you want to do that? Well, JET has some real advantages in that it can
resolve VBA functions. So, say you have a couple of hundred thousand rows of
data. Use a Pass-thru to SQL-Server to return the 10 rows you need, then run
a JET query on top of that (locally) to return your final result. Best of
both worlds.

It's not that JET is slow, it's that a WAN is slow and JET must return at
least the indexes of the entire table(s) to work. I personally find that
ADPs are often the easiest way to get and write SQL-Server data from a
front-end. Because of the amount of local processing that is done with VBA,
however, I invariably use MDBs for a lot of my reporting.

Still, the most users I've ever had on a WAN is 15, and I find that a
Terminal Server with Jet is still easier for the smaller databases (under a
couple of hundred MBs, that I build). For MSDE/SQL-Express where the engine
is free, the ROI is still often with an MDB because of the faster (generally
30 to 50%) development times. But with the full cost of a SQL-Server
license, the ROI is almost always with the MDB/JET solution.

 

[Todos Menos [MSFT]]

Tom

I call bullshit on this.

A linked MDB file to SQL Server? It pulls more data than it needs.

Writing a hundred pages of code in order to update a SQL passthrough
definition?
RIDICULOUS

ADP work over any network

MDB is for fucking babies

Dear David:

OK, sorry. Not so much difference in which FE design tool you choose.

Tom Ellison
Microsoft Access MVP

That wasn't my question. I was talking ADP->MSDE/SQL Server vs.
MDB->MSDE/SQL Server. Everyone already understands that Jet can't be
as efficient as a server back end.

But I'm only addressing the front end question, since you brought up
ADP.

 

[Todos Menos [MSFT]]

re:
Still, the most users I've ever had on a WAN is 15, and I find that a
Terminal Server with Jet is still easier for the smaller databases


ADP is always easier to implement than Terminal Server

you kids need to go back to school and get a degree in MIS in order to
be able to calculate the ROI for a stodgy 'Terminal Services'
application

how much does it slow down your end users?
how much of a pain in the ass is it?
how much does the additional server cost?
how much do the terminal server licenses cost?

MDBs will always use JET, but connecting JET to a SQL-Server back-end is the
difference. If you use JET queries, they will always be slower. But if you
use Pass-thrus so that the Server is returning a reduced recordset, the
difference is slight. The advantage of using the JET overlay to SQL-Server
is that you can run a local JET query on top of a SQL-Server pass-thru. Why
would you want to do that? Well, JET has some real advantages in that it can
resolve VBA functions. So, say you have a couple of hundred thousand rows of
data. Use a Pass-thru to SQL-Server to return the 10 rows you need, then run
a JET query on top of that (locally) to return your final result. Best of
both worlds.

It's not that JET is slow, it's that a WAN is slow and JET must return at
least the indexes of the entire table(s) to work. I personally find that
ADPs are often the easiest way to get and write SQL-Server data from a
front-end. Because of the amount of local processing that is done with VBA,
however, I invariably use MDBs for a lot of my reporting.

Still, the most users I've ever had on a WAN is 15, and I find that a
Terminal Server with Jet is still easier for the smaller databases (under a
couple of hundred MBs, that I build). For MSDE/SQL-Express where the engine
is free, the ROI is still often with an MDB because of the faster (generally
30 to 50%) development times. But with the full cost of a SQL-Server
license, the ROI is almost always with the MDB/JET solution.
--
Arvin Meyer, MCP, MVPhttp://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com

That wasn't my question. I was talking ADP->MSDE/SQL Server vs.
MDB->MSDE/SQL Server. Everyone already understands that Jet can't be
as efficient as a server back end.

But I'm only addressing the front end question, since you brought up
ADP.

 

[Todos Menos [MSFT]]

re:But with the full cost of a SQL-Server
license, the ROI is almost always with the MDB/JET solution.

WRONG ANSWER KID


do the fucking math, newbie

MDBs will always use JET, but connecting JET to a SQL-Server back-end is the
difference. If you use JET queries, they will always be slower. But if you
use Pass-thrus so that the Server is returning a reduced recordset, the
difference is slight. The advantage of using the JET overlay to SQL-Server
is that you can run a local JET query on top of a SQL-Server pass-thru. Why
would you want to do that? Well, JET has some real advantages in that it can
resolve VBA functions. So, say you have a couple of hundred thousand rows of
data. Use a Pass-thru to SQL-Server to return the 10 rows you need, then run
a JET query on top of that (locally) to return your final result. Best of
both worlds.

It's not that JET is slow, it's that a WAN is slow and JET must return at
least the indexes of the entire table(s) to work. I personally find that
ADPs are often the easiest way to get and write SQL-Server data from a
front-end. Because of the amount of local processing that is done with VBA,
however, I invariably use MDBs for a lot of my reporting.

Still, the most users I've ever had on a WAN is 15, and I find that a
Terminal Server with Jet is still easier for the smaller databases (under a
couple of hundred MBs, that I build). For MSDE/SQL-Express where the engine
is free, the ROI is still often with an MDB because of the faster (generally
30 to 50%) development times. But with the full cost of a SQL-Server
license, the ROI is almost always with the MDB/JET solution.
--
Arvin Meyer, MCP, MVPhttp://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com

That wasn't my question. I was talking ADP->MSDE/SQL Server vs.
MDB->MSDE/SQL Server. Everyone already understands that Jet can't be
as efficient as a server back end.

But I'm only addressing the front end question, since you brought up
ADP.

 

[Todos Menos [MSFT]]

re:
For MSDE/SQL-Express where the engine
is free, the ROI is still often with an MDB because of the faster
(generally
30 to 50%) development times.


Development time is BETTER for MDB?

ROFL

do you have query analyzer?


can you write a single sproc that runs 20 SQL statements?

lose the friggin training wheels; ADP development is considerably
easier than MDB
we don't need to deal with linked tables, changing SPT, we don't need
the Auto FE Updater-- what a fucking retarded name

we don't need to write DAO
we don't need to worry about crap on users machines

we don't need to fumble with a library that hasn't been included with
Office, Windows or MDAC in the past decade (DAO)

you MDB newbie kids are just plain fucking too stupid to learn how to
write SQL Server

you kids should be drinking wine on the side of the road, 'WILL MDB
FOR FOOD'

**** YOU GUYS FOR SPREADING LIES
**** YOU GUYS FOR BEING TOO STUPID TO LEARN ADP
**** YOU GUYS FOR HAVING THE AUDACITY TO THINK THAT MDB IS _CHEAPER_?

ROFL

WHAT A RIDICULOUS STATEMENT

Dev is _NOT_ easier
Dev is _NOT_ cheaper

lose the fucking training wheels you newbie retards

JET IS DEAD
AND NO ONE CARES

IF THERE WAS A HELL
I WOULD SEND MICROSOFT THERE

MDBs will always use JET, but connecting JET to a SQL-Server back-end is the
difference. If you use JET queries, they will always be slower. But if you
use Pass-thrus so that the Server is returning a reduced recordset, the
difference is slight. The advantage of using the JET overlay to SQL-Server
is that you can run a local JET query on top of a SQL-Server pass-thru. Why
would you want to do that? Well, JET has some real advantages in that it can
resolve VBA functions. So, say you have a couple of hundred thousand rows of
data. Use a Pass-thru to SQL-Server to return the 10 rows you need, then run
a JET query on top of that (locally) to return your final result. Best of
both worlds.

It's not that JET is slow, it's that a WAN is slow and JET must return at
least the indexes of the entire table(s) to work. I personally find that
ADPs are often the easiest way to get and write SQL-Server data from a
front-end. Because of the amount of local processing that is done with VBA,
however, I invariably use MDBs for a lot of my reporting.

Still, the most users I've ever had on a WAN is 15, and I find that a
Terminal Server with Jet is still easier for the smaller databases (under a
couple of hundred MBs, that I build). For MSDE/SQL-Express where the engine
is free, the ROI is still often with an MDB because of the faster (generally
30 to 50%) development times. But with the full cost of a SQL-Server
license, the ROI is almost always with the MDB/JET solution.
--
Arvin Meyer, MCP, MVPhttp://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com

That wasn't my question. I was talking ADP->MSDE/SQL Server vs.
MDB->MSDE/SQL Server. Everyone already understands that Jet can't be
as efficient as a server back end.

But I'm only addressing the front end question, since you brought up
ADP.

 

[Todos Menos [MSFT]]

ADPs are listed as Microsoft to be 'considerably faster than MDB for
reporting, specifically'


so seriously

you claim that ADP is better for forms

MS claims that ADP is better for repoting

YOU GUYS ARE BOTH WRONG, ADP IS BETTER AND EASIER AND FASTER FOR
EVERYTHING!

MDBs will always use JET, but connecting JET to a SQL-Server back-end is the
difference. If you use JET queries, they will always be slower. But if you
use Pass-thrus so that the Server is returning a reduced recordset, the
difference is slight. The advantage of using the JET overlay to SQL-Server
is that you can run a local JET query on top of a SQL-Server pass-thru. Why
would you want to do that? Well, JET has some real advantages in that it can
resolve VBA functions. So, say you have a couple of hundred thousand rows of
data. Use a Pass-thru to SQL-Server to return the 10 rows you need, then run
a JET query on top of that (locally) to return your final result. Best of
both worlds.

It's not that JET is slow, it's that a WAN is slow and JET must return at
least the indexes of the entire table(s) to work. I personally find that
ADPs are often the easiest way to get and write SQL-Server data from a
front-end. Because of the amount of local processing that is done with VBA,
however, I invariably use MDBs for a lot of my reporting.

Still, the most users I've ever had on a WAN is 15, and I find that a
Terminal Server with Jet is still easier for the smaller databases (under a
couple of hundred MBs, that I build). For MSDE/SQL-Express where the engine
is free, the ROI is still often with an MDB because of the faster (generally
30 to 50%) development times. But with the full cost of a SQL-Server
license, the ROI is almost always with the MDB/JET solution.
--
Arvin Meyer, MCP, MVPhttp://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com

That wasn't my question. I was talking ADP->MSDE/SQL Server vs.
MDB->MSDE/SQL Server. Everyone already understands that Jet can't be
as efficient as a server back end.

But I'm only addressing the front end question, since you brought up
ADP.

 

[Todos Menos [MSFT]]

Performance over a mother fucking wan

sharing queries
updating objects while other people are using them

uh.. stability
uh.. performance
uh.. reporting flexibility
uh.. troubleshooting (when MDB gets a profiler.. ROFL)
uh.. indexing (index tuning wizard and database tuning advisor are
better at indexing then you MDB jackasses)
uh.. reliability
uh.. rebooting a file server because your database is hung
uh.. DLL hell-- because DAO isn't included with anything anymore?

 

[Todos Menos [MSFT]]

ADP is always faster, easier, better
ADP is always faster, easier, better

you can use ADP to point to a hosted db server and presto chango--
you've got a solution