Results 1 to 6 of 6
  1. #1
    Join Date
    Feb 2012
    Posts
    3

    Unhappy Unanswered: Access Intranet Application

    Hi All,

    I am very new with Ms access 2007 but I do understand the database concept.

    My Question is that " Can I make such access database which can be updated, manipulated and used by many users around 100"

    Actually I am trying to make an appllication software on which many users can work by creating the user interface front end and to store the data into the access db back end.

    Please suggest me Is it possible.

  2. #2
    Join Date
    Nov 2011
    Posts
    11

    Restrictions in Access

    Well I might be mistaken But I do remeber reading about the "flaws" of MS access being that it becomes unstable or inoperable if you have more than 25 users in it at a given moment. even in a front end back end setup. Other than going to MS SQL Server or other type DB you could (which I had to do prior to getting SQL Server) was have a single back end with multiple front ends. I had a app that would then select the frontend with the least users in it and send the new person to that one. in this set up (say 4 FE's)you should be able to have 25 users in each front end and it would be like only 4 users in the back-end and you get your 100 users. SQL Server Express might be an option to you because its free, though look into the eula though, do not know what the limits are.

  3. #3
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    there is no hard and fast rule as to where Access hits problems. and in reality its usually not Access that has the problems but the underlying storage engine, which is called JET.

    JET is a file server orientated mechanism and isn't clever when you have large number sof concurrent users.

    there are things that you can do to circumvent this problem

    design the application using unbound controls / recodsets ( a lot more code to be handwritten, you can't use most of the whizzy designers)

    use another data storage mechanism such as a client server db, pick anyone you like from MySQL, SQL Server, DB2, Oracle whoever. keep the front end in Access. however you still have to code much of the glue logic between the user interface and the data. if you revert to the Access bound controls then you have the worst of both worlds, the extra load on the servers and the extra load on the local PC + Network. if you want to go down the client / server back end then rund, odnt' walk to your local geek bookshop and buy the Access developers handbook

    the precise number where palin vanilla Access craps out depedns entirely on the the number of users, the way the app was written and the hardware its running on. I doubt you will get a satisfactory applciation using JET with 100+ concurrent users doing data entry. if ts 15..30 at any one time then you may be OK, mebbe higher mebbe lower.. the complexity of the table design is also going to be an issue. the more complex the table design the more likely it will bring a JET db to its knees (complex joins can crucify JET)

    JET also is not happy runnign over VPN's. its will work OK on most modern networks but a VPN or remote connection is a recipie for problems.

    bear in mind the JET sends chunks of data to the client, which decides what it needs from that data, whereas a server application will ask the server for the data it needs and only that data is sent. meaning a server db will have a significantly lower impact on network resources than a file server db.

    you can split an Access JET db into two components., the back end (contains the data), the front end contains the user interface (forms, reports, most queries). ideally each user should have their own local copy of the front end. theres stuff in the code bank on this forum to handle deploying local front ends to remote desktops

    I knew of one app which is multi thousand concurrent users, with a high transaction volume that uses an Access front end, however the back end is a client server, used to be DB2 what it is now I haven't got a clue.

    what you could do is consider a web based interface such as ASP.NET, PHP, Ruby / god knows what. or a traditional language such as C, C++, VB, .NET, JAVA et al
    I'd rather be riding on the Tiger 800 or the Norton

  4. #4
    Join Date
    Feb 2012
    Posts
    3

    Thank You

    Thank you so much, I would like to know which one is the best for developing the application which can have more 100 concurrent users accessing the same data and modifying it concurrently.

    Looking for your reply

  5. #5
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    which one is the best, who knows
    the best for based on what criteria
    definign what best may be
    runs on cheapest hardware / software
    may be easiest to maintain over time
    may be total cost of ownership over the projected life
    may be whats a closest fit to the current knowledge or skills base
    may be what is a good foundation for the author to move on into another job


    first define what the objects or measurables are, thne based on that you can get a good idea of what is 'best'
    I'd rather be riding on the Tiger 800 or the Norton

  6. #6
    Join Date
    Feb 2012
    Posts
    3

    thanks again

    I am working for a private company where we have an access db crated in 2003 version, and excel macro conneted to it, users whoever has the querry related to any concern for the work they assigned to do they just put the querry in a cell and submit it to their respective supervisors, sup gets the intimation abt that and suggesst them what to do and how to do. it shared by many users.

    Now the issue with it we are facing is that we just got upgraded the CITRIX version (the client desktop application) so its not working at all for any users while the new version of CITRIX has the same 2003 excel and access.

    So what to do please suggest

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •