Multiple users running same report

[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

 

[FD]

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.

 

[Tony Toews]

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

 

[Chriske911]

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

 

[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.

 

[Tony Toews]

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

 

[Chriske911]

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

 

[Ron2006]

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

 

[Tony Toews]

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

 

[Tony Toews]

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