AccPac 4.1A / Pervasive error 1

[JoeAtWork]

My client has an ancient system (runs on Windows 98) with AccPac 4.1A. When trying to open their company database in AccPac, I get the following error:

System error. Cannot access the application's table in the system or company database.

I was able to open one of the Sample company databases.

The database is Pervasive, in the About box in the GUI tool the version information is "SQL 2000 Workstation, 1999, version 2.0 build 147.4". Not sure if that refers to Pervasive itself or the GUI tool I was using (I'm a MS SQL Server guy, don't really know Pervasive).

I tried opening the ARCUS table and got the following error:

ODBC error: SQL State = S0002, Native-error code = -1305. No such object or table.

Finally, when I tried to do a database dump (through the AccPac Tools menu) I got error 45059.

What I am looking for is any advice on getting the system up and running. We are looking to upgrade the system ASAP, but we need to get the old one up and running in the meantime (one reason being so we can transfer the data when we upgrade).

 

[ettienne]

Check the setup in Accpac Database Setup. 4.1 did not use ODBC data connections, so check the data path and make sure that it is valid.

 

[JoeAtWork]

Thanks Ettienne.

Somebody sent me an article that said the problem might be a corrupt system database, and the article explained how to create a new one.

I've successfully run through the procedure on my development computer by replacing the system database for SAMINC, so I am going to try this tomorrow.

 

[Jay Converse]

If you're running a single currency database, then blowing out the system database has zero impact. If you're multi-currency, then you might be a few currency codes short, but you can add them later.

 

[JoeAtWork]

blowing out the system database has zero impact

But if the system database file is corrupt, wouldn't replacing it be the solution?

I've fixed other programs on this particular computer by replacing corrupted files from backups. I'm pretty sure there is something wrong with the hard drive - hopefully we will replace this system soon and be able to throw it in the trash.

 

[JoeAtWork]

I thought I should finish off this thread.

It turns out a lot of the data files were destroyed during the crash. We were able to restore some of them, but not enough. Unfortunately their tape drive hasn't been running properly for over a year so there is no backup (very small company, no IT staff to verify these things).

We installed version 5.5 on a new computer, they are slowing rebuilding their AP and AR.

 

[grnelson]

Just a note that I do file repairs on Pervasive Btrieve files. If the errors are in the page allocation tables usually you can restore the file 100 percent. But at times the corruption may be in the actual data. But usually you can still restore some data and in some cases you can combine the restored file with the last backup even if it has been awhile and you can get most of your data back.

But there are cases where if you have a header file and line item file and you lose data that causes to many orphaned records then you do just have to go back to your last backup.

Gil


Gil

 

[ettienne]

With accounting data it is critical to know that all records have been restored. Let's say your bank's server crashes and they let you know that they have recovered most of your money, but not all it it? Would you be happy?
Same with accounting data, if you are not 100% certain that all records have been recovered then how much can you trust the data? Sure there are ways to validate and check data integrity and so on, but the doubt always lingers on.
The point is that complete backups - that can be restored - are a critical part of running a business.