Programmatic DBT to FPT conversion

[IlyaRabyy]

Colleagues,

Is there a way to convert programmatically, on run time, table files in dBase 2K with memo part (.DBT) into VFP format (DBF/CDX/FPT) from VFP without modifying that bloody DBT along the way?

I tried the following (in a FOR...NEXT cycle, but that's not the point):

USE IN (SELECT("TEMP_DBF")) && Just in case
** Switch dBASE compatibility on:
SET COMPATIBLE DB4

TRY
USE (lcSrcDBF) ALIAS TEMP_DBF NOUPDATE SHARED
COPY TO (lcDstDBF) WITH CDX
SELECT 0
USE (lcDstDBF) ALIAS DB_2_VFP EXCLUSIVE
REINDEX
USE IN DB_2_VFP
CATCH TO loErr
** etc.
SET COMPATIBLE OFF

Every time there's .DBT part in the dB2K table - I get the following error message:

Error #1659, The table has memo fields that cannot be converted while open read-only.
in the Such'n'Such method on line #Such-n-Such
Command/line:
USE (lcSrcDBF) ALIAS TEMP_DBF NOUPDATE SHARED

Apparently, SET COMPATIBLE DB4 does not affect VFP's handling of the .DBT files, and I have already the explanation gotten in my other thread related to the dB-to-VFP topic. So, this time around, I need not an explanation but a solution.

One of those I have already tested was

COPY FILE (FORCEEXT(lcSrcDBF, "*")) TO (FORCEEXT(lcDstDBF, "*"))
SET SAFETY OFF
USE (lcDstDBF) ALIAS TEMP_DBF EXCLUSIVE
SET SAFETY ON

and it wasn't exactly satisfactory: it asked whether to convert the memo to VFP and, if answered "Yes" asked whether to replace "soft" line endings with binary ones. Of course, I set CDPDIALOG OFF and these two questions disappeared, but I am still not sure if this is the best, if not the only, solution.

Any ideas are welcome!


Regards,

Ilya

 

[IlyaRabyy]

Dan (sigh! :-( ), I wish I could always work on the copy of the data! But - alas! - ain't gonna happen, ever! Sooner or later, you will be told to work on either data entry, or data update, or something like that. On one of my previous jobs, I was responsible for the app for customers' data representation (SELECT and display as PDF page on screen), but that data should had been first processed, merged to the existing tables, QC-ed, etc., so - you see what I'm gettin' at, colleague?
It looks like I'm stuck with this "last resort" type of solutuion.
Well, as long as it works... it works.
Thanks!


Regards,

Ilya

 

[Dan Freeman]

Oh, I see where the problem is, sure! And I think you're trying to solve the wrong problem!

If your client's data is from a dBase app and they need you to work with it "live" and in-place without damage, then you should be writing your code in dBase! ;-)

I always hate saying this to people, but it's really true. If you need to preserve the integrity of Clipper's NTX index files, you need to be coding in Clipper! If you need to preserve dBase DBT memo files, you need to be coding in dBase.

Anything short of that is inherently a compromise. You just need to figure out which compromise is the least objectionable.

 

[Mike Lewis]

I always hate saying this to people, but it's really true. If you need to preserve the integrity of Clipper's NTX index files, you need to be coding in Clipper! If you need to preserve dBase DBT memo files, you need to be coding in dBase.

Dan, that makes good sense.

Altenatively, you could Codebase. That won't be an option for Ilya because of the cost, but it might be a possibility for others.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business