hi all,

i'm having a play & turned on database security on a test box, as we
have found that accessing the database via ODBC from a linux box
connects (and allows sql updates) without specifying a
username/password!

i now want to turn the database security off, but when I try (from
PCC), I get an error :

[Pervasive][ODBC Client Interface][LNA][Pervasive][ODBC Engine
Interface][Data Record Manager]This database has no security so the
command has no effect.

I find this a bit odd, as there are users in the Users pane, users in
the X$USer table, and the security tab on the properties of the
database says "Database Security: Enabled".

I get a similar error if I try and delete one of the users - "This
database has no security so the command has no effect."

Anyone got any ideas?

thanks
Dave

no one got any clues for me ?

Sounds like the DDF's might be bad. Try restoring them from a backup
copy with the engine shut down (which should clear the security stuff
out). You can try re-enabling security right away, but I'd recommend
running the Check Database Wizard against the DDF's themselves first to
be sure that the DDF's are properly defined.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - November, 2005 ***
*** Chicago: Pervasive DataExchange Class - November, 2005 ***

Dave wrote:

Thanks Bill.
I found the cause of the problem today in fact. I installed the SP3
(8.7) client on my workstation and that appears to have fixed the
problem. If I fire up PCC from an SP1 workstation, the problem appears
... so looks like a bug in the client itself !

On a side note, i'm just trying out your killuser utility.
I am using the following command line on my test box:

killuser /Sdanshape_test /UMaster /P123456 /D /KS

However, it doesn't seem to work. The output from killuser is as
follows:

Status from pvStart = 0
status from pvConnectServer = 7004

Any clue as to what that error code means? The connections are still
visable in Monitor.

Cheers, thanks heaps
Dave

Dave wrote:

The 7004 indicates a generic connection error. Perhaps the Username or
password was incorrect? This user/pass combination is NOT the "Master"
password to the database, but rather the same admin-level password that
you use to connect to the Monitor remotely.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - November, 2005 ***
*** Chicago: Pervasive DataExchange Class - November, 2005 ***

Thanks Bill. So it uses the OS authentication, not the database
authentication?
To log into Monitor, I use my OS username/password, which, as I'm on
Novell, is a fully qualified NDS name, including the preceeding period
and container names.

See the following output:

R:\General Software\Pervasive>killuser /Sdanshape_test /U.admin.test
/P123456 /D /KS
KillUser Version 1.4: 03/22 (C)2002-04 Goldstar Software Inc.

Status from pvStart = 0
status from pvConnectServer = 0
status from PvGetServerName = 0
Unable to Retrieve Active Client Information (Status=0)
status from PvDisconnect = 0
Status from pvStart = 0

That is correct. The KillUser tool, as well as his big brother
PSConfig, is simply an extension of the Pervasive Distributed Tuning
Interface (DTI). As such, it has the same authentication requirements
as the Monitor tool.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - November, 2005 ***
*** Chicago: Pervasive DataExchange Class - November, 2005 ***

Dave wrote:

Cheers Bill. If that's the case, have you got any idea why the above
example isn't killing the connections? Using the same login creds in
Monitor works no probs.

ie
username: .admin.test
password: 123456

cheers & thanks,
Dave

Get rid of the /D switch -- the debugging option may be affecting the
processing of the error message and prematurely exiting the loop.

In the meantime, I'll check the Debug code & see if this is what is
happening...
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - November, 2005 ***
*** Chicago: Pervasive DataExchange Class - November, 2005 ***

Dave wrote:

Dave wrote:

Yup -- just checked the code & the Debug Logic is flawed. Will
probably not be changing this on the free version. Just don't use the
/D option, and it should work.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - November, 2005 ***
*** Chicago: Pervasive DataExchange Class - November, 2005 ***