A good reason to use ADP's

[Jerry Boone]

A long time ago Larry Linson (MVP contributor to this group) made a point to
me that mdb's could do anything ADP's (Access Projects) could by using
linked tables to leverage Sql server databases. It's been years since then,
and I still sometimes think about that statement when evaluating the
usefulness of the ADP's I build. Larry and I discussed this technique and
he found it "Credible" (hope you don't mind me quoting you sir) so what the
hell... here it goes - this is for all you die-hard ADP guys (and gals of
course). I know there have been long, drawn out debates over the very
subject at hand, some I have read and been a participant... and perhaps this
recommendation of usage has even came to surface - however, I felt it had
not been mentioned before by the way Larry responded.

After working with ADP's since the birth of A2K, I have found many
advantages that suit me... but what about you? Please understand, this
thread is not an open invitation to bash ADP's (let's try something new),
but rather a constructive way to figure out what tricks people are using
that make them "valuable" - ok? So, without further delay... here is one
innovative trick out of my bag in which I have kept for myself for some
time... yours for free if it's new to you...

Note that ADP's connect to Sql Server using an OLEDB connection. This type
of connection can and will definitely span further than the local network,
in fact it can span to any IP Address that has port 1433 (Sql Server) open
and Sql Server/MSDE running. Perhaps the strongest advantage ADP's have in
my business is that I can deploy them to multiple locations while hosting
the database. For a monthly fee, customers get a managed database and do
not incur the expense of a server. This model simply fits the small branch
office scenario "like a glove". Then, using bound forms and intelligent
Stored Procedure design, I have a very tight, fast performing (by keeping
records down), rich, and believe it or not... a secure delivered ADE
application.

How many people have a website that uses a Sql Server database? If so, did
you know you can more than likely connect to it with Access as a Project and
do whatever you want with the database... as long as you have the
credentials? Most, if not all ISP's who host Sql Databases allow you to
connect with Enterprise Manager - you can use those same credentials to
connect your copy of Access. Work with Data, build new queries, build some
forms for maintaining data, deploy them as an alternative to building
complex, yet featureless web page based maintenance systems.

I believe this is new with AccessXP, but did you know that you can now link
many flavors of tables to ADP's? Yes, Paradox, dBase, MDB's, and any ODBC
or OLEDB accessible engine... to name a few. Look into it if you have a
need for this. You could always link some of these from Sql Server, but now
it's a right click and link option in table view.

Anyway - I hope this thread stays positive and uncovers some really good
features that ADP's provide to working developers.

Professional replies are appreciated.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access

[Rick Brandt]

"Jerry Boone" <je***@antech.biz.killspam> wrote in message
news:f0*******************@newssvr11.news.prodigy. com...

A long time ago Larry Linson (MVP contributor to this group) made a point to me that mdb's could do anything ADP's (Access Projects) could by using
linked tables to leverage Sql server databases. It's been years since then, and I still sometimes think about that statement when evaluating the
usefulness of the ADP's I build. Larry and I discussed this technique and he found it "Credible" (hope you don't mind me quoting you sir) so what the hell... here it goes - this is for all you die-hard ADP guys (and gals of
course). I know there have been long, drawn out debates over the very
subject at hand, some I have read and been a participant... and perhaps this recommendation of usage has even came to surface - however, I felt it had
not been mentioned before by the way Larry responded.

After working with ADP's since the birth of A2K, I have found many
advantages that suit me... but what about you? Please understand, this
thread is not an open invitation to bash ADP's (let's try something new),
but rather a constructive way to figure out what tricks people are using
that make them "valuable" - ok? So, without further delay... here is one
innovative trick out of my bag in which I have kept for myself for some
time... yours for free if it's new to you...

Note that ADP's connect to Sql Server using an OLEDB connection. This type of connection can and will definitely span further than the local network, in fact it can span to any IP Address that has port 1433 (Sql Server) open and Sql Server/MSDE running. Perhaps the strongest advantage ADP's have in my business is that I can deploy them to multiple locations while hosting
the database. For a monthly fee, customers get a managed database and do
not incur the expense of a server. This model simply fits the small branch office scenario "like a glove". Then, using bound forms and intelligent
Stored Procedure design, I have a very tight, fast performing (by keeping
records down), rich, and believe it or not... a secure delivered ADE
application.

How many people have a website that uses a Sql Server database? If so, did you know you can more than likely connect to it with Access as a Project and do whatever you want with the database... as long as you have the
credentials? Most, if not all ISP's who host Sql Databases allow you to
connect with Enterprise Manager - you can use those same credentials to
connect your copy of Access. Work with Data, build new queries, build some forms for maintaining data, deploy them as an alternative to building
complex, yet featureless web page based maintenance systems.

I believe this is new with AccessXP, but did you know that you can now link many flavors of tables to ADP's? Yes, Paradox, dBase, MDB's, and any ODBC or OLEDB accessible engine... to name a few. Look into it if you have a
need for this. You could always link some of these from Sql Server, but now it's a right click and link option in table view.

Anyway - I hope this thread stays positive and uncovers some really good
features that ADP's provide to working developers.

Professional replies are appreciated.

Two points:

My intent is not to "bash ADPs" and I don't doubt that many features of an
ADP make connection to a server over the internet easier, but you seem to
be saying that only ADPs have this ability. Everything you're describing
about connecting to a server over the internet can also be done with ODBC
and an MDB file.

One is not limited to Jet queries over linked tables just because they are
using an ODBC/MDB file. I had an app in use for several years that
connected to our SQL Server over the internet and found that even with a
dial-up connection that it was quite usable. That was an app that lent
itself to small data transactions and nearly all of it was done using
Stored Procedures and Pass-Throughs.

Point two is concerned with why I had to completely redesign that same app
a couple of years ago to get away from ODBC and switch to using HTTP
requests talking to Java servlets. The reason being that I was informed by
our networking admin that leaving port 1433 open to the internet was a huge
security problem. This opinion was nearly unanimously agreed upon when I
made some Newsgroup inquiries about it. If that is in fact true then I
wonder what benefit there is to what you're describing if it will by
definition be lacking proper security.

I agree that the ability in newer versions to link to sources other than
SQL Server is a big plus. That was the primary reason I had little
interest in them when I first looked at them in A2000.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Jerry Boone]

Thanks Rick - very professional. My answers to your respectable points are
these...

Connecting and deploying with ADP's...
File-Connection-Fill in parameters
At this point all Sql objects are local to the IDE for design change and
will reflect design changes made to the database without updating the ADE.
The database name can be changed any time to connect to a different database
using the connection parameters. For instance, the same accounting system
has 4 different companies with identical database structure, the user can
pick which company by changing this one option and the ADP will adhere
everything across the board.

Connecting and deploying with Jet...
Devise ini or reg entry to create dsn in ODBC with parameters
Start Linking tables
At this point linked tables are there, but the tables must be relinked and
possibly re-deployment of the mdb (remote location and options are limited)
if updates are done on the tables. The database name needs to be fixed, or
else more code and efforts must be installed.

My intent is to make nothing local but the code and Access objects. Also...
local storage, I use local xml and atdg files that update once on app start
for that - works great.

Security - *"A number of industry pundits (and I) feel that Jet security is
an oxymoron. It seems that there are dozens of ways to crack Jet database
security -- there are even some Web sites that will do it for a small fee.
If you're concerned with security, switch to MSDE or SQL Server where you
will be confronted with another whole set of security issues, but where it
is a whole lot easier to maintain overall security of your database." The
issues he mentions are concerning the overwhelming amount of choices. By
what he has written, I would say that using Jet makes SQL Server less
secure.

Sql Server port 1433 has had one security incident that was made known. My
systems were never effected by it for two reasons -- I only permit 1433 to
clients with static ip's (reputable businesses) and enter them into my
firewall. On more secure systems, I shift the port as well as work the
firewall specifics. Security is not for the novice - it's an evolutionary
phenomenon that changes as technology does. What was a unsafe yesterday, is
safe or at least safer today. These questions should be evaluated
periodically, not just once.

The linking of databases was possible before within Sql Server in 7.0.
* From William Vaughn's latest book on ADO best practices - page 41, last
paragraph.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:bt************@ID-98015.news.uni-berlin.de...

"Jerry Boone" <je***@antech.biz.killspam> wrote in message
news:f0*******************@newssvr11.news.prodigy. com...

A long time ago Larry Linson (MVP contributor to this group) made a point

to

me that mdb's could do anything ADP's (Access Projects) could by using
linked tables to leverage Sql server databases. It's been years since then,

and I still sometimes think about that statement when evaluating the
usefulness of the ADP's I build. Larry and I discussed this technique

and

he found it "Credible" (hope you don't mind me quoting you sir) so what

the

hell... here it goes - this is for all you die-hard ADP guys (and gals

of course). I know there have been long, drawn out debates over the very
subject at hand, some I have read and been a participant... and perhaps

this

recommendation of usage has even came to surface - however, I felt it had not been mentioned before by the way Larry responded.

After working with ADP's since the birth of A2K, I have found many
advantages that suit me... but what about you? Please understand, this
thread is not an open invitation to bash ADP's (let's try something new), but rather a constructive way to figure out what tricks people are using
that make them "valuable" - ok? So, without further delay... here is one innovative trick out of my bag in which I have kept for myself for some
time... yours for free if it's new to you...

Note that ADP's connect to Sql Server using an OLEDB connection. This

type

of connection can and will definitely span further than the local

network,

in fact it can span to any IP Address that has port 1433 (Sql Server)

open

and Sql Server/MSDE running. Perhaps the strongest advantage ADP's have

in

my business is that I can deploy them to multiple locations while hosting the database. For a monthly fee, customers get a managed database and do not incur the expense of a server. This model simply fits the small

branch

office scenario "like a glove". Then, using bound forms and intelligent
Stored Procedure design, I have a very tight, fast performing (by keeping records down), rich, and believe it or not... a secure delivered ADE
application.

How many people have a website that uses a Sql Server database? If so,

did

you know you can more than likely connect to it with Access as a Project

and

do whatever you want with the database... as long as you have the
credentials? Most, if not all ISP's who host Sql Databases allow you to
connect with Enterprise Manager - you can use those same credentials to
connect your copy of Access. Work with Data, build new queries, build

some

forms for maintaining data, deploy them as an alternative to building
complex, yet featureless web page based maintenance systems.

I believe this is new with AccessXP, but did you know that you can now

link

many flavors of tables to ADP's? Yes, Paradox, dBase, MDB's, and any

ODBC

or OLEDB accessible engine... to name a few. Look into it if you have a
need for this. You could always link some of these from Sql Server, but

now

it's a right click and link option in table view.

Anyway - I hope this thread stays positive and uncovers some really good
features that ADP's provide to working developers.

Professional replies are appreciated.

Two points:

My intent is not to "bash ADPs" and I don't doubt that many features of an
ADP make connection to a server over the internet easier, but you seem to
be saying that only ADPs have this ability. Everything you're describing
about connecting to a server over the internet can also be done with ODBC
and an MDB file.

One is not limited to Jet queries over linked tables just because they are
using an ODBC/MDB file. I had an app in use for several years that
connected to our SQL Server over the internet and found that even with a
dial-up connection that it was quite usable. That was an app that lent
itself to small data transactions and nearly all of it was done using
Stored Procedures and Pass-Throughs.

Point two is concerned with why I had to completely redesign that same app
a couple of years ago to get away from ODBC and switch to using HTTP
requests talking to Java servlets. The reason being that I was informed

by our networking admin that leaving port 1433 open to the internet was a huge security problem. This opinion was nearly unanimously agreed upon when I
made some Newsgroup inquiries about it. If that is in fact true then I
wonder what benefit there is to what you're describing if it will by
definition be lacking proper security.

I agree that the ability in newer versions to link to sources other than
SQL Server is a big plus. That was the primary reason I had little
interest in them when I first looked at them in A2000.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Larry Linson]

"Jerry Boone" wrote

A long time ago Larry Linson ... (hope you
don't mind me quoting you sir)

No, I don't mind at all, Jerry... I'm happy to see an enlightening technical
discussion.

I'm wondering how this fits with the Microsoft insiders' apparent current
agreement that "MDB-ODBC beats ADP-ADODB" -- maybe one of those insiders
will join in this discussion.

As Rick said, I knew you _could_ connect via the Internet with MDB-ODBC, but
I never thought it was practical from either a performance or a security
point of view. An open port to the Internet strikes me, as it apparently
struck Rick's admin friend, as a lot riskier than an open port on a LAN/WAN.

In my experience, Access clients using MDB-Jet-ODBC do not rely on Jet
security to any degree; it is the server database that provides the
security. A major app on which I worked off and on for several years had an
Access 2.0 client -- no MDE and security with a hole big enough to drive a
freight train through -- but the Informix server security was pretty good.

Larry Linson
Microsoft Access MVP

[David W. Fenton]

bo*****@localhost.not (Larry Linson) wrote in
<Xc*******************@nwrddc02.gnilink.net>:

"Jerry Boone" wrote

A long time ago Larry Linson ... (hope you
don't mind me quoting you sir)

No, I don't mind at all, Jerry... I'm happy to see an enlightening
technical discussion.

I'm wondering how this fits with the Microsoft insiders' apparent
current agreement that "MDB-ODBC beats ADP-ADODB" -- maybe one of
those insiders will join in this discussion.

As Rick said, I knew you _could_ connect via the Internet with
MDB-ODBC, but I never thought it was practical from either a
performance or a security point of view. An open port to the
Internet strikes me, as it apparently struck Rick's admin friend,
as a lot riskier than an open port on a LAN/WAN.

Well, wouldn't a VPN eliminate that issue? Why would anyone deploy
such a solution in any other fashion than with a VPN?

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

[Lyle Fairfield]

"Rick Brandt" <ri*********@hotmail.com> wrote in news:btcmfr$5mkg2$1@ID-
98015.news.uni-berlin.de:

Point two is concerned with why I had to completely redesign that same app
a couple of years ago to get away from ODBC and switch to using HTTP
requests talking to Java servlets. The reason being that I was informed by
our networking admin that leaving port 1433 open to the internet was a huge
security problem. This opinion was nearly unanimously agreed upon when I
made some Newsgroup inquiries about it. If that is in fact true then I
wonder what benefit there is to what you're describing if it will by
definition be lacking proper security.

The server administrator can set the port which the SQL server uses to
something other than the default 1433.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Rick Brandt]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.90.. .

bo*****@localhost.not (Larry Linson) wrote in
<Xc*******************@nwrddc02.gnilink.net>:

"Jerry Boone" wrote

A long time ago Larry Linson ... (hope you
don't mind me quoting you sir)

No, I don't mind at all, Jerry... I'm happy to see an enlightening
technical discussion.

I'm wondering how this fits with the Microsoft insiders' apparent
current agreement that "MDB-ODBC beats ADP-ADODB" -- maybe one of
those insiders will join in this discussion.

As Rick said, I knew you _could_ connect via the Internet with
MDB-ODBC, but I never thought it was practical from either a
performance or a security point of view. An open port to the
Internet strikes me, as it apparently struck Rick's admin friend,
as a lot riskier than an open port on a LAN/WAN.

Well, wouldn't a VPN eliminate that issue? Why would anyone deploy
such a solution in any other fashion than with a VPN?

On our LAN we only allow VPNs when used with SecuRemote software and whatever
you call that little device that changes pass numbers every 60 seconds. This is
limited to a handful of power users so they can do some work remotely. It would
have been a nightmare to set that up for the few hundred remote users that
connect to the database (I have my hands full enough just getting an Access app
installed and running properly). As these remote users are independently
contracted, not employees, I'm not sure that setting them up with a network
profile would ever have been given serious consideration.

I was surprised by the security issue myself when it was raised. I had always
figured that SQL Server had "real" security and therefore could be trusted. The
fact that people think it is not safe when exposed to the internet implies to me
that it is not secure from users on our LAN either.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Albert D. Kallal]

"Jerry Boone" <je***@antech.biz.killspam> wrote in message
news:1D*****************@newssvr24.news.prodigy.co m...

Connecting and deploying with Jet...
Devise ini or reg entry to create dsn in ODBC with parameters
Start Linking tables At this point linked tables are there, but the tables must be relinked and
possibly re-deployment of the mdb
No, you don't need to re-deploy the application at all.

And good developer will ALWAYS use a dsn-less connection.

In fact a few software places have the
question of how to make DSN less connection on the test
when they are hiring you for a VB, or ms-access
position!

Anyway, here is a nice piece of free code by Mr. Steele
that simply lets you enter the server name, and the database
name, and it re-links. So, you don't have to re-deploy
or do anything:

http://members.rogers.com/douglas.j....LessLinks.html

Now, the fact that we can set up code to link, and allow the database
and server name to be easily changed does not in any throw out your
point that it is easier to change the connection to a database
with a adp project. However, you most certainly can build a
JET to sql application, and have a means to easily change the
server name and database name.
Security - *"A number of industry pundits (and I) feel that Jet security is an oxymoron.
Sure, but both of us are not talking about using JET to store the data. We
are talking about placing data on properly secured sql server. The debate
is here not that a sever is more secure then is JET, but the debate is do
you get more security from a adp project to a sql server then do you with
JET to that same sql server?

I have not seen any real augments that would make a adp project more secure
then a JET odbc to that same sql server.
By what he has written, I would say that using Jet makes SQL Server less
secure.

Gee, I can't really say there any difference here. There is perhaps a few
issues in terms of where/how the table links to the server are stored,
but I would certainly need more debate on this one.

As mentioned, I do think for new projects that are destined to run with sql
server, a adp project is a great idea. It also forces all tables and data
to be on the server (this is *usually* a good thing!) With a JET based
system,
it is somewhat easer to put data on the client side! (so, forced all data
to be kept server side is not ALWAYS the ticket)!

In some discussions with developers I have seen some ultra low bandwidth
requirements for adp projects. I cannot say the same low bandwidth results
would be achieved with jet/odbc, but then again, I don't see why not.

Without question, sql server gives you MUCH better connectivity here.
However,
that ability extends to both JET/odbc and adp projects. In fact, using sql
server can be cheaper then using a Terminal Services to a jet file share on
a server! (so, in fact, usng sql server and a thick client (either adp, or
jet/odbc) can be used in place of termial services)).

If you are writing from day one with sql server in mind, or need correct
security,
then I do think that using a adp project makes sense. adp's also do as
you mention are more seamless with sql server.

After taking to some very happy developers who use adp projects, I in no way
want to discourage the use of adp projects . On the other hand, few of us
are giving up our lovely little JET engine either!
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
No************@msn.com
http://www.attcanada.net/~kallal.msn

[Albert D. Kallal]

"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:btdc5a$60skm$1@ID-

On our LAN we only allow VPNs
As David mentioned, for any type of connection to anything, a VPN quite
standard. Throw in the server authentication stuff, and it is quite good.

The fact that people think it is not safe when exposed to the internet
implies to me that it is not secure from users on our LAN either.

Well, the one big advantage of sql server is that it is integrated with
windows security. That means the same permissions that the domain server has
can also be used by sql server.

So, while that port is opened, the security settings do apply (well,
actually it
depends on how the sql server is setup, but sql server can use the users
logon).

However, this whole post of mine does bring up the point is a oleDB
connection to sql server (via a adp project) more secure then is jet/odbc
connection?

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
No************@msn.com
http://www.attcanada.net/~kallal.msn

[Jerry Boone]

DSN-less strings -- yes, good, I use them every time I open a connection.
Except with ADP's in which the current project connection can be reused.
The article you present is a nice way to re-link tables if the db name
changes, I had not entertained that thought. Still, as you point out - it's
not simply taken care of for you. The need for me to deploy mdb's no longer
exists, so there are some things that I am not razor sharp on.

On the security item - I will try to come up with some good technical info,
but I think you starting to ask the same questions I am after reading your
more recent post.

Starting from day one, with a Sql Server is the place for adp's -- however,
it's one handy tool in systems that have sql server and you just need to
quickly browse some data. I frequently have visited customer sites with Sql
accounting and mfg systems that have vb or c front ends. Nothing... makes
it easier to view and analyze the data than using a adp. It also is
invaluable when planning and building web applications from existing sql
server databases. The same applies of course to existing sql server web
databases located at the clients ISP. No linking required.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"Albert D. Kallal" <pl********************@msn.com> wrote in message
news:t7vKb.9472$hk.20@pd7tw1no...

"Jerry Boone" <je***@antech.biz.killspam> wrote in message
news:1D*****************@newssvr24.news.prodigy.co m...

Connecting and deploying with Jet...
Devise ini or reg entry to create dsn in ODBC with parameters
Start Linking tables

At this point linked tables are there, but the tables must be relinked and possibly re-deployment of the mdb

No, you don't need to re-deploy the application at all.

And good developer will ALWAYS use a dsn-less connection.

In fact a few software places have the
question of how to make DSN less connection on the test
when they are hiring you for a VB, or ms-access
position!

Anyway, here is a nice piece of free code by Mr. Steele
that simply lets you enter the server name, and the database
name, and it re-links. So, you don't have to re-deploy
or do anything:

http://members.rogers.com/douglas.j....LessLinks.html

Now, the fact that we can set up code to link, and allow the database
and server name to be easily changed does not in any throw out your
point that it is easier to change the connection to a database
with a adp project. However, you most certainly can build a
JET to sql application, and have a means to easily change the
server name and database name.

Security - *"A number of industry pundits (and I) feel that Jet security

is

an oxymoron.

Sure, but both of us are not talking about using JET to store the data. We
are talking about placing data on properly secured sql server. The debate
is here not that a sever is more secure then is JET, but the debate is do
you get more security from a adp project to a sql server then do you with
JET to that same sql server?

I have not seen any real augments that would make a adp project more

secure then a JET odbc to that same sql server.

By what he has written, I would say that using Jet makes SQL Server less
secure.
Gee, I can't really say there any difference here. There is perhaps a few
issues in terms of where/how the table links to the server are stored,
but I would certainly need more debate on this one.

As mentioned, I do think for new projects that are destined to run with

sql server, a adp project is a great idea. It also forces all tables and data
to be on the server (this is *usually* a good thing!) With a JET based
system,
it is somewhat easer to put data on the client side! (so, forced all data
to be kept server side is not ALWAYS the ticket)!

In some discussions with developers I have seen some ultra low bandwidth
requirements for adp projects. I cannot say the same low bandwidth results
would be achieved with jet/odbc, but then again, I don't see why not.

Without question, sql server gives you MUCH better connectivity here.
However,
that ability extends to both JET/odbc and adp projects. In fact, using sql
server can be cheaper then using a Terminal Services to a jet file share on a server! (so, in fact, usng sql server and a thick client (either adp, or
jet/odbc) can be used in place of termial services)).

If you are writing from day one with sql server in mind, or need correct
security,
then I do think that using a adp project makes sense. adp's also do as
you mention are more seamless with sql server.

After taking to some very happy developers who use adp projects, I in no way want to discourage the use of adp projects . On the other hand, few of us
are giving up our lovely little JET engine either!
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
No************@msn.com
http://www.attcanada.net/~kallal.msn

[David W. Fenton]

ri*********@hotmail.com (Rick Brandt) wrote in
<bt************@ID-98015.news.uni-berlin.de>:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.90. ..

bo*****@localhost.not (Larry Linson) wrote in
<Xc*******************@nwrddc02.gnilink.net>:

>"Jerry Boone" wrote
>
> > A long time ago Larry Linson ... (hope you
> > don't mind me quoting you sir)
>
>No, I don't mind at all, Jerry... I'm happy to see an
>enlightening technical discussion.
>
>I'm wondering how this fits with the Microsoft insiders'
>apparent current agreement that "MDB-ODBC beats ADP-ADODB" --
>maybe one of those insiders will join in this discussion.
>
>As Rick said, I knew you _could_ connect via the Internet with
>MDB-ODBC, but I never thought it was practical from either a
>performance or a security point of view. An open port to the
>Internet strikes me, as it apparently struck Rick's admin
>friend, as a lot riskier than an open port on a LAN/WAN.
Well, wouldn't a VPN eliminate that issue? Why would anyone
deploy such a solution in any other fashion than with a VPN?

On our LAN we only allow VPNs when used with SecuRemote software
and whatever you call that little device that changes pass numbers
every 60 seconds. This is limited to a handful of power users so
they can do some work remotely. It would have been a nightmare to
set that up for the few hundred remote users that connect to the
database (I have my hands full enough just getting an Access app
installed and running properly). As these remote users are
independently contracted, not employees, I'm not sure that setting
them up with a network profile would ever have been given serious
consideration.

It makes no sense to me to have a VPN so secure that nobody uses
it. A standard VPN would offer a higher level of protection to SQL
Server without requiring the extra software be used. Why would you
not use it?
I was surprised by the security issue myself when it was raised.
I had always figured that SQL Server had "real" security and
therefore could be trusted. The fact that people think it is not
safe when exposed to the internet implies to me that it is not
secure from users on our LAN either.

An open port that is a standard number is an invitation to hackers.
Any vulnerability of the software listening on that port is going
to be exposed to the world.

The reason why there's a difference between exposing it to the
Internet and exposing it on the LAN is because the people on the
LAN are authorized to be on the LAN. Is that not a gigantic
difference?

Of course, if you're just now coming to the conclusion that you
can't trust even your employees, well, D'OH!!!!

SQL Server security is NT security (unless you're using only SQL
Server's native security rather than relying on your domain
controller, which would make no sense to me), and NT Security is
breachable, though I would say it's pretty secure.

But do you really want to take the risk of having an open port
visible to everyone? Think of it this way:

What if your LAN was set up so that anyone could connect to your
network and see your SQL Server's open ports, whether they logged
onto your domain controller or not? Then, move that
non-authenticated user to the waiting room of your office, then out
to the lobby of your building, then out to the phone booth on the
corner. Having SQL Server sitting listening out on the Internet is
equivalent to exposing a part of your network to exactly that level
of vulnerability.

A standard VPN would be orders of magnitude safer.

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

[David W. Fenton]

pl******************@msn.com (Albert D. Kallal) wrote in
<t7vKb.9472$hk.20@pd7tw1no>:

Without question, sql server gives you MUCH better connectivity
here. However,
that ability extends to both JET/odbc and adp projects. In fact,
using sql server can be cheaper then using a Terminal Services to
a jet file share on a server! (so, in fact, usng sql server and a
thick client (either adp, or jet/odbc) can be used in place of
termial services)).

Well, what if you have a client with an Access/Jet application who
has neither SQL Server nor WTS set up. Which is cheaper and easier
to setup and which is cheaper and easier to administer? Which
requires more work to maintain? I'm pretty sure that WTS wins out
here and quite handily.

Now, if you're looking for other advantages that porting the app to
SQL Server would offer, or if you're designing the app from scratch
or if the app already uses SQL Server, the balance is completely
different. But you were suggesting that Access/Jet over WTS is more
difficult and more expensive than converting the app to SQL Server
and deploying that way. I strenuously disagree.

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

[Jerry Boone]

Yes, generally a VPN would be a clean way to permit a "more" secure port to
the client. I use this method with another customer and the only thing I
don't like about it is that I have to give them a certain degree of trust to
my domain. If they are allowed only a Sql Server auth login and have access
to a hot port - that's the only rope they can cling to.

BTW... is that stuff Don has posted about you really true? I have been
around the group long enough to know his style - no need to spend valuable
time explaining... an honorable yes, no, or no reply would do just fine.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.90.. .

bo*****@localhost.not (Larry Linson) wrote in
<Xc*******************@nwrddc02.gnilink.net>:

"Jerry Boone" wrote

A long time ago Larry Linson ... (hope you
don't mind me quoting you sir)

No, I don't mind at all, Jerry... I'm happy to see an enlightening
technical discussion.

I'm wondering how this fits with the Microsoft insiders' apparent
current agreement that "MDB-ODBC beats ADP-ADODB" -- maybe one of
those insiders will join in this discussion.

As Rick said, I knew you _could_ connect via the Internet with
MDB-ODBC, but I never thought it was practical from either a
performance or a security point of view. An open port to the
Internet strikes me, as it apparently struck Rick's admin friend,
as a lot riskier than an open port on a LAN/WAN.

Well, wouldn't a VPN eliminate that issue? Why would anyone deploy
such a solution in any other fashion than with a VPN?

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

[Jerry Boone]

Expense and conversion depends on the application. There are issues with
any application running on a terminal vs. locally. Any interactive needs
with the application like working with an autodialer, providing audio (most
of the time this doesn't work over terminal), faxing with a local modem (I
know network faxing is good - use it a lot, but some don't), and other
reasons like the simple reality of explaining to the user just what is going
on so they don't get confused as to what computer they are actually working
on. Oh, and the licenses.

The simplicity is sending one small 100k - 400k (range of size for some
forms and reports) adp file over email to an Access installed workstation,
having them open it and it flat out just works. Having peace of mind that
nothing in the connection will go wrong, and if it does... that it is a
firewall issue and not a code issue.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.74.. .

pl******************@msn.com (Albert D. Kallal) wrote in
<t7vKb.9472$hk.20@pd7tw1no>:

Without question, sql server gives you MUCH better connectivity
here. However,
that ability extends to both JET/odbc and adp projects. In fact,
using sql server can be cheaper then using a Terminal Services to
a jet file share on a server! (so, in fact, usng sql server and a
thick client (either adp, or jet/odbc) can be used in place of
termial services)).

Well, what if you have a client with an Access/Jet application who
has neither SQL Server nor WTS set up. Which is cheaper and easier
to setup and which is cheaper and easier to administer? Which
requires more work to maintain? I'm pretty sure that WTS wins out
here and quite handily.

Now, if you're looking for other advantages that porting the app to
SQL Server would offer, or if you're designing the app from scratch
or if the app already uses SQL Server, the balance is completely
different. But you were suggesting that Access/Jet over WTS is more
difficult and more expensive than converting the app to SQL Server
and deploying that way. I strenuously disagree.

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

[Rick Brandt]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.74.. .

It makes no sense to me to have a VPN so secure that nobody uses
it. A standard VPN would offer a higher level of protection to SQL
Server without requiring the extra software be used. Why would you
not use it?
Our network admin is former Navy/NSA and it took quite a bit of convincing
to allow remote access to the LAN *at all*. The ability when used with
SecuRemote was the compromise he was willing to sign off on. I have just
assumed that this was fairly standard practice. My wife can work from home
via VPN to her office and she also has to use SecuRemote to be
authenticated.
An open port that is a standard number is an invitation to hackers.
Any vulnerability of the software listening on that port is going
to be exposed to the world.

The reason why there's a difference between exposing it to the
Internet and exposing it on the LAN is because the people on the
LAN are authorized to be on the LAN. Is that not a gigantic
difference?
Of course what you're saying is that security is a matter of degree, right?
Wasn't there a recent Jet Security thread where the experts were basically
saying "Since Jet doesn't keep everyone out, then it's essentially
useless."? We hear over and over that if you want real security use a db
engine like SQL Server. Now we are qualifying that by adding "as long as
it's only exposed to your LAN". That (to me) is a major qualification.
Of course, if you're just now coming to the conclusion that you
can't trust even your employees, well, D'OH!!!!

For certain data it is absolutely true that management doesn't trust the
employees. Why else do we even have LAN security. Not to mention the fact
that in larger coporate offices it might not be that hard for an outsider
to walk around and park himself in an unoccupied office.

[David W. Fenton]

ri*********@hotmail.com (Rick Brandt) wrote in
<bt************@ID-98015.news.uni-berlin.de>:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.74. ..

It makes no sense to me to have a VPN so secure that nobody uses
it. A standard VPN would offer a higher level of protection to
SQL Server without requiring the extra software be used. Why
would you not use it?

Our network admin is former Navy/NSA and it took quite a bit of
convincing to allow remote access to the LAN *at all*. The
ability when used with SecuRemote was the compromise he was
willing to sign off on. I have just assumed that this was fairly
standard practice. My wife can work from home via VPN to her
office and she also has to use SecuRemote to be authenticated.

But you recognize the inconsistency in having your SQL Server open
to the Internet while making VPN access hard?

An open port that is a standard number is an invitation to
hackers. Any vulnerability of the software listening on that
port is going to be exposed to the world.

The reason why there's a difference between exposing it to the
Internet and exposing it on the LAN is because the people on the
LAN are authorized to be on the LAN. Is that not a gigantic
difference?

Of course what you're saying is that security is a matter of
degree, right? Wasn't there a recent Jet Security thread where the
experts were basically saying "Since Jet doesn't keep everyone
out, then it's essentially useless."? We hear over and over that
if you want real security use a db engine like SQL Server. Now we
are qualifying that by adding "as long as it's only exposed to
your LAN". That (to me) is a major qualification.

It's not something *I* said, so I'm not offering a qualification to
it.

You have three levels of security available to you:

1. open SQL Server port, available to anyone who can connect to the
port to attempt to log on.

2. no open SQL Server port, but offer access via VPN.

3. closed network, no access to SQL Server at all from outside your
network.

Which makes sense to you? To me, it's a no-brainer that you use a
VPN to give safe access to people outside your office. Have 1) for
everyone connecting to SQL Server and 2) for everyone using other
tools makes no sense at all.

Of course, if you're just now coming to the conclusion that you
can't trust even your employees, well, D'OH!!!!

For certain data it is absolutely true that management doesn't
trust the employees. Why else do we even have LAN security. Not
to mention the fact that in larger coporate offices it might not
be that hard for an outsider to walk around and park himself in an
unoccupied office.

So, why worry that the implication that a SQL Server port open to
the Internet implies (to you) that SQL Server is also potentially
hackable within the LAN? Of course it is.

And an open SQL Server port is not just an invitation to the hacker
who runs password crackers against it. It's also open to any
security holes or misconfigurations. Do you know for sure that your
SQL Server has a password for the sa account? What if someone
upgrades or reinstalls and it somehow sets the sa account back to
the default with no passord? If that happens, your installation
will be open to any SQL Server exploit that happens by. Remember
that the SQL Server worm that hit last January took TEN MINUTES to
infect 90%+ of the available machines. After that, why would
*anyone* have their SQL Server sitting raw on the Internet, even on
a non-standard port number?

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

[David W. Fenton]

je***@antech.biz.killspam (Jerry Boone) wrote in
<ie*****************@newssvr23.news.prodigy.com> :

Yes, generally a VPN would be a clean way to permit a "more"
secure port to the client. I use this method with another
customer and the only thing I don't like about it is that I have
to give them a certain degree of trust to my domain. If they are
allowed only a Sql Server auth login and have access to a hot port
- that's the only rope they can cling to.
This seems such incredibly wrong-headed thinking that I can't
believe it. You can give the user only as much access to your
domain as is necessary to connect to SQL Server -- you can deny
those users any other kind of access. Yet, your alternative to
doing this is to leave a port open for anyone (or any worm) to
attempt to connect to.

That is a fundamentally broken rationale.
BTW... is that stuff Don has posted about you really true? I have
been around the group long enough to know his style - no need to
spend valuable time explaining... an honorable yes, no, or no
reply would do just fine.

"True" in what sense? I posted comments he has gleaned from Google,
yes, but in contexts that he's stripped from the discussion. Read
and judge for yourself -- I have nothing to be ashamed of.

But I also don't have any interest in discussing it, as it's not
appropriate to this forum.

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

[Jerry Boone]

Woe.... slow down there a minute hot shot... it's called revenue to a
businessman... Sure, sometimes the tractor needs some repairs and upkeep,
but that don't mean it can't get dirty while making money. It's all in
perspective, and I'm afraid yours is shifted more towards paranoia.

First, every ISP that allows Enterprise Manager access to your Sql inclusive
web account runs in this way -- you usually have to look for it, but it's
there, sometimes not mentioned... but there. I know because I have worked
with several and noticed the rest. It is a fundamental practice and the
patches are there for a reason. It doesn't matter what services you run, it
takes "effort" to keep up. Sql server has had 1 famous problem that caused
no data mods or loss. None of my systems or clients systems would have been
affected by slammer anyway because I do subscribe to this tedious practice
quickly to avoid post problems.

Some ISP's are building custom apps with SQLDMO, but they are limiting and
could never really take the place of Enterprise M. or an ADP. The ASP.NET
EM is made for those who don't want to buy an edition of Sql server just to
get EM. I venture to bet that 70% of anyone using a sql web database never
thought about using ADP's - which is one of the reasons why I started this
post. I have found clients that were amazed when they discovered they
didn't have to replace the web tables with EM and could just modify data
with an ADP - got paid well for it too.

Besides, Sql injections are the biggest security problem there is - but the
developers are to blame for that, not sql or 1433.

You can also go back and read about how I go a step further than the "norm"
and allow only reputable customers with static ip's access to 1433 at the
firewall, then additionally shift the port on the even yet more secure sql
service for my elite group.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.90.. .

je***@antech.biz.killspam (Jerry Boone) wrote in
<ie*****************@newssvr23.news.prodigy.com> :

Yes, generally a VPN would be a clean way to permit a "more"
secure port to the client. I use this method with another
customer and the only thing I don't like about it is that I have
to give them a certain degree of trust to my domain. If they are
allowed only a Sql Server auth login and have access to a hot port
- that's the only rope they can cling to.

This seems such incredibly wrong-headed thinking that I can't
believe it. You can give the user only as much access to your
domain as is necessary to connect to SQL Server -- you can deny
those users any other kind of access. Yet, your alternative to
doing this is to leave a port open for anyone (or any worm) to
attempt to connect to.

That is a fundamentally broken rationale.

BTW... is that stuff Don has posted about you really true? I have
been around the group long enough to know his style - no need to
spend valuable time explaining... an honorable yes, no, or no
reply would do just fine.

"True" in what sense? I posted comments he has gleaned from Google,
yes, but in contexts that he's stripped from the discussion. Read
and judge for yourself -- I have nothing to be ashamed of.

But I also don't have any interest in discussing it, as it's not
appropriate to this forum.

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

[TC]

"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:bt************@ID-98015.news.uni-berlin.de...

(snip)

I was surprised by the security issue myself when it was raised. I had always figured that SQL Server had "real" security and therefore could be trusted. The fact that people think it is not safe when exposed to the internet implies to me that it is not secure from users on our LAN either.

All the "big boys" think their products are secure. For example, Oracle made
a big fuss about their "unbreakable security". Three microseconds later, a
dozen serious exploits were found in some of their flagship products.

TC

[Jerry Boone]

Reducing connection overhead is a good reason to use ADP's...

In Andy and Mary's nice book they discusses extra overhead added by using
MDB-Jet-ODBC vs. simply using the native sql oledb provider utilized by the
adp.

They also mention that ADP's scale further and m-j-o has it's limits based
on such added overhead placed on the lan/wan, and sql server. So yes,
Larry - it is do-able, but less practical for the performance/scalability
aspect, which is why you found the idea of using adp's as a web delivered
solution interesting.

If anyone wants quotes and/or page numbers, I will be glad to add them to
the thread.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access

"Larry Linson" <bo*****@localhost.not> wrote in message
news:Xc*******************@nwrddc02.gnilink.net...

"Jerry Boone" wrote

> A long time ago Larry Linson ... (hope you
> don't mind me quoting you sir)
No, I don't mind at all, Jerry... I'm happy to see an enlightening

technical discussion.

I'm wondering how this fits with the Microsoft insiders' apparent current
agreement that "MDB-ODBC beats ADP-ADODB" -- maybe one of those insiders
will join in this discussion.

As Rick said, I knew you _could_ connect via the Internet with MDB-ODBC, but I never thought it was practical from either a performance or a security
point of view. An open port to the Internet strikes me, as it apparently
struck Rick's admin friend, as a lot riskier than an open port on a LAN/WAN.
In my experience, Access clients using MDB-Jet-ODBC do not rely on Jet
security to any degree; it is the server database that provides the
security. A major app on which I worked off and on for several years had an Access 2.0 client -- no MDE and security with a hole big enough to drive a
freight train through -- but the Informix server security was pretty good.

Larry Linson
Microsoft Access MVP

[David W. Fenton]

je***@antech.biz.killspam (Jerry Boone) wrote in
<UF*****************@newssvr23.news.prodigy.com> :

You can also go back and read about how I go a step further than
the "norm" and allow only reputable customers with static ip's
access to 1433 at the firewall, then additionally shift the port
on the even yet more secure sql service for my elite group.

Using a VPN would eliminate all sorts of risks as well as
eliminating the restriction to a list of IP addresses (fixed or
not).

That's all I have to say.

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

[Jerry Boone]

Another... but more subtle reason...

Using ADP's forces you to become a stronger ADO and Sql Server developer
which leads you to other great tools. Since these two items are key players
to the entire fleet of MS developer products, it gives you power to know how
to use them well.

Now, understand that I am not saying that you "can't learn" if you use
mdb's, but that adp's push you harder to produce server side code and wean
you off of the expression builders and other tools that are not in ADP's and
other dev environments.

The things we all do with Mdb's are great... no doubt that useable databases
can literally be built in minutes. Complex tasks are easy with expressions
& vba, not to mention that the subtle performance loss from linked tables
over odbc vs. native oledb is generally acceptable when the database is
small and the concurrent user count is low.

What happens when it's time to build data driven web pages, deploy a dll in
VB or flavor of C, produce a small utility (pure coded exe, not access or db
related) application for Active Directory containers or to do WMI calls on a
domain server...? Hmm... no easy cheater tools for that. What a terrible
place for a confident and accomplished mdb developer to land in!

I feel that using ADP's gently persuaded me to get serious about ADO, which
led to understanding com objects better, which led to getting deep into all
the features that are grossly under-discovered in Sql server like triggers,
udf's (new in 2k), dts, job agents, profiler, defaults, full text indexing,
auto tuning, multi proc, (geez... I could literally go on forever) which led
me into VB because I understood how to fetch data in recordsets and bind
them to vb forms, which led me to looping data on ASP pages, which gave me
the nuts to hammer at VB.Net and ASP.Net... the list just goes on and on.
I cannot say with certainty that had I not made a move to using ADP's that I
would not have been motivated to discover any of that stuff. You can
survive with querydefs, dao, odbc, and all of that until MS stops putting it
out and that's fine if that is all you want or need to do. I believe MS
killed DDE support in .Net this time around and in time even ADO will get
the ax, but not before odbc does.

Bottom line is that adp's can motivate you to learn these technologies in a
more subtle manner than for say... diving right into .Net (talk about mental
suicide) -- there are few ladders in the development world as subtle as
ADP's and climbing those once and a while can lead you to discover some new
and very valuable things. Just remember that motivation, opportunity, and
the tenacity to put up with the problems that come with new territory is not
always a bad thing. All great discoveries are truly realized when leaving
the protection of familiarity.
--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access

"Jerry Boone" <je***@antech.biz.killspam> wrote in message
news:f0*******************@newssvr11.news.prodigy. com...

A long time ago Larry Linson (MVP contributor to this group) made a point to me that mdb's could do anything ADP's (Access Projects) could by using
linked tables to leverage Sql server databases. It's been years since then, and I still sometimes think about that statement when evaluating the
usefulness of the ADP's I build. Larry and I discussed this technique and
he found it "Credible" (hope you don't mind me quoting you sir) so what the hell... here it goes - this is for all you die-hard ADP guys (and gals of
course). I know there have been long, drawn out debates over the very
subject at hand, some I have read and been a participant... and perhaps this recommendation of usage has even came to surface - however, I felt it had
not been mentioned before by the way Larry responded.

After working with ADP's since the birth of A2K, I have found many
advantages that suit me... but what about you? Please understand, this
thread is not an open invitation to bash ADP's (let's try something new),
but rather a constructive way to figure out what tricks people are using
that make them "valuable" - ok? So, without further delay... here is one
innovative trick out of my bag in which I have kept for myself for some
time... yours for free if it's new to you...

Note that ADP's connect to Sql Server using an OLEDB connection. This type of connection can and will definitely span further than the local network,
in fact it can span to any IP Address that has port 1433 (Sql Server) open
and Sql Server/MSDE running. Perhaps the strongest advantage ADP's have in my business is that I can deploy them to multiple locations while hosting
the database. For a monthly fee, customers get a managed database and do
not incur the expense of a server. This model simply fits the small branch office scenario "like a glove". Then, using bound forms and intelligent
Stored Procedure design, I have a very tight, fast performing (by keeping
records down), rich, and believe it or not... a secure delivered ADE
application.

How many people have a website that uses a Sql Server database? If so, did you know you can more than likely connect to it with Access as a Project and do whatever you want with the database... as long as you have the
credentials? Most, if not all ISP's who host Sql Databases allow you to
connect with Enterprise Manager - you can use those same credentials to
connect your copy of Access. Work with Data, build new queries, build some forms for maintaining data, deploy them as an alternative to building
complex, yet featureless web page based maintenance systems.

I believe this is new with AccessXP, but did you know that you can now link many flavors of tables to ADP's? Yes, Paradox, dBase, MDB's, and any ODBC
or OLEDB accessible engine... to name a few. Look into it if you have a
need for this. You could always link some of these from Sql Server, but now it's a right click and link option in table view.

Anyway - I hope this thread stays positive and uncovers some really good
features that ADP's provide to working developers.

Professional replies are appreciated.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access

[Jerry Boone]

Right - I agree with that to a certain degree. I think VPN's are great for
employees or members of the immediate trusted realm. But the reality is
that all companies hire people who change settings. Things that were one
way yesterday are different today. It is harder to constantly secure an
entire network (in which trusted employees work with) than controlling one
port and what entity accesses it, and even "when" they are able to access
it.

A user with VPN access has an entire network of vulnerabilities to explore
and generally with no firewall to contend with. Everything from the
underdog Win95 computer in the plant to the domain controllers. I
understand that provisions can be made but after a while it gets kind of
mundane. I have several VPN's and they are all very well used, but only by
trusted individuals in the immediate realm in which I would extend a port on
the switch within a building -- sorry, no average Joe's allowed.

Web apps on 80 for John and Jane, 1433 for friends, VPN for family.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.90.. .

je***@antech.biz.killspam (Jerry Boone) wrote in
<UF*****************@newssvr23.news.prodigy.com> :

You can also go back and read about how I go a step further than
the "norm" and allow only reputable customers with static ip's
access to 1433 at the firewall, then additionally shift the port
on the even yet more secure sql service for my elite group.

Using a VPN would eliminate all sorts of risks as well as
eliminating the restriction to a list of IP addresses (fixed or
not).

That's all I have to say.

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

[David W. Fenton]

je***@antech.biz.killspam (Jerry Boone) wrote in
<%8*****************@newssvr22.news.prodigy.com> :

A user with VPN access has an entire network of vulnerabilities to
explore and generally with no firewall to contend with.

If the administrator knows how to configure the VPN *and* how to
properly manage NT users and user groups and apply appropriate ACLs
to network resources, your statement is false.

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

[Jerry Boone]

ACL's are good, I haven't used them because I don't need to and out of 30+
networks I can't think of one that has ever required it. Especially mine...

Giving out VPN access is not something ISP's normally do, and if you find a
few - good for you, they have more time on their hands than I do and maybe
even share your 1433 paranoia. My customers are happy that they have one
step to opening an app and I'm happy that I never have vpn connection
issues. I doubt there is anything that can change my mind on that.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access

[Albert D. Kallal]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message

news:94***************************@24.168.128.74.. .

pl******************@msn.com (Albert D. Kallal) wrote in
<t7vKb.9472$hk.20@pd7tw1no>:
Well, what if you have a client with an Access/Jet application who
has neither SQL Server nor WTS set up. Which is cheaper and easier
to setup and which is cheaper and easier to administer? Which
requires more work to maintain? I'm pretty sure that WTS wins out
here and quite handily.
Yes, I fully agree with the above. So, yes, WTS would without
question by my choice. If one has sql server already
for the application, then we most certainly have a much more
lively debate here (but that is not our debate!).
But you were suggesting that Access/Jet over WTS is more
difficult and more expensive than converting the app to SQL Server
and deploying that way. I strenuously disagree.

I am well in agreement with the above also. However, I will say that
converting a relative simple ms-access application to work
with JET/ODBC to sql server can actually be FAR cheaper then using
WTS. So, in fact I am hinting that using JET/odbc, or even a adp
*might* be a cheaper choice then deploying WTS. The reasons here is
that WTS does have fairly steep licensing fees. So, for a simple
application with 20 remote users, sql server (either JET/odbc, or
adp) can actually be a lot cheaper). However, this savings would
only occur if NOT a lot of programming labour is required to
convert the application from a JET file share to a JET/odbc to
sql server.

So, yes, in most cases, WTS would be far better then spending
money converting the application to work with sql server, but
this would not always be the case. Also WTS takes a lot more
horse power and ram to run then does sql server for a given
number of users. So, there is "some" factors at play here,
and as always, no cut and dry 100% rule for every case.
--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
No************@msn.com
http://www.attcanada.net/~kallal.msn

[David W. Fenton]

je***@antech.biz.killspam (Jerry Boone) wrote in
<fa*****************@newssvr24.news.prodigy.com> :

ACL's are good, I haven't used them because I don't need to and
out of 30+ networks I can't think of one that has ever required
it. Especially mine...

Giving out VPN access is not something ISP's normally do, and if
you find a few - good for you, they have more time on their hands
than I do and maybe even share your 1433 paranoia. My customers
are happy that they have one step to opening an app and I'm happy
that I never have vpn connection issues. I doubt there is
anything that can change my mind on that.

I did not know an ISP was involved.

If I were your clients, I wouldn't be too happy with that
situation.

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

[David W. Fenton]

pl******************@msn.com (Albert D. Kallal) wrote in
<Qr0Lb.17519$JQ1.1716@pd7tw1no>:

So, in fact I am hinting that using JET/odbc, or even a adp
*might* be a cheaper choice then deploying WTS. The reasons here
is that WTS does have fairly steep licensing fees.

And the comparison to the licensing fees for SQL Server?

You seem to be assuming that those have already been paid for and
the WTS licenses not. In a situation where SQL Server is already in
use and licensed, yes, that obviously changes the equation.

But that simply is not the scenario that was under discussion in
this threadlet.

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

[Jerry Boone]

Well, your not - and that's ok with me, unless of course you have a better
idea than the thousands of other ISP's that won't even go as far as I do.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.86.. .

je***@antech.biz.killspam (Jerry Boone) wrote in
<fa*****************@newssvr24.news.prodigy.com> :

ACL's are good, I haven't used them because I don't need to and
out of 30+ networks I can't think of one that has ever required
it. Especially mine...

Giving out VPN access is not something ISP's normally do, and if
you find a few - good for you, they have more time on their hands
than I do and maybe even share your 1433 paranoia. My customers
are happy that they have one step to opening an app and I'm happy
that I never have vpn connection issues. I doubt there is
anything that can change my mind on that.

I did not know an ISP was involved.

If I were your clients, I wouldn't be too happy with that
situation.

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

[Jerry Boone]

They have the licenses if they are running SBS. However, somewhere in
SBS... MS decided you still have to pay for WTS licenses on top of that.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.86.. .

pl******************@msn.com (Albert D. Kallal) wrote in
<Qr0Lb.17519$JQ1.1716@pd7tw1no>:

So, in fact I am hinting that using JET/odbc, or even a adp
*might* be a cheaper choice then deploying WTS. The reasons here
is that WTS does have fairly steep licensing fees.

And the comparison to the licensing fees for SQL Server?

You seem to be assuming that those have already been paid for and
the WTS licenses not. In a situation where SQL Server is already in
use and licensed, yes, that obviously changes the equation.

But that simply is not the scenario that was under discussion in
this threadlet.

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

[Jerry Boone]

Oh yeah... I almost forgot... for paranoid people who don't have really
sensitive data, they can use protocol encryption for Sql Server. It's a
selection you can make in cliconfg.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.86.. .

je***@antech.biz.killspam (Jerry Boone) wrote in
<fa*****************@newssvr24.news.prodigy.com> :

ACL's are good, I haven't used them because I don't need to and
out of 30+ networks I can't think of one that has ever required
it. Especially mine...

Giving out VPN access is not something ISP's normally do, and if
you find a few - good for you, they have more time on their hands
than I do and maybe even share your 1433 paranoia. My customers
are happy that they have one step to opening an app and I'm happy
that I never have vpn connection issues. I doubt there is
anything that can change my mind on that.

I did not know an ISP was involved.

If I were your clients, I wouldn't be too happy with that
situation.

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

[Jerry Boone]

> Oh yeah... I almost forgot... for paranoid people who don't have really

sensitive data, they can use protocol encryption for Sql Server. It's a
selection you can make in cliconfg.

Well... I shouldn't have put that "don't" in there, but it kind of works
either way...

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access

[Larry Linson]

"Jerry Boone" wrote

They have the licenses if they
are running SBS. However,
somewhere in SBS... MS
decided you still have to pay
for WTS licenses on top of that.

What are the max users for SBS? As I recall, it used to be rather low, after
which you had to move on to the unbundled server O/S, SQL Server, etc..

And, a couple of other questions: did you earlier say that ADPs now do not
_have_ to use MS SQL Server as their back end? If that is the case, are
there ADO data provider that allow an ADP to be used with PostgreSQL and
MySQL, the free and semi-free databases?

Larry Linson

[Jerry Boone]

SBS is 50 users max.

The linking allows to either...

Create a Sql Server View for each table based on a MS Sql Linked Server
(this possible before using Enterprise Manager, but easier now inside the
ADP)

Link to any OLE DB source using an ad hoc connection. Unfortunately I
didn't notice before that it states that this type of connection is
"read-only", but still it's a nice improvement. It allows you to hit any
mdb, data source via odbc, paradox, dbase, etc.

So I would say that if PostgreSQL or MySQL have OleDB interfaces they are
definitely useable, otherwise only partially useable (assuming odbc) via
ADP.

--
Jerry Boone
Analytical Technologies, Inc.
http://www.antech.biz
Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access
"Larry Linson" <bo*****@localhost.not> wrote in message
news:wv*************@nwrddc01.gnilink.net...

"Jerry Boone" wrote

> They have the licenses if they
> are running SBS. However,
> somewhere in SBS... MS
> decided you still have to pay
> for WTS licenses on top of that.
What are the max users for SBS? As I recall, it used to be rather low,

after which you had to move on to the unbundled server O/S, SQL Server, etc..

And, a couple of other questions: did you earlier say that ADPs now do not
_have_ to use MS SQL Server as their back end? If that is the case, are
there ADO data provider that allow an ADP to be used with PostgreSQL and
MySQL, the free and semi-free databases?

Larry Linson