converting old .dbt files?

[CALocklin]

This is a longshot but maybe I'll get lucky....

I have a situation where I need to convert some files from another database on a regular basis. Unfortunately, these files seem to be using a .dbt memo file that can be read by A4 but not by A5. Not even by A5v1.

I could buy a 3rd party program to convert the files on my own system but....

Since the app will be sold (hopefully) to many companies, each company would need to be able to convert the data as easily as possible. Asking them to open a different program, convert the files, then go back to my program really isn't very appealing, probably would cause all kinds 'service' calls, and is not a very good selling point either.

Anybody know of a better, more 'behind the scenes' way to convert/fix a memo file?

I looked at an 'original' and 'converted' file and tried to see if I could just poke some values into the header. It looked like it might work but it didn't - at least, not the way I did it. The 'poked' values went in fine. They just didn't solve the problem.

[Tom Cone Jr]

Cal, have you actually tried to open the table (before the fpt file exists)? I thought Alpha Five would convert the Alpha Four table automatically, creating the necessary fpt file for you. -- tom

[davej]

Converting A4V6 .dbt Files

Cal,

I just did what Tom suggested and it worked 100%.

I opened A5V6, clicked File, Open and navigated to an existing A4V6 application that has a .dbf file, opened it and then used the default form (in A5V6) to view the data. The memo field opened with no problems whatsoever.

Dave

[CALocklin]

The problem is that A5 can't open the table. It says the memo file can't be found. Since it can't open the table, it can't convert the memo file either.

It opens in A4v7 just fine.

[martinwcole]

cal, have you tried a script to test if you can say something like

file_add_to_db()

and see if it will convert the appropriate tables automatically

[Finian Lennon]

Cal:

I seem to remember that conversion of the dbt file in A5V1 was something you chose to via a menu option, it didn't happen automatically.

Finian

[Tom Cone Jr]

Cal, perhaps it's worth trying in A5v4, or A5v5? I'd be happy to try it here, also, if you can post a sample table, including the dbt file.

The sequence I'm recalling would look like this:

a) copy the DBF and DBT to a new folder
b) use A5v? to create a new database there
c) use the control panel to 'add' the table to the database

-- tom

[Barry]

Same problem

Cal,

I recently had the same problem, I used a DBF fix program found at
http://www.dbf-repair.com. The prog has various options and I know that the
fixed DBF can be opened directly in Alpha once it is fixed.
Perhaps you could do somethong with this.

Barry

[Steve Workings]

It's been a while since I've done this Cal, but I think an append operation will convert the data for you. Create the structure you need in A5 then just append the A4 data into it.

[Bill Parker]

I never thought this was a problem, but with most folks thinking it is, I went back to test.

Took table with dbt memo from 2 different old A4 systems and put in a new directory.
Created a new database in v6 and added the tables.
Opened default browse successfully. Opened default form and added text to the memo field, and saved. The updated memo stays in dbt format as I remembered. Alpha Five will maintain a DBT file, it just won't create one.

To change to FPT format, I added a Dummy, C1 field to the structure. This does the same thing as Steve's append. Or you could also do a Duplicate operation.

In short, I have found the A4 DBT files to be no problem in A5.

Bill.

[CALocklin]

OK, here are two files to work with (a .dbf and the matching .dbt) if you'd like to see what you can do.

I appreciate the attempts to help but youse guys ain't reading very carefully. The most critical comment as stated in my second post above:

The problem is that A5 can't open the table. It says the memo file can't be found. Since it can't open the table, it can't convert the memo file either.

Also, since it can't open the table, it can't be restructured or appended to anything.

If there is a solution, it will probably have to be from outside A5 or some type of byte manipulation within a5.

I have tried a 3rd party program and that works fine. However, again as previously stated (in less detail), I don't feel it's reasonable to ask users of my app to open a 3rd party app maybe 10-20 times a day to convert files before importing them to my app. These files that are being imported are the result of an export from another program and, unfortunately, this is the only available export format and the existing data seems to be in a proprietary format.

I have tried overwriting the existing memo file with a converted memo file and that allows me to read the rest of the data (always just one record like the attached samples) but that doesn't help with the data in the memo fields. It does prove that the issue is in the .dbt file - for whatever that's worth.

By the way, I happen to know that the memo fields in the sample are actually empty but the data in this specific sample file is not the issue. Converting other files from within my app is the problem.

And, for what it's worth. I agree that any file created in A4 with a memo field(s) can be easily converted to a v5/.fpt format. The problem is that these files don't come from A4 even though they can be read by v4 - but not v5.

[Al Buchholz]

Where is this file from?

Cal

I looked at your file with Dsalvage. It stated that the memo file header is corrupt. The file should follow the dbase standard for headers and pointers (even though Alpha/codebase doesn't).

I've attached some of the messages that I've gotten as I've tried different Dsalvage operations on the file.

Do you have an example of this where it works with Alpha? We might find the problem in the header by comparing the two files......

Or by looking a little farther, I edited the record in hex mode and found that all of the values after the rf_* series of fields have a 20 as it's value... ie blank. That's an illegal memo pointer (and a non pointer besides..) Note the bottom image in the series of images attached.

Something goofy is going on here....

[Bill Parker]

A4 creates a memo file padded with 00 (hex) to 512 bytes if all memos are empty. Cals dbt file is 24 bytes, with no padding.

You probably know that if the memo is edited in A4 the memo can then be read by A5 since A4 then adds the padding.

You also indicated that real world memos would have data. Can a dbt > 512 bytes be read by A5? I have not tried adding the padding to a shorter dbt to see if that makes it readable.

Bill.

[Tom Cone Jr]

Wonder if it would make sense to use a hex editor on the DBT to add the 00 hex padding manually, and then determine if A5 can read/recognize the memo field text. If the source data is going to arrive one record at a time, A5 could be scripted to open the DBTfile in binary mode, add necessary padding, and then write it back to disk. All before opening the table.

---------------------

Follow up...

This looks promising.

I took Cal's DBT file, opened it with a hex editor. Inserted 00 (hex) 488 times, then saved it to disk. I then cranked up A5v6 and it opened the table just fine. I entered some text in the empty memo field.

-- tom

[CALocklin]

Thanks guys. We are getting closer.

I don't know why I didn't try it before but editing a memo field in v4 does make the file usable in v5. This still isn't a solution but at least it's some positive info.

When I looked at this file, it appears that the only difference is the additional "00" bytes mentioned by Bill. And, I see that Tom has chimed in now and I tried the same thing with the same results.

The next thing I'll try to do is get a memo file with some data in it. From what I hear, it's not common to have memos but does happen and I need to be able to handle it. Hopefully I can get someone to either find one or create one for me. Maybe with this info the solution will be obvious once I see a "used" memo file.

I'll let you know what I find out.

(And I hope nobody was offended by my previous comment. It wasn't meant to be offensive - just a wake up call.)