ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Crystal Reports, ODBC & Access >> ODBC General Issues >> Btrieve Error 35 After UT-A ODBCDDF
http://www.istechforum.com/YaBB.pl?num=1311694687

Message started by David Waldmann on 07/26/11 at 08:38:06

Title: Btrieve Error 35 After UT-A ODBCDDF
Post by David Waldmann on 07/26/11 at 08:38:06

CHANGES MADE
We recently needed to add a DSN to a client computer, and in the process ran UT-A ODBCDDF from that client computer.

PROBLEMS
Ever since then we have had problems accessing the database through the Pervasive Control Center and Crystal Reports on any client computer, each time getting a Btrieve Error 35:
[Pervasive][ODBC Client Interface][LNA][Pervasive][ODBC Engine Interface][Data Record Manager]The Btrieve file directory is invalid(Btrieve Error 35)

We also get that same error when running the Test from the ODBC Data Source Administrator, on both the server and client computers.

Furthermore, when we try to expand the Pervasive.SQL 2000u Engines section in the Pervasive Control Center from the server, we get the following error:
Unrecoverable error occured. Control Center will be closed now. (that typo is in the message)

TROUBLESHOOTING
We've tried researching the problem on this forum and the Pervasive forum, but none of the things we've tried fixed the problem including:

Running UT-A ODBCDDF (that's what seems to have caused the problem in the first place)
Ensuring there are no spaces in the directory path(s)
Restoring the DDF files we've been using for a few years from backups

Thanks in advance for help and suggestions to fix this.

Bethany

Title: Re: Btrieve Error 35 After UT-A ODBCDDF
Post by GasGiant on 07/26/11 at 10:25:50

You might try removing the view of the database in the Pervasive Control Center under Databases (Client) and recreating it.

Title: Re: Btrieve Error 35 After UT-A ODBCDDF
Post by Kelloggs on 07/26/11 at 11:29:51

This a path issue, no a ODBC issue. Running the ODBCDDF is not going to fix anything
Some how Evo has the path all wrong.

have you contact Lynn? I think there is a utililty to verify/change the path (where the location of the \DBAMFG and \DBAMFG\Default folders are)

The Pervasive Control Panel uses odbc to connect to it. The DSN has the wrong path (FILE.DDF, FIELD.DDF, and INDEX.DDF)

35 - DIRECTORY ERROR
An error occurred while changing to the directory that contains the Btrieve file. Either the drive specified in the GetDirectory operation does not exist or the pathname specified in a SetDirectory operation was invalid.

:-[

Kelloggs

Title: Re: Btrieve Error 35 After UT-A ODBCDDF
Post by David Waldmann on 07/26/11 at 13:00:43

Thank you for your suggestions.

GasGiant:
I tried that, and am still getting the same error.

Kelloggs:
Regarding the \DBAMFG and \DBAMFG\Default folders, I did find UT-E in which you can set the Default Path and Data Dictionary Path - is that what you're referring to? We have both of them set to our mapped drive P:\DBAMFG\, which I verified was valid by copying/pasting that into my file explorer - it worked, and the DDF files are there. If this is not what you were referring to, let me know and I will contact Lynn directly.

Also there is something I really do not understand at all. The ONLY thing we did in DBA was run UT-A ODBCDDF. From what it sounds like, doing that doesn't change the path - but if it doesn't, how did it get changed? And even if it did get changed through that, we restored the original DDF files, so wouldn't that fix the path?

Title: Re: Btrieve Error 35 After UT-A ODBCDDF
Post by Kelloggs on 07/26/11 at 14:20:08

have the folder/file permissions change? do you have a server? can the server open the PCC?

:-/

open your Pervasive DDF Builder (You need admin access) check the data paths

:-/

Title: Re: Btrieve Error 35 After UT-A ODBCDDF
Post by David Waldmann on 07/27/11 at 07:18:06

Thanks again for your assistance.

We didn't change the permissions manually, but I thought maybe they had been changed when we ran UT-A or restored the files, so I just checked the directory and the DDF files and they're set to Allow for Read & Execute, List Folder Contents, and Read for all the groups.

Apparently the DDF Builder was discontinued. This is from our Pervasive.SQL 2000i (SP3) documentation under User's Guide > Basic Troubleshooting > Frequently Asked Questions:

Quote:

What happened to DDF Builder and DDF Sniffer?
DDF Sniffer and DDF Builder were added to the Pervasive product line with the acquisition of Smithware in 1998. Neither DDF Sniffer nor DDF Builder are available anymore. They were replaced by DDF Ease, which was part of the Pervasive.SQL 7 database engine. DDF Ease has since been replaced by Pervasive Control Center in Pervasive.SQL 2000i.

DDF Sniffer and DDF Builder used the Btrieve API to manipulate DDFs, which was less desirable than doing it through the native relational interface of Pervasive.SQL. These products contributed to issues that were difficult to isolate and fix.

Is there something in particular you were thinking I should look at? As far as I can see there isn't any way to see/build DDFs. I thought maybe it would be Tools > Rebuild, but that didn't bring up a dialog or anything and I'm still getting the error.

Bethany

Title: Re: Btrieve Error 35 After UT-A ODBCDDF
Post by Kelloggs on 07/27/11 at 08:00:25

I would contact http://www.goldstarsoftware.com/

I still thinking that it is the path, but I could be wrong.

:)

Title: Re: Btrieve Error 35 After UT-A ODBCDDF
Post by BethanyW on 07/29/11 at 10:30:27

ISSUE RESOLVED!

I was reminded that we got some sort of error/notification when we were setting up the client DSN about one with the same name already existing, which I had forgotten about. After investigating all the options and settings in the ODBC Administrator, I came to realize that during the beginning of the process we accidentally created a new Engine DSN that overwrote the original one. That shouldn't have been a problem though because we used the same database, which had settings we couldn't modify on that computer.

These realizations came before we contacted GoldStar Software, and they recommended removing/recreating the DSN and checking the settings in the Control Panel's DBNames, both of which I had already done. Just for kicks I decided to create a new database with the same data/dictionary paths, and then modify the DSN to use that database instead - and it worked! Must be some fluke, but I'm sure glad it works now!

Thanks again for everyone's help!