Receiving Error=49153 once security is applied to databases?

[Apollo6]

I am running a program called Accpac, an accounting program that uses Pervasive.SQL for it's backend.

Accpac Version: 5.1A
Pervasive Version: 8.0

The Accpac program connects fine without security applied to the database. However, once I setup groups/users, I get the following error:
"Cannot access database (error=49153). See Help for more information."

The odd thing is that with security applied, I can connect to the database via ODBC connections, ie MSAccess, Crystal, etc., and how I have the user security setup works perfectly. But when I go through the Accpac program, frontend, I get the error.

Any suggestions? Possibly the steps in which I apply the security? Possible patches that need to be applied to Pervasive?

Thanks

 

[zemp]

See thread631-577354.

zemp

 

[Apollo6]

zemp-

I actually found that post already and tried what it mentioned with no luck. The Function Executor finds no errors, at least on the two tables I tried. Would I need to run it against every table in the database?

Thanks for the feed back.

 

[zemp]

No, the function executor should fail to connect as your ACCPAC has. Bottom line is that 49153 is just too generic, somehow you need to narrow it down.

You can try rebuilding your ODBC connections through database setup.
You can try installing Pervasive V8 SP2.

zemp

 

[Apollo6]

I am downloading the SP2 file now. It seems like I remember reading something about possibly the error maybe caused if the path to the actuall database files is greater than 8 characters. For example, I have it installed on the server in the following directory:

C:\Program Files\ACCPAC\DATA

Should I install ACCPAC in it's directory on the root of the drive?

 

[zemp]

I don't think that is the problem (maybe in the DOS ACCPAC Plus). I have always used the default and other mapped locations without problems. Some have had very long names.

zemp

 

[Apollo6]

Some of the articles I've read mention the Workgroup Engine... Do I need that installed to have security enabled on the Pervasive database and still allow the Accpac program to access the tables?

Also, something about Gateways... Is this something that needs to be configured and would it cause the problem preventing Accpac from accessing the secured tables?

 

[zemp]

No, the workgroup engine is a local or P2P installation rather than a client/server install. The Security is still handled by the SM.

zemp

 

[Apollo6]

It still is not making any sense why the two pieces don't work together. The SM in Accpac works fine for restricting program access from user to user. My problem, rather, my bose's problem, which becomes my problem, is that those same users who have restricted Accpac access have complete access to all the Accpac tables via ODBC unless the security is enabled on the Pervasive side. But when security is enabled on Pervasive's side, Accpac cannot connect to the database at all. Grrr, just doesn't make sense.

Thanks for the suggestions anyway, still working on it.

 

[zemp]

Have you tried creating the ACCPAC users on the pervasive database. It sounds more and more like a rights issue.

The SM determines the security and then uses the ODBC. From there I don't think that it worries about security any more. I believe Pervasive datbase security is independant of ACCPAC security. So you may have to play with the settings to get through both layers of security.

zemp

 

[Apollo6]

Okay, after reading some more stuff, I reran the function executor against the file.ddf and it returned the following error:
"Btrieve Status 51"
"51: The owner name is invalid.
The possible causes for this status code are as follows:
If the application received this status code from a Set Owner operation, the owner names specified in the key buffer and data buffer did not match.
If this status code occurred after an Open operation or a DROP TABLE statement, the application attempted to open a file that has an owner name assigned to it. The application must specify the correct owner name in the data buffer. Make sure that the owner name is null-terminated in the data buffer, and that the data buffer length is set long enough to include the owner name plus the null terminator.
If an application received this status code when removing a file from continuous operation mode, then the client ID of the calling application differs from the client ID of the application that originally put the file into continuous operation mode."

I am not sure what to do with this...

 

[Apollo6]

All for nothing... Pervasive.SQL v8.0 security is not compatible with any version of Accpac below 5.3A. In addition, if upgraded to Accpac v5.3A, Accpac requires that Pervasive.SQL be upgraded to v8.6 or later.

Just thought I would share what I found out.

 

[zemp]

Not for not, good information that I learned something from and it will also help others. Thansk for posting it.

FYI Pervasisve 8.6 is the application of Pervasive V8 SP2.

zemp