I wish to create a temporary table that on closing will tranfer data to a
main table. My problem is that on a network if more than one person opens the
tempory table, CONFUSION. I would like to use a time stamp in the name of the
temp table to eleviate this problem. could some one show me the code needed
to create a unique table title for each user. also the method to transfer my
temporary table data to the main table.

Thanks

--
Message posted via http://www.accessmonster.com

"anthonyspeirs via AccessMonster.com" <u40053@uwe> wrote

If you have multiple users, each should have their own copy of the front
end, and that is where a temporary table will be created, so you will not
face this problem.

If you feel compelled to do otherwise, then, no, (at least) _I_ will not try
to explain to you how to do what you shouldn't be doing. The CurrentUser
function will return the login name of the current user, if you have put a
password on the Admin user and require Access users to log in; there are API
calls to obtain identification of the user's machine or network station in
the API list at http://www.mvps.org/access.

Larry Linson
Microsoft Access MVP

Larry Linson wrote:
Thanks Larry,
I have never designed a database to work across a network before. I didnot
think this through to the end.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200802/1

Almost always, there is a better approach to problems than a temporary
table. Sometimes, though, it seems unavoidable.

You'll find an article on MVP Tony Toews' site,
http://www.granite.ab.ca/accsmstr.htm about creating a temporary database to
hold your temporary table... when you are done with the temp table, you can
delete the database. If you create the temp table in your front-end
database, you will experience database bloating and have to frequently
repair and compact it, or replace it with an unused copy of the front-end.

You'll find a lot of information at Tony's site about multiuser databases.
There's a list of links to other very informative Access sites at
http://sp.ntpcug.org/accesssig/default.aspx. That may smooth your path
somewhat.

Larry Linson
Microsoft Office Access MVP


"anthonyspeirs via AccessMonster.com" <u40053@uwe> wrote

"Larry Linson" <bouncer (AT) localhost (DOT) not> wrote in
news:8GNwj.33610$v57.12809@trnddc05:

I've used a temporary table just once when trying to deal with an
"abnormal" design inherited from a web genealogy site. Even then I was
careful to create it within a Transaction and to do a Rollback after using
it so that it never really caught, or had to be deleted.

Larry Linson wrote:
The only "better approach" I can think of is hideously convoluted nested 4
layers deep queries that take 6 hours to run </dripping sarcasm with slight
exaggeration>

I use temp tables - frequently - but for mostly one purpose: reporting. I
just find it intuitive and efficient to summarize data into a temp table one
or a few columns at a time, then draw the report off it. Some bloating does
occur, and occasionally a temp table will corrupt and suddenly start
throwing "too much data for field" (whatever that old error is) so the app
has to be redeployed. But the ease of development and speedy execution and
control and analysis you get from the combination of scripts and temp tables
far, far outweighs those issues. IMO!

"lyle fairfield" <lylefa1r (AT) yah00 (DOT) ca> wrote

I used temp tables a few times during my early experiences* using Access,
while I was still learning "The Access Way." Once I learned to work with
Access rather than against it, my perceived need for temporary tables
dwindled to near-nothing.

* Those were the days when I wished there was some gaunt-faced
Master with a scraggly beard whose advice began, "Grasshopper..."
But all the Masters, gaunt-faced and otherwise, were still learning
Access just as the rest of us** were.

** That is, we of the Great Access Unwashed.

But, that does not mean there are not situations which demand them. I
certainly make no claim to have worked in all the application areas for
which Access can be used, and some of those may present problems for which a
temporary table is the proper solution. I never had a need for
page-after-page of from-scratch SQL but I understand why Tom Ellison needed
it -- we worked on entirely different types of application.

I've done some rather complex reports, but never needed a temporary table.

Larry

Larry Linson wrote:
Maybe i dont need a temporary table then, that was my solution to the bosses
breif. Her breif read "allow users to enter records and if necesary change
those records, but only in the that login session. When they re login they
will be looking at a blank slate (no records)."
So from the threads i have read it sounds like a temporary database is the
way to go. Would you agree?

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200802/1