I recently created a new process with a bunch of PRIV tables and 1 WORK table
using Pdox 9 which is loaded on Windows XP SP2 PCs. The database sits on
a Window 2003 R2 SHARE Machine. During the test phase I gave a Test User
FULL CONTROL to my folder to allow the User to 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.
The Group has permissions:
Read & Execute
List Folder
Read
Write
Which translates to ALL permissions except
Full Control, Delete, Change Permissions & Take Ownership
If ADVANCED button is selected to look at the EFEFECTIVE PERMISSIONS Tab.

The only thing the new process does that is NOT DONE elsewhere in the App
is SORT:
cashTbl.attach("CashFlow.DB")
sort cashTbl
on "Year","ContractNo", "StreetCode",
"RptYear", "BgnDate", "EndDate"
to cashTbl
endSort
cashTbl.UNattach()
CashFlow.DB is a WORK table

The above SORT is done 3 times in the ARRIVE event and once in the PUSHBUTTON
event.
Once you log out of Paradox and go back in you will see 3 TMPSRnnn.db tables.

How do I fix this and could this be the reason for several GPVs throughout
the day while using the App even if you ARE NOT running the new process?

TIA

Jeanette

Well, if Paradox creates temporary tables and doesn't have rights to delete
them, those tables would still be there.

Does this sum up what you are seeing?


--
------------------------------
Tony McGuire

you MUST have complete, absolute, full rights to every Paradox folder.. temp
tables must be deleted.. lock files must be deleted.. other tables that you
specifically want to delete, must be deleted..

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

What they said.

Liz


Jeanette wrote:

FIRST, I made a MISTAKE!

MY COMMENT SHOULD HAVE READ:
The Users that are allowed to use the App in Production are in a Group. Now
that I have moved the process to Production
a TMPSRnnn.db is created when a Group User runs the process. Once s GROUP
USER logs out of Paradox and goes back in you will see 3 TMPSRnnn.db tables.


The Group has Security:
Read & Execute
List Folder
Read
Write
If the ADVANCED button is selected to look at the EFEFECTIVE PERMISSIONS
Tab for the Group you will see that the above security translates to my FULL
CONTROL EFEFECTIVE PERMISSIONS except the Group specifically DOES NOT HAVE:
Full Control
Delete Subfolders and Files
Delete
Change Permissions & Take Ownership

For several years the App has run without the above mentioned Permissions
without concern that a User would DELETE a Production table OR create a SubFolder
in the Production area OR oth such stuff for thos Users that are somewhat
savvy.

1. Are you folks telling me that the Group Users must/should have FULL CONTROL
to the folder where the Production data resides?

2. If YES, why have we been OK for several years with the above Security/Permissions?

3. Would the above conditons cause ONGOING GPVs throughout the day OR shall
I address GPVs in a seperate Posting?

TIA

Jeanette



Liz McGuire <liz (AT) paradoxcommunity (DOT) com> wrote:

User count or usage or data volume increasing could be why you're now
seeing more problems. What we can't know are the details of past
problems which may have been caused by this.

Here's how a Paradox/BDE application is supposed to work:

1. We have a directory (or more than one, but we'll work with one) where
the data lives, and another directory where the .NET file lives and each
user has a PRIV directory.

We start with no open instances of Paradox, no lock files, no net file.

2. User number 1 fires up Paradox. Paradox loads the BDE. The BDE sees
there's no .NET file and creates* one. The BDE then creates* .LCK files
in PRIV. The user opens the application, thus opening tables in our
data directory and the BDE creates* .LCK files in said data directory
and makes an entry** indicating what locks the user has on the tables.
It also makes an edit** in the .NET file.

So far, we need the following rights (other than "list" and "read",
which are a given):

* Create - in the .NET directory, the PRIV directory and the data directory

** Edit - in the .NET and the data directory (I think edit in PRIV goes
without saying)

Opening a table probably requires execute rights, not really sure.

3. Other users come. For each user who opens Paradox and starts the
application, the BDE makes entries in the .NET file and in the .LCK
files in the data directory and creates .LCK files in PRIVs.

The above rights are still enough - we're creating and editing.

4. A user closes the app (and Paradox), but others are still using it.
The BDE edits the .NET and .LCK files in the data directory and deletes
the .LCK files and temp tables in PRIV, probably any temp files the user
caused to be created elsewhere too (I know of no comprehensive list of
directories where the BDE creates temp files; testing a year or two ago
showed the BDE sometimes uses the dir above the one the data is actually
in, so we now all recommend the data above all your Paradox dirs be
unused and have full rights like the Paradox dirs).

We now need to add delete rights in PRIV (possibly elsewhere, if the
user caused temp files to be created elsewhere). If the LCK files in
PRIV don't get deleted, there's a high likelihood of "different .NET" or
other errors the next time the user starts the app.

5. Steps 3 & 4 repeat ad nauseum through the day. The .LCK files in the
data directory grow and grow and grow and grow. (The .NET file stays at
13 KB, go figure.) This is all as it should be.

6. Finally, at the end of the day, the last user exits the application.
The BDE deletes their PRIV LCK and temp files, edits the .NET file and
*deletes* the LCK files in the data directory.

* We now need delete rights in the data directory (for sure).

Here's what happens if we don't have delete rights in the data directory:

The lock files grow and groW and grOW and gROW and GROW until they're so
BIG that Paradox won't work any more and your application runs slower
than molasses in winter and users get impatient with it, so they
ctrl+alt+delete it, which at first just causes index out of date errors,
which cause application errors where the corrupt index is used, and
frustration grows and users complain to each other about how stupid this
app is or how stupid IT are or how slow the network is and they
ctrl+alt+delete the app some more and cause data corruption (unless
you're really lucky - glory to Paradox, the BDE and NetWare), some users
power off their computers rather than Crtl+Alt+Deleting and pretty soon
you've got corruption and GPVs and GPFs and other errors all over the
place. Meanwhile, you're having to take the app down in the middle of
the day to run table repair and management are yelling at you for lost
productivity...

All because:

a) the users don't have delete rights, so the LCK files never get
deleted when the last users leaves the app (for lunch, at the end of the
day, or whatever) and so they get to an unmanageable size (this is a
known and documented issue - lock files cannot grow infinitely - the
closer they get to 1MB in size, the slower the app is and the closer
failure comes)

and/or

b) your users are lazy and leave the app and their computers running
24x7 so they don't have to restart it, thus leaving locks forever and
interfering with your backups - not to mention losing memory to leaks
for days on end, leading to other problems.

This is the reality of Paradox. Rights and configurations must be set
to *support* it, not to *fight* it.

There are 2 ways to help avoid users deleting tables:

1) Use some obscure drive letter for your Paradox files and don't put
any other files there and don't allow users to create files at the root
of the drive. Have nothing but folders at the root of the drive.

2) Use UNC rather than mapped drives, so that it's harder for users to
find where your Paradox files live in the first place.

I suppose you could try using some other tool, run by some user with
delete rights, to try deleting the LCK files from the data dir every now
and then, but IMO, that's a bad solution. Just give people delete rights.

Liz

Liz McGuire wrote:
....recommend the *directory* above all your Paradox dirs...

In other words, users need the following rights to directories where
Paradox tables and .NET file live:

*List
*Read
*Create
*Write
*Modify
*Delete
(not sure on Execute)

....which translates into: frequent, reliable backups.

Liz

excellent explanation of the internals, Liz.. !!!

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

Thanks.

Can you tell management have yelled at me? <g>

For the record, I wasn't the one who decided users shouldn't have delete
rights in the data dir - that was someone before me - as soon as I found
out they didn't, I told the network manager to give them delete rights
and that solved a lot of problems (until our user count caught up with
the poor design... we're still trying to out-run that one).

Liz


Steven Green wrote: