I'd like some opinions: What is the best/easiest/quickest way to have a 
database on the web?
I'm after all options - be it Internet replication, MySQL/SQL Server/Data 
Access Pages or whatever.
What is the best total solution in your experience?

Steven

The answer depends on a lot of things : how much traffic do you expect, how
much data will be manipulated, what kind of resources do you have for
support, what skills do the people who have to build it currently have...
it could be as small as an MDE with .NET web access, or as big as
Oracle/Unix backend with a farm of WebLogic app servers etc etc... its like
asking "what the best vehicle" : are you trying to haul 100 tons of rock out
of your strip mine or are you trying to go around in a little circle at
200mph?

so tell us more...


-----Original Message-----
From: Steven White [mailto:Steve.White@m...]
Sent: Friday, September 20, 2002 5:11 AM
To: Access
Subject: [access] Databases on the web


I'd like some opinions: What is the best/easiest/quickest way to have a 
database on the web?
I'm after all options - be it Internet replication, MySQL/SQL Server/Data 
Access Pages or whatever.
What is the best total solution in your experience?

Steven

OK - I was just after a fairly broad sort of opinion, but I agree that I should have been a bit 
more specific.

Say you make a database using one of those Access wizards (say, for the sake of an example 
- the order entry one).
All that you want your users to do over the internet is data entry - nothing more.

You've got massive amounts of bandwidth on your server (eg, 3 T1 connections with very little 
traffic on the server), but your users might only be using a 33.6k modem, so you want it to be 
fairly lightweight.

There's only going to be about 10 users, which may be concurrent. 

You expect to have about 20 orders entered each day all up (i.e NOT 20 per user)

but you've already got about 4000 orders in the database.

All queries and reporting and the like will be done across a LAN connected to the server, so 
that's not needed in terms of the web.

In terms of the skills of the workers - well - let's pretend we don't care for the sake of this 
exercise - someone could be hired. 

So - what do you all think would be the best solution for that fairly generic, yet kind of specific 
situation?

You could try data access pages in A2K+, however I've never really used
them.

The question on skills of the workers is quite important, since you need to
use a server-side scripting language to interact with the database from your
web-server.

If you wanted to do it in-house, someone with a bit of a coding background
could probably pick ASP or ColdFusion quite easily, or use the inbuilt
wizards of MS FrontPage (YUK), seeing as you only need to design for a few
users.  

ASP requires no further software install assuming you are running a Windows
Server.  ColdFusion requires purchase of the server software, and probably a
development environment such as cold-fusion studio. 

There are other languages around also, such as PHP / Perl etc which could do
the job.  If you wanted to hire a programmer then it would depend on what
languages they code in.

Cheers,
Andrew

-----Original Message-----
From: Steven White [mailto:Steve.White@m...]
Sent: Saturday, 21 September 2002 1:24 PM
To: Access
Subject: [access] RE: Databases on the web


OK - I was just after a fairly broad sort of opinion, but I agree that I
should have been a bit 
more specific.

Say you make a database using one of those Access wizards (say, for the sake
of an example 
- the order entry one).
All that you want your users to do over the internet is data entry - nothing
more.

You've got massive amounts of bandwidth on your server (eg, 3 T1 connections
with very little 
traffic on the server), but your users might only be using a 33.6k modem, so
you want it to be 
fairly lightweight.

There's only going to be about 10 users, which may be concurrent. 

You expect to have about 20 orders entered each day all up (i.e NOT 20 per
user)

but you've already got about 4000 orders in the database.

All queries and reporting and the like will be done across a LAN connected
to the server, so 
that's not needed in terms of the web.

In terms of the skills of the workers - well - let's pretend we don't care
for the sake of this 
exercise - someone could be hired. 

So - what do you all think would be the best solution for that fairly
generic, yet kind of specific 
situation?

For a system that small, I would recommend using an Access 2000 data access
page design.  There's lots of good info on using those in MSDN or TechNet...


-----Original Message-----
From: Haslett, Andrew [mailto:andrew.haslett@i...]
Sent: Saturday, September 21, 2002 5:30 AM
To: Access
Subject: [access] RE: Databases on the web


You could try data access pages in A2K+, however I've never really used
them.

The question on skills of the workers is quite important, since you need to
use a server-side scripting language to interact with the database from your
web-server.

If you wanted to do it in-house, someone with a bit of a coding background
could probably pick ASP or ColdFusion quite easily, or use the inbuilt
wizards of MS FrontPage (YUK), seeing as you only need to design for a few
users.  

ASP requires no further software install assuming you are running a Windows
Server.  ColdFusion requires purchase of the server software, and probably a
development environment such as cold-fusion studio. 

There are other languages around also, such as PHP / Perl etc which could do
the job.  If you wanted to hire a programmer then it would depend on what
languages they code in.

Cheers,
Andrew

-----Original Message-----
From: Steven White [mailto:Steve.White@m...]
Sent: Saturday, 21 September 2002 1:24 PM
To: Access
Subject: [access] RE: Databases on the web


OK - I was just after a fairly broad sort of opinion, but I agree that I
should have been a bit 
more specific.

Say you make a database using one of those Access wizards (say, for the sake
of an example 
- the order entry one).
All that you want your users to do over the internet is data entry - nothing
more.

You've got massive amounts of bandwidth on your server (eg, 3 T1 connections
with very little 
traffic on the server), but your users might only be using a 33.6k modem, so
you want it to be 
fairly lightweight.

There's only going to be about 10 users, which may be concurrent. 

You expect to have about 20 orders entered each day all up (i.e NOT 20 per
user)

but you've already got about 4000 orders in the database.

All queries and reporting and the like will be done across a LAN connected
to the server, so 
that's not needed in terms of the web.

In terms of the skills of the workers - well - let's pretend we don't care
for the sake of this 
exercise - someone could be hired. 

So - what do you all think would be the best solution for that fairly
generic, yet kind of specific 
situation?