Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!

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

Discussion in 'Information Technology' started by LurfysMa, Jul 28, 2006.

  1. LurfysMa

    LurfysMa
    Expand Collapse
    Guest

    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
     
  2. Loading...


  3. Lyle Fairfield

    Lyle Fairfield
    Expand Collapse
    Guest

    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.
     
  4. tommaso.gastaldi@uniroma1.it

    Guest

    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
     
  5. Albert D.Kallal

    Albert D.Kallal
    Expand Collapse
    Guest

    > 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
    pleaseNOOSpamKallal@msn.com
    http://www.members.shaw.ca/AlbertKallal
     
  6. LurfysMa

    LurfysMa
    Expand Collapse
    Guest

    On 12 Jul 2006 14:53:23 -0700, "Lyle Fairfield"
    <lylefairfield@aim.com> wrote:

    >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
     
  7. tommaso.gastaldi@uniroma1.it

    Guest

    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"
    > <lylefairfield@aim.com> wrote:
    >
    > >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
     
  8. Larry Linson

    Larry Linson
    Expand Collapse
    Guest

    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" <invalid@invalid.invalid> wrote in message
    news:fapcb292ivhb780dpe02r9uammpu6kniqe@4ax.com...
    > On 12 Jul 2006 14:53:23 -0700, "Lyle Fairfield"
    > <lylefairfield@aim.com> wrote:
    >
    >>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
     

Share This Page