I recently created a new process using Pdox 9 – Windows XP SP2
with a bunch of PRIV tables and 1 WORK table.
During the test I gave a Test User FULL CONTROL to my folder
so that User could enter data and troubleshoot the new process.

Now that I have moved the process to Production
a TMPSRnnn.db is created when a User (and not me) runs the process.
The Users that are allowed to use the App in Production are in a Group.
I now see that the Group has permissions:
Read & Execute
List Folder
Read
Write

While watching Shark last night I had ‘a moment of brilliance’ and thought
that maybe I should add MODIFY Permission to the Production table so that
the Users can sort the table and eliminate the creation of the TMPSRnnn.db
table !
Bad Idea.
Not only was the TMPSRnnn.db created but the Production table was DELETED!

There are no other processes in Production where the User sorts a Production
Table - keys/index will not work for the new process... well they probably
will if I worked at it – but for now I need to find out about the TMPSRnnn.db
table that’s created and move on and maybe get back to this process sometime
in the future to implement keys/index …

1. My in-house Admin Staff has never heard of TMPSRnnn.db tables
2. Is my thinking correct about WHY TMPSRnnn.db table is created?
3. Did the addition of the MODIFY Permission cause the deletion of the production
table?
4. If I give Full Control to this one table what can the Users do that they
are unable to do with the other tables in Production?

TIA

Jeanette

temp tables are created in MANY situations, and are almost always
automatically deleted at the end of a clean process.. even if they aren't
deleted, they are basically a non-issue..

why does this one bother you?

--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales

Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards

"Jeanette" <HarrisJR (AT) bwsc (DOT) org> wrote

A. the production area will be filled up with unneeded data SINCE they are
not being dropped - HOWEVER, I can get over it
BUT I'm STILL interested in replies to:
1-4 below

TIA

JEANETTE

///////////////////////////////////////////////////////////////

"Steven Green" <greens (AT) diamondsg (DOT) com> wrote:

temp tables only appear in the PRIV, and can be safely deleted externally,
on the way out, or before re-loading.. if they're appearing in what you
think is the "working" directory, you've got a problem..


you hadn't, either, right? (g)


if your theory was that it was the User account, no..


don't know anything about your app, but again, no..


you MUST give full control to every folder that uses Paradox.. if for no
other reason, that's what is needed for the lock files to work properly..


--
Steven Green - Waldorf Maryland USA

Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Support & Sales

Diamond Sports Gems
http://www.diamondsg.com/gemsmain.htm
Sports Memorabilia and Trading Cards

These TMPSRnnn.db tables are not created by me and saved and used in the PRIV
directory. They are being created by Users that DO NOT have FULL CONTROL
permisions in the WORK directory in the background.
I thought I had made that clear, sorry...


"Steven Green" <greens (AT) diamondsg (DOT) com> wrote:

Jeanette,

Paradox *must* have read, write, create, modify and delete rights in the
dirs where .DB files live or your app will have problems. The only
exception is if you create directory locks, and place them in the
directory, thus making it read-only to Paradox, then it only needs read
rights.

"Paradox" in this case, obviously, means the user who's logged in and
running Paradox.

Liz


Steven Green wrote:

We know that. The BDE / Paradox creates them as needed for certain
functions. Your code uses those functions.

Note that the BDE has been known to create files above the PRIV dir
(anyone remember if that extends to the WORK dir as well?), so it would
be good for full rights to be granted for the dir above where .db files
live as well.

Liz


Jeanette wrote:

CLARIFICATION:

I found that one of my sort statements on a WORK table did not have an UNattach()
after the sort was completed.
Once I added the UNattach() statement I am NO LONGER getting the creation
of TMPSRnnn.db tables


"Jeanette" <HarrisJR (AT) bwsc (DOT) org> wrote: