Fatal Error while packing data files

[Random Confusion]

Lately we have been unable to download orders from Miva to Stone Edge Order Manager because SEOM says that there are no new orders - when we are staring at the unbatched orders in MM4 itself.

It had been recommended that we pack our data files so I went off to do so, and the domain data files packed fine, but the store database files return the following error:

Fatal Error

Miva Merchant has encountered a fatal error and is unable to continue. The following information may assist you in determining the cause of the error:

Error Code: MER-INV-00006 Description: 'Merchant2/00000001/inv_cnt.dbf' contains an unsupported field (  ) of type ' '

We've been told that this happens when the file is FTPd using ASCII and not BIN, but to our knowledge we have not touched these database files for any transferring. So, we need to edit the database to correct this error.

I've downloaded dBase IV for Windows & dBase V for Windows (I've heard before that these would work for correcting the problem without corrupting the files for Miva 4.22) but what files should I go after first? I tried opening the inv_cnt.dbf file, but I get an error that it's not a valid table.

Any suggestions?

Todd

[PCINET - Andreas]

Just use MS Access and fix, upload and pack.

[Vic - WolfPaw Computers]

Personally I've never used either of those editors...but I know what works and many in the community use dbfutils from dbfutils.com

The error you are seeing is a typical error when a memo field has been damaged. You may not be able to fix this if the field definition has been damaged.

If the database is damaged beyond repair, you may want to have your host restore it from backup.

Since its the inventory counts, you could also delete the database and replace it with an empty copy and re-import your inventory levels.

[dotCOM_host]

Todd,

As I explained to you in our helpdesk, you will need a DBF file editor compatible with MIVA's format of databases. They are using dBase III format with custom indexes (proprietary), so dBase IV or V won't work...

Look at DBFView - my preferred choice. It will work with all MIVA MErchant databases. Once you fix the database file(s), you have to upload them back and pack your store to re-generate the indexes. Since they are using proprietary indexes, DBFView won't be able to create those for you.

[dotCOM_host]

Just use MS Access and fix, upload and pack.
I would be EXTREMELY careful if going that route. Access is not 100% compatible with some of the MIVA databases, or at least not without installing additional Borland drivers on your PC. This is similar to opening up databases in Excel to fix them - it MAY work on some databases, but in general that will truncate the fields from the original lengths to something like 11 characters (when the original field may have been 55), and will definitely not work on "memo" type fields which are 255 characters.

[Bruce - PhosphorMedia]

Random, Remik,
I don't think you can fix this error. We started seeing this error in Merchant 4.16. Something in the inventory management routines completely corrupts the inv_cnt.dbf file, changing not only the field name but the type as well. (The type is changed to a 19 character digit!!!). I don't think any DBF editor can Fix it. The only solution is to replace the file.

As for what causes it, don't know this at that point the db management code is compiled.

Random, what version of Merchant are you running?

[PCINET - Andreas]

Just for the records. We are using MS Access 2003 and changed all kinds of Miva related dbs which do have Memo fields with more the 255 chars and no problems at all.

Remik, please provide an example where the above mentioned problems occured so forum users can avoid it.

[Random Confusion]

I've tried opening up the file in Access, and it wouldn't open (otherwise I'd not have dug out my old copies of dBase from the back of the closet.) I've tried DBFView but it tells me "File open error. The database file doesn't appear to be a dBASE file."

At this point I think I need to replace the file (I'm writing this as more of you contribute so I'm adding on) like Bruce said. I'm not worried about re-indexing since most of our products we're not tracking inventory in Miva anyway (MM v4.22, engine 5.04 as I said earlier with OUI 4.95) and I can re-upload what I need once that is stable again.

I'll open a new ticket (I guess a "Hold" on an existing ticket means updates to it don't get read, right?) to have that restored from backup or whatnot.

Todd
Random Confusion

[dotCOM_host]

I don't have any thing off-the-top-of-my-head, but if you recall the old MRU lists, this topic has been brought up many times in the past and the general concensus was that Access and Excel should not be used for working with MIVA's DBF files, or at the very least, Access can be used if you have Borland database engine also installed/enabled on your PC (which I don't believe is installed by default). Check the archives, they are still available online.

[dotCOM_host]

I guess a "Hold" on an existing ticket means updates to it don't get read
No, "HOLD" simply means that the ticket is still open and unresolved. Once it gets resolved the status will change to "CLOSED."

[PCINET - Andreas]

Access definitly doesn't truncate memo fields. We are working with huge memo fields (dbt) and have no additional drivers installed.

BTW Excel is really a bad choice to fix corrupted dbs! Because it does truncate after 255 chars.

Let's drop this discussion unless you got a real example.

[ILoveHostasaurus]

I thought that error occurred after the inv_cnt.dbf had been edited by something not compatible with the Merchant database format. If that occurred, or the upload in ascii issue, it would need to be restored from backup. There's a bunch of programs that can incorrectly write out a dbf file to cause that problem, including Excel, etc.

[Random Confusion]

To my knowledge, nothing has/had touched that file since we swapped hosts. I do know that since the switch we had been able to download orders, and had packed the database last week, too, but late last week we started to have the problem.



I thought that error occurred after the inv_cnt.dbf had been edited by something not compatible with the Merchant database format. If that occurred, or the upload in ascii issue, it would need to be restored from backup. There's a bunch of programs that can incorrectly write out a dbf file to cause that problem, including Excel, etc.

[dotCOM_host]

Access definitly doesn't truncate memo fields. We are working with huge memo fields (dbt) and have no additional drivers installed.

BTW Excel is really a bad choice to fix corrupted dbs! Because it does truncate after 255 chars.
Yes, Excel is definitely a no-no for most intents and purposes, which is why I mentioned it. Access _can_ be used, pretty safely, assuming you have good understanding of how it works with dBase III files (I'm assuming you do). But in general, it can create problems just like Excel, and many people have been bitten in the you know what trying to work with DBF files in Access.

Not that this is a full documentation for this problem, but if you quickly check the archives for this problem, you will see this documented several times:

http://listmgr.miva.com/mru/index.mvc?control=display&msid=id76159989998

http://listmgr.miva.com/mru/index.mvc?control=display&msid=id7638197
(it seems like the newer versions of Access may work better with dBase files without the need for the Borland database engine?)

http://listmgr.miva.com/mru/index.mvc?control=display&msid=id8316898

http://listmgr.miva.com/mru/index.mvc?control=display&msid=id8386998

I haven't tried it in the most recent version of Access, personally. Can you let us know which version you are using, and whether the Borland Database Engine was installed/activated when you installed Access on your system?

[dotCOM_host]

Well, problem solved... Stephen (one of our staff members here at dotCOM) uploaded a clean copy of this database from one of our development sites and this resolved the problem. This file appeared to have been corrupted for quite a while (even backup from the previous host had this file already corrupted). Editing it didn't help. Replacing it with a clean copy from a different store did.

Just posting it for archives sake for anyone else running into this problem.

[kevin@stoneedge.com]

This is a known issue with the Inventory System from the Order Manager and has only appeared with merchants also using the Inventory Manager from Viking Coders (that I am aware of). I have not been able to determine the cause, however, I believe it is related to the index files associated with the dbf. After a recent bug issue was identified between the Export Module and the Inventory Manager, I made changes to the Order Manager's Export Module to open all associated index files with each of the tables that are accessed for inventory updates. This initially appears to have solved the problem with the .dbf corruption and the bug issue with the Inventory Manager. If any user of the Order Manager gets this error message, contact Stone Edge Technologies, Inc. for the latest release of the Order Manager Export Module (v2.302+) and a blank copy of the inv_cnt.dbf. FTP the blank copy of the .dbf to the site to replace the corrupted .dbf and install the new version of the module prior to uploading any inventory data to the Miva site. Should anyone continue to receive this error message after the updates, please contact me directly.