Hi all,

Pervasive 8.7 on Netware.

I've configured a Named Database.
I've then enabled database security by setting a master password for
that database.
When I try and add a new database user, I get the following error:

[Pervasive][ODBC Client Interface][LNA][Pervasive][ODBC Engine
Interface][Data Record Manager]No such table or object.

However, the user is actually created.
But, when i go back into the user to then give the user some
permissions to the tables, I get exactly the same error again when i
try and save.

Has anyone got any ideas? I'm stuck. If I'd stuffed up the DDF path,
etc, then I wouldn't be able to view the tables.. so I'm not sure where
i've gone wrong.

Thanks
Dave

I've got an update to this --
X$Files table contains zero rows. (no errors opening it, it's just
empty)

Second, if I run a GRANT SELECT ON table1 TO user1 from sql, a row gets
written to X$Rights. I can connect to the database via ODBC and I can
do a select on table1, but not table2. Excellent, working as expected.

If the DDF files have something screwed, they could have been screwed
for years - because our app access the btrieve data files directly.
It's only now that we wish to access the database via ODBC in a read
only capacity.

If anyone has any ideas on how to fix the issue, please let me know!

Failing that, is there any major issue in just doing the manual SQL
grants as a workaround?

One problem I've encountered is even though the above grant statement
works, the following one does not (it errors complaining about the *) :

GRANT SELECT ON * TO user1

Any clues? I'd prefer not to do grants on every table individually if
can be avoided.

cheers
Dave

Ok I have an update after mucking around for a few hours. I know
little about Pervasive so forgive me ---
Firstly, X$Files contains no rows. I thought this to be odd.
Secondly, I tried doing a GRANT from SQL, and that seems to work. A
row is added to X$Rights and when I try to access the tables from MS
Access using ODBC, I can access the tables as per the permissions set
via the GRANT statement. (ie, I can't link to tables that i haven't
given SELECT permissions to -- excellent).

There could be inherited issues that have been around for ages in the
DDF's, as our application accesses the btrieve data files directly. It
is only now that we wish to access data via ODBC, and I want to enable
security such that the ODBC access is read only.

So --- can the DDF's be fixed? If not easily, is it a safe workaround
to just perform the SQL GRANTS and go my merry way ?

Secondly, I tried the following command and it errored, complaining
about the *.

GRANT SELECT ON * TO testuser
but
GRANT SELECT ON tablename TO testuser
works fine.

Any ideas? I want to give SELECT to all tables and would rather not
have to do every one individually!

Thanks
Dave

The DDF's definitely seem to be messed up. We've found that one old
DDF builder application used to create DDF's and supply the Btrieve
File name of "X$File.DDF" for X$File -- although the CORRECT Btrieve
File name is actually FILE.DDF. You can confirm this by running this
command "BUTIL -SAVE FILE.DDF FILE.UNF N 0" from the command line (with
security NOT enabled). The first line item should show FILE.DDF -- if
it doesn't, then you have problems. The others should be FIELD.DDF and
INDEX.DDF, of course.

Another possible problem is the use of varying directory paths in your
DBName, and it is finding multiple DDF files, but this is less likely
an issue.

Your best bet is to fix the DDF's, although this may need to be done
manually by changing the records within the DDF's themselves. You can
do this with the Function Executor if you know the file's owner name.

We can also provide a service to review and rebuild the DDF's, if
needed. If it is this problem as we suspect, then the cost will be
only $50.
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 did that command, and it shows X$File as "file.ddf" on the first
line.
One thing to mention is the DDF's are stored in a different directory
to the .DAT data files for the database. Is this an issue? (but like I
said, I can open the other system tables and my database tables no
problem)

Any other ideas?

cheers
Dave

Ok found that problem --- there was a FILE.DDF and a FIELD.DDF in the
same directory as the data files. I renamed those, and now I can open
the X$Files table.

However, I still get the table not found error when adding permissions.

I noticed X$Rights does not exist.

So, I performed a GRANT statement and that has generated X$Rights.

If I view the user in PCC, the select permission on that table shows
up. But, if I try and make any changes from the PCC, it errors with
table not found.

Any ideas on why this is happening? And, why a GRANT SELECT ON *
doesn't work?

cheers
Dave

I have done the GRANTS manually and I can connect via odbc.
One of the guys here is connecting via crystal reports, and crystal is
coming back asking for the Owner name.
? I've no idea what this is!

Dave wrote:

If you are using Crystal Reports for Btrieve, then the owner name that
Crystal needs is the owner of the data dictionary files. This MAY be
your Master password, or it will be something different if you have
PSQLV8.5 or above.

To overcome this, you would be better served by connecting from Crystal
via ODBC instead, using the native ODBC drivers. This does not require
an owner name, but rather will require a user/password (that you just
defined in SQL) to get in.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com

As for why you are having a problem with the GRANT statement, I cannot
say, unless the DDF's are stil messed up in a way. You can try running
the Check Database Wizard against the DDF's to see if they are OK or
not.

I did the following on DEMODATA, and had no problems...

grant login to 'Fred':'fred'
#
grant select on * to 'Fred'

Worked fine. Try your own setup against Demodata to see if that helps.
If so, then the problem is definitely in your DDF's.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com


Dave wrote: