For database on the Internet, if not Access, what?

[LurfysMa]

I am working on an electronic flashcard application. I have one
version up and running using Visual Basic (6.0) and Access 2000.

My long-range plans are to put it up on a website and sell
subscriptions. But that is probably 2-3 releases away. In the
meantime, I would like to put it up on the website for testing.

I have been reading here and elsewhere that Access is not suitable for
a web-based implementation. Is that because is was designed for a
single user (on a desktop) and cannot handle more than a few
simultaneous users?

Assuming that Access is not the right tool, what is?

I will be hiring a contract programmer to implement the database so my
personal learning curve is not a factor.

Is there an intermediate capacity database program that I could use
that wouldn't require a 10-person department to support and maintain?

For the foreseeable future, I probably only need something that can
support a few hundred simultaneous users. If I exceed that, I will be
flush with cash and I'll hire the 10-person department. ;-) I just
need something to get me from here to there.

Thanks
--
Running MS Office 2000 Pro on Win2000

[Lyle Fairfield]

LurfysMa wrote:

I am working on an electronic flashcard application. I have one
version up and running using Visual Basic (6.0) and Access 2000.

My long-range plans are to put it up on a website and sell
subscriptions. But that is probably 2-3 releases away. In the
meantime, I would like to put it up on the website for testing.

I have been reading here and elsewhere that Access is not suitable for
a web-based implementation. Is that because is was designed for a
single user (on a desktop) and cannot handle more than a few
simultaneous users?

Assuming that Access is not the right tool, what is?

I will be hiring a contract programmer to implement the database so my
personal learning curve is not a factor.

Is there an intermediate capacity database program that I could use
that wouldn't require a 10-person department to support and maintain?

For the foreseeable future, I probably only need something that can
support a few hundred simultaneous users. If I exceed that, I will be
flush with cash and I'll hire the 10-person department. ;-) I just
need something to get me from here to there.

I think the major issue with a Multi-user web app is not so much the
db, but the front end. Somehow we must deal with simultaneous editing.
Typically with ASP, the ASP file uses ADO to get the data and display
it. But the data is no longer connected to the db. Suppose I edit it.
You, one hundred km away, do the same thing at about the same time.
There's no real problem with us both asking for the data at the same
time. Filling the request takes a millionth of a second; which ever one
of us is second won't even notice the wait.
But I change job description and salary. You change telephone number
and address. I save my changes, a fraction of a second before you save
yours. My changes may be (depending on our SQL) gone forever. And I
don't know. And the job description and salary changes are not rolled
back. Arggggggggghhhhhhhhhh!

IMO this requires thought, careful thought, and planning or ... maybe a
"bound" kind of front end ... such as (I think) ASP.Net.

[tommaso.gastaldi]

hi LurfysMa,

probably the most common answer to your answer would be using sql
server 2005 express. But I guess you could also use mysql. I also have
heard about access limitations, actually you could start with access
and if problem arise could move on. After all, from the programming
perspective practically does not change (almost) anything...

-tom

LurfysMa ha scritto:

I am working on an electronic flashcard application. I have one
version up and running using Visual Basic (6.0) and Access 2000.

My long-range plans are to put it up on a website and sell
subscriptions. But that is probably 2-3 releases away. In the
meantime, I would like to put it up on the website for testing.

I have been reading here and elsewhere that Access is not suitable for
a web-based implementation. Is that because is was designed for a
single user (on a desktop) and cannot handle more than a few
simultaneous users?

Assuming that Access is not the right tool, what is?

I will be hiring a contract programmer to implement the database so my
personal learning curve is not a factor.

Is there an intermediate capacity database program that I could use
that wouldn't require a 10-person department to support and maintain?

For the foreseeable future, I probably only need something that can
support a few hundred simultaneous users. If I exceed that, I will be
flush with cash and I'll hire the 10-person department. ;-) I just
need something to get me from here to there.

Thanks
--
Running MS Office 2000 Pro on Win2000

[Albert D.Kallal]

I have been reading here and elsewhere that Access is not suitable for

a web-based implementation. Is that because is was designed for a
single user (on a desktop) and cannot handle more than a few
simultaneous users?

Well, how is VB6 sutiable for a web based application?

I think you are confusing ms-access, and the database engine.

ms-access is a developers tool, just like c++, or VB6. You can use ms-access
to build a appcation, and the database system can be oracle.

The last 3 versions of the office cd have shipped with a FREE copy of sql
server (the MSDE - desktop edition) of sql server.

So, the problem here is not that ms-access can't handle more then a few
users, in fact, there are some companies that have 1000 users ALL AT THE
SAME TIME for ms-access. Of course, those access applications are connecting
to a powerful sql server database.

Remember, the performance in using , c++, vb6, or ms-access to pull data
from oracle, or sql server is EXACTLY the same.

Also REMEMBER THAT YOU CAN NOT create forms, reports etc. with sql server.

So, don't confusing the application development system. MS-access, or vb6
will perform the same when you connect them to sql server (the data speed
becomes that of the database engine you use).

So, the reason why you are being told that ms-access sis not good for web
development is a exactly the same reason as to why VB6 is not for web
development. The fact is, they are tools that let you write code, and
develop..but, they certainly are not web based.

As for the data engine? Well, you can use JET, and that is the default
engine for ms-access. However, you are no more restricted to using sql
server, or JET with VB6, then you are with ms-access.

There is a number of free engines available from Microsoft. The choice of
what data engine you use for your web based systems has really NOTHING to do
with ms-access. If you are going to run and host your own web site, then
you have a choice. If you are purchasing web space, then obviously your
choice of what database system/engine you use is going to be limited to what
your provider offers you. (so, you have greater choice if you host your own
web site, but MANY a company I know has stopped doing that, as they have NO
WHERE NEAR the experience to expose their network and computers to the wild
internet. The company I know that last attempt this gave up VERY quickly
when they discover they did not have NEAR the technical ability to secure
their website from hackers and the nasty outside place called the wild
internet.).

So, what data engine you chose is mostly going to be limited to what your
provider gives you, or if you are wiling to risk running your own web server
that is exposed to the internet.

However, regardless of whatever approach you take...it not ms-access anymore
then VB6 you are going to be using....

For lightweight web based applications, you can use JET, but why? There is
no more effort into using sql server, or sql express then that of using JET.
Even when you use JET on the web server, you certainly do not install
ms-access, and you likely will not use ms-access at all.

Since you don't need, nor use ms-access in this case, then choosing JET, or
sql server, (paid for, or one of the several free visions) really does not
matter much. The efforts are about the same, but the server based systems
are better for web based stuff, and even more so because they can be
administered remotely....something that is a pain with JET based systems.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal

[LurfysMa]

On 12 Jul 2006 14:53:23 -0700, "Lyle Fairfield"
<ly***********@aim.comwrote:

>LurfysMa wrote:

>I am working on an electronic flashcard application. I have one
version up and running using Visual Basic (6.0) and Access 2000.

My long-range plans are to put it up on a website and sell
subscriptions. But that is probably 2-3 releases away. In the
meantime, I would like to put it up on the website for testing.

I have been reading here and elsewhere that Access is not suitable for
a web-based implementation. Is that because is was designed for a
single user (on a desktop) and cannot handle more than a few
simultaneous users?

Assuming that Access is not the right tool, what is?

I will be hiring a contract programmer to implement the database so my
personal learning curve is not a factor.

Is there an intermediate capacity database program that I could use
that wouldn't require a 10-person department to support and maintain?

For the foreseeable future, I probably only need something that can
support a few hundred simultaneous users. If I exceed that, I will be
flush with cash and I'll hire the 10-person department. ;-) I just
need something to get me from here to there.

I think the major issue with a Multi-user web app is not so much the
db, but the front end. Somehow we must deal with simultaneous editing.

In the particular application I am writing, there will never be a
situation where two different users will ever edit the same record in
any of the databases.

In fact, most of the data will be read only. Each user will have a
private dataset (collection of records in a database) that keep track
of what that user has done. Since a user cannot e logged on twice,
those particular records will never be open read/write by more than a
single user at a time.

>Typically with ASP, the ASP file uses ADO to get the data and display
it. But the data is no longer connected to the db. Suppose I edit it.
You, one hundred km away, do the same thing at about the same time.
There's no real problem with us both asking for the data at the same
time. Filling the request takes a millionth of a second; which ever one
of us is second won't even notice the wait.
But I change job description and salary. You change telephone number
and address. I save my changes, a fraction of a second before you save
yours. My changes may be (depending on our SQL) gone forever. And I
don't know. And the job description and salary changes are not rolled
back. Arggggggggghhhhhhhhhh!

IMO this requires thought, careful thought, and planning or ... maybe a
"bound" kind of front end ... such as (I think) ASP.Net.

--
Running MS Office 2000 Pro on Win2000

[tommaso.gastaldi]

I suggest you start designing your scheme with access.

For developing purposes it is useful to have a handy db such
as an mdb file. Also because during the development you may
change your mind about some part of the design (although you should
try to design it well from the beginning) and it's much more easy to
make
changes to an mdb.

When I write my asp.net applications from scratch I always use access
during development as scratch dbms, also because I can move it easily
from
a site to another. This is also possible with .mdf, but there might be
several
security issues which make waste a lot of time and give headhaches.

When everything is set and working fine, you finally can change the
dbms to
whatever: sql server, mysql, oracle. postgres, vfp, sybase, etc. with
minor
changes (hopefully just the conn string!).
But keep around the access copy for further developments :) ...

-tom

LurfysMa ha scritto:

On 12 Jul 2006 14:53:23 -0700, "Lyle Fairfield"
<ly***********@aim.comwrote:

LurfysMa wrote:

I am working on an electronic flashcard application. I have one
version up and running using Visual Basic (6.0) and Access 2000.

My long-range plans are to put it up on a website and sell
subscriptions. But that is probably 2-3 releases away. In the
meantime, I would like to put it up on the website for testing.

I have been reading here and elsewhere that Access is not suitable for
a web-based implementation. Is that because is was designed for a
single user (on a desktop) and cannot handle more than a few
simultaneous users?

Assuming that Access is not the right tool, what is?

I will be hiring a contract programmer to implement the database so my
personal learning curve is not a factor.

Is there an intermediate capacity database program that I could use
that wouldn't require a 10-person department to support and maintain?

For the foreseeable future, I probably only need something that can
support a few hundred simultaneous users. If I exceed that, I will be
flush with cash and I'll hire the 10-person department. ;-) I just
need something to get me from here to there.

I think the major issue with a Multi-user web app is not so much the
db, but the front end. Somehow we must deal with simultaneous editing.

In the particular application I am writing, there will never be a
situation where two different users will ever edit the same record in
any of the databases.

In fact, most of the data will be read only. Each user will have a
private dataset (collection of records in a database) that keep track
of what that user has done. Since a user cannot e logged on twice,
those particular records will never be open read/write by more than a
single user at a time.

Typically with ASP, the ASP file uses ADO to get the data and display
it. But the data is no longer connected to the db. Suppose I edit it.
You, one hundred km away, do the same thing at about the same time.
There's no real problem with us both asking for the data at the same
time. Filling the request takes a millionth of a second; which ever one
of us is second won't even notice the wait.
But I change job description and salary. You change telephone number
and address. I save my changes, a fraction of a second before you save
yours. My changes may be (depending on our SQL) gone forever. And I
don't know. And the job description and salary changes are not rolled
back. Arggggggggghhhhhhhhhh!

IMO this requires thought, careful thought, and planning or ... maybe a
"bound" kind of front end ... such as (I think) ASP.Net.

--
Running MS Office 2000 Pro on Win2000

[Larry Linson]

The default database engine that comes with Access is called "Jet." So,
strictly speaking, you have a VB6 and Jet application. Jet databases can be
used on the Internet, and can likely, because of the way the application
will be coded, may even support more concurrent users than a standard Access
multiuser database. But, _Access_ will not be involved, just as it is not
with your "VB6 and Jet" application (note that we, here, and Microsoft, too,
do often not adhere to precise descriptions and call it an "Access
database").

If your audience grows, then you may need to use a server database -- many
Web Presence Providers include a specific server DB in their package deals,
most often an OpenSource DB, and, often, the less-expensive service uses
OpenSource web server software, too. If you pay a bit extra to get a Windows
web server, with IIS, and support for .ASP, then they will probably also
have Microsoft SQL Server available. If the cost of the service isn't too
high, just starting out with the appropriate server DB for your web
environment is likely to save hassles in the long run.

Larry Linson
Microsoft Access MVP
"LurfysMa" <in*****@invalid.invalidwrote in message
news:fa********************************@4ax.com...

On 12 Jul 2006 14:53:23 -0700, "Lyle Fairfield"
<ly***********@aim.comwrote:

>>LurfysMa wrote:

>>I am working on an electronic flashcard application. I have one
version up and running using Visual Basic (6.0) and Access 2000.

My long-range plans are to put it up on a website and sell
subscriptions. But that is probably 2-3 releases away. In the
meantime, I would like to put it up on the website for testing.

I have been reading here and elsewhere that Access is not suitable for
a web-based implementation. Is that because is was designed for a
single user (on a desktop) and cannot handle more than a few
simultaneous users?

Assuming that Access is not the right tool, what is?

I will be hiring a contract programmer to implement the database so my
personal learning curve is not a factor.

Is there an intermediate capacity database program that I could use
that wouldn't require a 10-person department to support and maintain?

For the foreseeable future, I probably only need something that can
support a few hundred simultaneous users. If I exceed that, I will be
flush with cash and I'll hire the 10-person department. ;-) I just
need something to get me from here to there.

I think the major issue with a Multi-user web app is not so much the
db, but the front end. Somehow we must deal with simultaneous editing.

In the particular application I am writing, there will never be a
situation where two different users will ever edit the same record in
any of the databases.

In fact, most of the data will be read only. Each user will have a
private dataset (collection of records in a database) that keep track
of what that user has done. Since a user cannot e logged on twice,
those particular records will never be open read/write by more than a
single user at a time.

>>Typically with ASP, the ASP file uses ADO to get the data and display
it. But the data is no longer connected to the db. Suppose I edit it.
You, one hundred km away, do the same thing at about the same time.
There's no real problem with us both asking for the data at the same
time. Filling the request takes a millionth of a second; which ever one
of us is second won't even notice the wait.
But I change job description and salary. You change telephone number
and address. I save my changes, a fraction of a second before you save
yours. My changes may be (depending on our SQL) gone forever. And I
don't know. And the job description and salary changes are not rolled
back. Arggggggggghhhhhhhhhh!

IMO this requires thought, careful thought, and planning or ... maybe a
"bound" kind of front end ... such as (I think) ASP.Net.

--
Running MS Office 2000 Pro on Win2000