Macola 7.6.102 Error Code 030 3

[CRUhoob]

Encountered error code 030 on multiple OE files (message 0430). Tried using the Pervasive Rebuild utility, and it claimed that the rebuild was successful and all records were recovered. When I subsequently rebuilt the files in Macola/System/Process/Rebuild, still got the same error code. Also cannot export the files.

Any idea what error code 030 is and how to fix it?

 

[MacolaHelp]

What version pervasive? There is documentation in the pervasive group on error codes. This is from help in PCC v7.94, which was also the description in the 6.15 manual:

30: The file specified is not a MicroKernel file

This status code is returned in one of the following situations:

• The MicroKernel did not create the file, or a pre-v3.x MicroKernel created it.

• While using an earlier version of Btrieve, you opened a file created by a later version that has a format incompatible with the earlier version.

• The first page of the file may be damaged. Use a backup copy of your data file. If you receive this status code and you suspect that the header page of the source file is damaged, recover the file as described in the Pervasive.SQL User’s Guide
.

• You have attempted to access a valid Btrieve file. This status code is returned when old engines access newer file formats. A likely scenario is that data created by a new server engine is later used by an earlier workstation engine. Status 30 can be reported if the file format is newer than the MicroKernel engine attempting to open it. Particularly, accessing a 7.x file with a 6.x engine causes this error.

NOTE: Previously, accessing a 6.x file with a 5.x engine returned Status 2: "the application encountered an I/O error"

Sounds like a corrupted file problem to me. What happened between the time it worked and now?

 

[CRUhoob]

Thanks for the quick response.

We were running on an NT server until 3/26. It was locking records and freezing on a regular basis, so we migrated to a windows 2000 server. We are currently running Pervasive 7.0. We were also experiencing BTR errors on the 2000 server, and rebooting on a daily basis has not been uncommon. (We are in a software search now, and are looking at Macola ES, Epicor, and SAP.)
Between then and now, we have learned that our backups were not saving locked files, and it looks like our restore option is 3/26 - obviously not a happy situation. The files that were corrupted were not being saved since that time. We have internal discipline issues to resolve.

Again, thanks for the response. Your list of potential causes helped us eliminate a number of possibilities.

thx

hoob

 

[tpllc]

There is a utility that was for sale called BTVIEWER that often was able to recover these files. I cannot guarantee it but has worked very often for me in teh past. I never use the progression rebuild as it only tries to re-index the table and not rebuild it. The better path is to export initialize and import. But since you cannot export that won't be a help. If you want to you could send the file to me with the DDF files also and I will try and recover the file, If I cannot I won't charge you but if successful then I'd have to charge for the work. If you want to try this contact me off line at shenley@trianglepartners.com



Steve Henley
trianglepartners.com
Exact Software consulting, sales and implementations.

 

[MacolaHelp]

The problem is probably not going to be solved by restoring from backup if what I suspect below is true. Anytime you rebuild a file in macola or pervasive you may revisit the problem. See below:


It sounds like when you reinstalled on the new server you may have your configuration for compatibility set to version 7 instead of version 6. This will cause exactly the type of error you are experiencing. There is a way to recover. You have to export all the files listed as version 7x in the btrieve maintenance using macola or pervasive. Then you have to stop the pervasive engine, change the setting to version 6x. Rename the "bad" files to a new name so it holds the place on the server and you can get them back if needed. Then initialize the affected files using macola or pervasive, which will create new empty v6 files based on the ddf. Then import the files back in again using macola or pervasive.

This setting is well documented in the macola installation documents. Rebuilding files with the version set to 7x in either macola or pervasive will cause this condition. Was a macola dealer helping you with this? I know people have gotten away from using btrieve, but it does help to have the proper documentation to understand how it should work. I know it seems odd that the version in pervasive should be set to 6x when you are running a 7 engine, but when Macola released the progression product, btrieve 6x was the current engine and the ddfs are based on its structure.

Let me know if you need further assistance or insight.

 

[dgillz]

I believe Macolahelp is correct. Please check your btrieve settings and make sure the create file version is set to 6.

Software Sales, Training, Implementation and Support for Macola, eSynergy, and Crystal Reports

http://www.gainfocus.biz

"If you have a big enough dictionary, just about everything is a word"
--Dave Barry

 

[CRUhoob]

Thanks to all who helped us in this restore -

Status: the restore is up and running after the move back to Pervasive 6x from 7 and a complete initialization and import of all data files.

New Issue: Workstation clients are inop - MAC32UP.lbr errors. We have reinstalled the Pervasive client software on each workstation. We cannot identify what has changed since before the crash with the exception of the move to 6x. In essence, we are running like a single user. We also cannot access the program with more than one user running remotely off a terminal server.

I don't sleep well anymore.

 

[MacolaHelp]

Mac32up.lbr is in the macola root directory on the server. Do you still have btrieve 6.15 components on the server or workstation? When macola installs out of the box it comes with local btrieve 6.15 components so that you can run it as a stand alone in demo mode with a set of btrieve 6.15 for limited distribution. When you switch to a 7x or higher engine, you need to run the renbtdll.exe and delbtdll.exe on server and workstation to ensure that macola clients are talking to the server engine and using the proper dlls locally. You can manually remove the macola client from the workstation by deleting c:\program files\common files\macola shared, the macola registry key in HK\local\software and the macola7.ini in c:\windows. Also the program group if you like. Then rerun the macola client install from the server. BUT FIRST:

Be sure you can query a btr file from the workstation by using the maintenance function in pervasive and choosing a file you know has data from your macola data folder, maybe apvenfil.btr, for example. If the maintenance utility returns stats to you when you "load information", you have connectivity to the server at the pervasive db manager level.

I'm confused about your configuration. Do you access macola on the 2000 server via LAN AND TS? Which one is running like a single user? Do you have the correct reg file for multiple users in the macola root directory? Did you install the pervasive and macola clients on TS logged on as administrator and using add/remove programs? Have you granted all users rights to the registry keys for macola, pervasive, and odbc?

 

[CRUhoob]

We can run one workstation at a time with no problems. The process W32MKDE.exe is running when we are in Macola. If another user (either terminal server or mapped drive) tries to start Macola, it fails with the Mac32up.lbr error, but the W32MKDE process still runs.

If everyone is out of Macola, and you go into the task manager and terminate the W32MKDE.exe process, you can start Macola with no problems, but then a different user cannot start Macola.

Where do you look to see if user licenses are installed and/or were is the configuration area to tell the database engine we want to grant access to more users? What file is the “correct reg file for multiple users in the macola root directory”?

Security is not an issue as everyone has full permissions on the Macola directories.

Is this something to do with the Screens directory?

Thank you so much for your help.

 

[MacolaHelp]

The permissions need to be adjusted on TS or the LAN client trying to access macola in the REGISTRY, not at the server level. W32mkde.exe means you are running the "out of the box" db manager for btrieve 6.15 shipped with macola 7x, which is indeed single user. Do you have the documentation on how to move from 6.15 to 7x btrieve? It explains how to run the del & ren btdll utilities to get rid of your 6.15 components. If you don't have it, I'll try to see if I can find something to summarize or ftp to you if you have a site I can transfer to. Check your macola root directory to be sure you have a current regist70.dat (this is what tells the macola32.exe or pwe.exe how many macola users you are licensed for. It sounds like you may not have paid your annual maintenance at Macola? Can you log into the customer portal at Exact and download infomines, etc., if needed?

The pervasive user count can be seen in the pervasive user count administrator in the pervasive group on the server or from a workstation with the client installed. You should have been prompted to install that license when you installed pervasive on your server.

Still unanswered: how did you install pervasive and macola on TS? As administrator using add/remove programs? Oce you get the btrieve 6.15 off the server and workstations, you should probably rerun the macola client install after manually removing the current install of the macola client.