Welcome to SPN

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

Sign Up Now!

Multiple users running same report

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

  1. yar

    yar
    Expand Collapse
    Guest

    I have created a database to be used by multiple users. But, when more than
    one person run the same report from a form menu at the same time, the report
    gives me wrong data. the run report command I created uses quering tables,
    deleting and creating new temporary tables based on the criterias selected.
    However, when two or more users run the same report, the temporary table
    creates both individual's result in one table.

    Is there a way to avoid such problem in a multi user environment?

    yar
     
  2. Loading...


  3. FD

    FD
    Expand Collapse
    Guest

    If this is the exact situation then,
    U may create ur temporary table names by giving the prefix of userid,
    name or something unique to the user. This will create different
    temporary tables for different users. This should solve the problem.

    yar wrote:
    > I have created a database to be used by multiple users. But, when more than
    > one person run the same report from a form menu at the same time, the report
    > gives me wrong data. the run report command I created uses quering tables,
    > deleting and creating new temporary tables based on the criterias selected.
    > However, when two or more users run the same report, the temporary table
    > creates both individual's result in one table.
    >
    > Is there a way to avoid such problem in a multi user environment?
    >
    > yar
     
  4. Tony Toews

    Tony Toews
    Expand Collapse
    Guest

    yar <yar@discussions.microsoft.com> wrote:

    >I have created a database to be used by multiple users. But, when more than
    >one person run the same report from a form menu at the same time, the report
    >gives me wrong data. the run report command I created uses quering tables,
    >deleting and creating new temporary tables based on the criterias selected.
    >However, when two or more users run the same report, the temporary table
    >creates both individual's result in one table.


    Assuming you are running a split MDB where each user has their own
    copy of the FE you could then properly use a temporary MDB containing
    those temporary tables.

    See the TempTables.MDB page at my website which illustrates how to use
    a temporary MDB in your app.
    http://www.granite.ab.ca/access/temptables.htm

    Tony
    --
    Tony Toews, Microsoft Access MVP
    Please respond only in the newsgroups so that others can
    read the entire thread of messages.
    Microsoft Access Links, Hints, Tips & Accounting Systems at
    http://www.granite.ab.ca/accsmstr.htm
     
  5. Chriske911

    Chriske911
    Expand Collapse
    Guest

    > I have created a database to be used by multiple users. But, when
    > more than one person run the same report from a form menu at the
    > same time, the report gives me wrong data. the run report command I
    > created uses quering tables, deleting and creating new temporary
    > tables based on the criterias selected. However, when two or more
    > users run the same report, the temporary table creates both
    > individual's result in one table.


    > Is there a way to avoid such problem in a multi user environment?


    > yar


    yes, and this is happening because of a very big mistake of you
    do not ever use temp tables in the backend
    never, ever

    it does not only create the issues you mention but it also blows up the
    back end
    thus slowing the application down after a short while

    always create them in the front end and drop them when closing the
    database

    grtz
     
  6. Linc

    Linc
    Expand Collapse
    Guest

    I usually place a permanent "empty" table(s) on each front-end. Then use
    code to populate and delete the records in these tables as required.
     
  7. Tony Toews

    Tony Toews
    Expand Collapse
    Guest

    Chriske911 <chriske911nospam@yahoo.com> wrote:

    >always create them in the front end and drop them when closing the
    >database


    Also not a good idea as they blow up the front end too. Although not
    as bad an idea as in the back end. <smile>

    Tony
    --
    Tony Toews, Microsoft Access MVP
    Please respond only in the newsgroups so that others can
    read the entire thread of messages.
    Microsoft Access Links, Hints, Tips & Accounting Systems at
    http://www.granite.ab.ca/accsmstr.htm
     
  8. Chriske911

    Chriske911
    Expand Collapse
    Guest

    > Chriske911 <chriske911nospam@yahoo.com> wrote:

    >> always create them in the front end and drop them when closing the
    >> database


    > Also not a good idea as they blow up the front end too. Although not
    > as bad an idea as in the back end. <smile>


    > Tony


    the front end is usually on the local drive of a workstation
    nothing is keeping you from using auto shrinking on close
    and I do not mean dropping the tables but rather all of the data in
    them

    I've never considered using a third db as temp storage
    never heard about it from anyone until now
    maybe not a bad idea

    grtz
     
  9. Ron2006

    Ron2006
    Expand Collapse
    Guest

    It seems to me that bloat is still going to occur even if you use a 3rd
    mdb. The bloat on the users machine is automatically resolved, by a new
    version of the user's FE mdb. But if that doesn't change too often then
    perhaps a third db on the local machine that is compressed periodically
    might be the solution afterall.

    Ron
     
  10. Tony Toews

    Tony Toews
    Expand Collapse
    Guest

    Chriske911 <chriske911nospam@yahoo.com> wrote:

    >> Also not a good idea as they blow up the front end too. Although not
    >> as bad an idea as in the back end. <smile>

    >
    >the front end is usually on the local drive of a workstation
    >nothing is keeping you from using auto shrinking on close
    >and I do not mean dropping the tables but rather all of the data in
    >them


    Auto shrinking on close has been known to cause some troubles in the
    past.

    >I've never considered using a third db as temp storage
    >never heard about it from anyone until now
    >maybe not a bad idea


    See the TempTables.MDB page at my website which illustrates how to use
    a temporary MDB in your app.
    http://www.granite.ab.ca/access/temptables.htm

    Tony
    --
    Tony Toews, Microsoft Access MVP
    Please respond only in the newsgroups so that others can
    read the entire thread of messages.
    Microsoft Access Links, Hints, Tips & Accounting Systems at
    http://www.granite.ab.ca/accsmstr.htm
     
  11. Tony Toews

    Tony Toews
    Expand Collapse
    Guest

    "Ron2006" <ronnemec@hotmail.com> wrote:

    >It seems to me that bloat is still going to occur even if you use a 3rd
    >mdb. The bloat on the users machine is automatically resolved, by a new
    >version of the user's FE mdb. But if that doesn't change too often then
    >perhaps a third db on the local machine that is compressed periodically
    >might be the solution afterall.


    I prefer to create and delete the temp MDB as required. That is a
    very fast operation.

    See the TempTables.MDB page at my website which illustrates how to use
    a temporary MDB in your app.
    http://www.granite.ab.ca/access/temptables.htm

    Tony
    --
    Tony Toews, Microsoft Access MVP
    Please respond only in the newsgroups so that others can
    read the entire thread of messages.
    Microsoft Access Links, Hints, Tips & Accounting Systems at
    http://www.granite.ab.ca/accsmstr.htm
     

Share This Page