Dbase (AREV Specific)
At 06 FEB 2004 02:47:20PM Aiden Massey wrote:
Arev 2.11
Created dbase location using set volume. Copied Dbase file to location. Files show in LISTFILES but LIST ABARMAST generates error "ABARMAST.DBF file is not available"
At 06 FEB 2004 06:30PM C Mansutti wrote:
I'm racking my brains now, but I used to get this error. I think I resolved it by opening the db file first, which then generated the dictionary for the table. I was then able to apply TCL commands after that.
I'm sure there is a more "Proper" way to do it though
Claude
At 06 FEB 2004 07:32PM Aiden Massey wrote:
Tried definefile to existing dbase file get the following
The "DICT.ABARMAST" file in the "GLOBAL" account exists, but an error was encountered while trying to access it.
At 06 FEB 2004 07:59PM Aiden Massey wrote:
Ok, so now I tried a Dbase Import for TEST\ABARMAST.DBF. The Dbase III Import window recognizes the file but creates field names appended with ZPP+
When I try an import I get the message
The operating system file "TEST\ABARMAST.DBT file is not available"
So where the heck does the .DBT come from.
Opened the Dbase file with a file viewer no problem.
At 06 FEB 2004 08:14PM Aiden Massey wrote:
Tried environmental bond with Arev 3.12, now get message
The F:\TEST\ABARMAST.DBF" table or one of its essential components is not available.
At 07 FEB 2004 09:29AM C Mansutti wrote:
Are you sure it is dbase III and not Dbase III+ or dbase IV
You can always e-mail me the file and I'll try it here with my bit of code (which I just have found)
Regards
Claude
At 09 FEB 2004 12:42PM Warren wrote:
The .DBT file is for memo fields. The structure of these is surprisingly similar to Rev hashed files (fixed frame size, overflow frames that are linked to a record if the record excedes the frame size).
You probably have one or more fields defined as memo fields in your layout.
I went through the source code for DBase export from the 2.1x REVSOURCE file and found several errors in how it defines Memo fields in the DBase dictionary as well as in the actual creation of the memo files themselves (it creates an orphan frame for each record). I also created a modified version that creates Foxpro v2.5 files which have less limitations than Dbase files (more dictionary columns, larger memo fields). The 2.1x version has a nasty Y2K bug it it too. It always takes the last 2 digits of the year and appends it to 19 to create the internal DBase date format (YYYYMMDD).
The quick fix is define the Memo fields length as 10 bytes. The memo field Dbase dictionary entry is just a placeholder / pointer to the offset in the .DBT file and has to be defined as 10 bytes but the DBase export puts the size you enter in the definition.
Post an email address and I can send you the fixed version and Foxpro versions that I have.
At 09 FEB 2004 12:44PM Warren wrote:
This is probably caused by the incorrect memo field definitions in Dbase dictionary as noted in my earlier reply.
At 09 FEB 2004 10:23PM Warren wrote:
Note: The Y2K bug is fixed in the v3.12 DBase Export, I'm not sure about the 10 byte dictionary definition for Memo fields. The orphan frame bug was not fixed. This frame bug does not affect the usage of the file in any way except wasting 512 bytes for every record placed in the DBT file. This can be cleaned up in DBase by "packing" the file.