Temporary tables

  • Thread starter Thread starter Peter Kinsman
  • Start date Start date
P

Peter Kinsman

I have already posted this in the TechNet Terminal Services area, but
received no reply. I suspect the answer is more Access related than
Terminal Services related so here goes!

I am building an Access database which among other things will create and
update Bills of Materials. This involved temporary tables, to display the
workings on the screen. The permanent tables are in a separate database.
In a normal environment, each user would have their own copy of the
temporary files, but running under Terminal Services, this is presumably not
the case, so I need to keep each user's records separate.
I have started by using a RunNumber, which is updated each time a User opens
the program. This is then used as an extra field on the temporary table.
It works in the two instances I have updated, but is very tedious to
install.
Another solution - similar to that used in the IBM midrange environment from
which I come - would be to create a temporary table whose name incorporated
the Run Number, but that would mean creating temporary queries as well.
Is there an established method of doing this when running under Terminal
Services please?

Many thanks

Peter Kinsman
 
John

What a brilliant idea. I have used the user's TEMP library on an AS/400 in
the past, but hadn't thought of using it in this context.

Many thanks

Peter
 
John

I have been having second thoughts about this solution.
The individual users need separate tables not to save the data, but to stop
their records becoming tangled while processing. If user Bill opens the
database, then his work tables will typically be at C:\Programs and
Settings\Bill\LocalSettings\Temp. If user Fred then opens the program while
Bill is still using it, will it be able to link to Bill's work tables?
One solution might be to make the update functions exclusive rather than
just locking individual records.

What do you think?

Cheers

Peter
 
Peter,

I guess it depends on how the Terminal Services sessions are configured.
But as far as I know, the TEMP environment variable can be relied on to
point to a folder (a) that is not shared by any other sessions and (b)
in which the user has RWXD permissions (needed in order to create,
modify and delete the temporary mdb.

So if Bill's TEMP variable points to
C:\Documents and Settings\Bill\LocalSettings\Temp
it's likely that Fred's will point to
C:\Programs and Settings\Fred\LocalSettings\Temp
and certain that it will be different from Bill's. So Fred's instance of
the database will create its temporary mdb in a different folder from
Bill's, and the two sets of temporary tables will be quite independent.
It happens that I was trying this out yesterday with our IT department,
with a view to making a database available via Citrix (which uses the
same basic technology as TS).

Something that doesn't seem to have been mentioned in this thread is
that each session should have sole use of a copy of the front end mdb.
Having multiple TS sessions sharing the same front end file is - or so I
understand - asking for trouble. See e.g.
http://www.granite.ab.ca/access/terminalserver.htm

John

I have been having second thoughts about this solution.
The individual users need separate tables not to save the data, but to stop
their records becoming tangled while processing. If user Bill opens the
database, then his work tables will typically be at C:\Programs and
Settings\Bill\LocalSettings\Temp. If user Fred then opens the program while
Bill is still using it, will it be able to link to Bill's work tables?
One solution might be to make the update functions exclusive rather than
just locking individual records.

What do you think?

Cheers

Peter
 
Thanks for that. If my "tmp" tables are in the front end and each user has
a separate copy, then I have no problem, but presumably they do not. I will
check with the network company before I waste any more of my - and your -
time and effort.
The concept is very similar to the "Multiple Requestor Terminal" situation
on IBM midrange machines when menory was expensive. A single instance of a
commonly used program stayed in memory, and the data for each of the users
was rolled in, processed and rolled out again - excelt that unter TS I think
all the data gets merged.

Thanks again

Peter

John Nurick said:
Peter,

I guess it depends on how the Terminal Services sessions are configured.
But as far as I know, the TEMP environment variable can be relied on to
point to a folder (a) that is not shared by any other sessions and (b)
in which the user has RWXD permissions (needed in order to create,
modify and delete the temporary mdb.

So if Bill's TEMP variable points to
C:\Documents and Settings\Bill\LocalSettings\Temp
it's likely that Fred's will point to
C:\Programs and Settings\Fred\LocalSettings\Temp
and certain that it will be different from Bill's. So Fred's instance of
the database will create its temporary mdb in a different folder from
Bill's, and the two sets of temporary tables will be quite independent.
It happens that I was trying this out yesterday with our IT department,
with a view to making a database available via Citrix (which uses the
same basic technology as TS).

Something that doesn't seem to have been mentioned in this thread is
that each session should have sole use of a copy of the front end mdb.
Having multiple TS sessions sharing the same front end file is - or so I
understand - asking for trouble. See e.g.
http://www.granite.ab.ca/access/terminalserver.htm
 
Back
Top