Understanding RDDSETDEFAULT("DBFCDX") for Former VFP Users

[Jeff Stone]

As we progress with testing and adapting our code from VFP to Harbour, we noticed an issue with COPY TO.  We opened a VFP .DBF file and then copied it to a temporary file using the COPY TO  command.  The temporary .DBF was in Clipper/DBIII+ format; however, the FILETYPE indicator at Byte 0 is 0x30 rather than being 0x03. If we subsequently attempted to open Tempdeals.dbf with VFP, the last 8 fields in each record are no longer accessible.

We figured out that a RDDSETDEFAULT("DBFCDX") call caused this behavior.  We also figured out that if we issued the COPY TO command with VIA "DBFNTX", the temporary .DBF's FILETYPE indicator was correctly set to 0x03 rather than 0x30. 

We used the RDDSETDEFAULT("DBFCDX") command because a couple of our VFP DBF tables have .CDX files associated with them.  We incorrectly thought RDDSETDEFAULT("DBFCDX") would also make all newly created .DBF files VFP compliant.  Since that's not the case, perhaps it might be better to open the VFP files with USE VIA "DBFCDX" as a matter of practice. 

Does anyone have thoughts they would like to offer on this topic?

Regards,

Jeff

[Klas Engwall]

Hi Jeff,

I have never used VFP files, so this is not from my own experience. But
there is a hb_RddInfo(RDDI_TABLETYPE,nType) setting that you can try.
Available types are DB_DBF_STD and DB_DBF_VFP. Put #include "dbinfo.ch"
at the top of the prg file and the hb_RddInfo() call before creating the
file. It might be a good idea to save the value returned by the function
so you can set it back to what it originally was when you are done.

Regards,
Klas

[Przemyslaw Czerpak]

Hi,

Can you send here such VFP table with few records so I can
make the tests what is the real reason of the problem.

best regards,
Przemek

> --
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users
>
> ---
> You received this message because you are subscribed to the Google Groups "Harbour Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Jeff Stone]

Hi Przemek,

Attached is the DBF I'm copying.

Thanks,

Jeff

[Przemyslaw Czerpak]

Hi Jeff,

If you open this table and execute COPY TO command then by
default Harbour creates standard DBF file with 0x03 in 1-st byte.
It means that you changed standard Harbour behavior and added to
your code:
rddInfo( RDDI_TABLETYPE, DB_DBF_VFP, "DBFCDX" )
or:
rddSetDefalt( "DBFCDX" )
[...]
rddInfo( RDDI_TABLETYPE, DB_DBF_VFP )
what changed default table type for newly created tabled in DBFCDX
to VFP.
So just simply remove above RDDI_TABLETYPE setting from your code.

Current Harbour code does not reserve space for database container
in DBF headers marked with VFP signature (0x30 or 0x31) and this
is the source of your problem. Probably your version of VFP reduces
the header size by 263 (database container space) so it does not
process last 9 (or 8) fields when it opens DBF table created by
Harbour with VFP signature.

best regards,
Przemek

[Jeff Stone]

Hi Przemek,

You are correct that we did execute RDDSETDEFAULT("DBFCDX") in our code.  As we are attempting to do a slow transition from VFP to Hbr, we have many DBF files that have true VFP signatures.  Since we are working and testing the files as we work with Hbr, we wanted to keep the DBF signatures consistent. So, this raises the following questions:

  1. Are RDD types really used for file reading and writing but not file creating?

  2. If we "use" a VFP .DBF, and we don't care about any associated index file(s), do we need to declare/define its type or will Harbour recognize it automatically.

My coding skills are not as good as most here, but it seems as like hb_rddCreateTable() could be modified to add the database container, if the DBF signature specified by the RDD type were 0x30 or 0x31, without a significant amount of difficulty.  Adding this capability might encourage other VFP coders to transition to Harbour as the subsequent implementation of .DBC files would be started for those that might need it.

As always, thanks for taking the time to help me.

Regards,

Jeff

[Przemyslaw Czerpak]

On Mon, 23 Nov 2015, Jeff Stone wrote:

Hi,

> You are correct that we did execute RDDSETDEFAULT("DBFCDX") in our code.
> As we are attempting to do a slow transition from VFP to Hbr, we have many
> DBF files that have true VFP signatures. Since we are working and testing
> the files as we work with Hbr, we wanted to keep the DBF signatures
> consistent. So, this raises the following questions:
> 1. Are RDD types really used for file reading and writing but not file
> creating?

Harbour automatically recognizes type of DBF and MEMO files when table
is open. It uses signatures stored in DBF and MEMO headers for it.
RDDI_TABLETYPE and RDDI_MEMOTYPE is used only for newly create files.
rddSetDefault( "DBFCDX" )
does not change DBF signature. It only sets DBFCDX as default as default
RDD. The type of newly created DBF tables is set by:
rddInfo( RDDI_TABLETYPE, DB_DBF_VFP )

> 2. If we "use" a VFP .DBF, and we don't care about any associated index
> file(s), do we need to declare/define its type or will Harbour recognize it
> automatically.

Harbour can use any combinations of table, memo and index files.
The type of index file is controlled by used RDD: DBFCDX, DBFNTX and DBFNSX
so it's not recognized automatically but chose by programmer. DBF header
does not contain any information about used index format and index names.

> My coding skills are not as good as most here, but it seems as like
> hb_rddCreateTable() could be modified to add the database container, if the
> DBF signature specified by the RDD type were 0x30 or 0x31, without a
> significant amount of difficulty. Adding this capability might encourage
> other VFP coders to transition to Harbour as the subsequent implementation
> of .DBC files would be started for those that might need it.

I'll commit modification which reserves space for DBC name in DBF header
when new table is created with VFP signature is used. Anyhow full support
for .DBC files is a job for real VFP users. I've never used it so it's
hard to me to implement such extensions when I cannot precisely verify
real VFP behavior.

best regards,
Przemek

[Jeff Stone]

Przemek,

You are The Man!  While we haven't used .DBC files very often (because we like to control index files and table relationships ourselves), I think I may know of some VFPers who could help implement .DBC usage in Harbour.  I would wager at least half of .DBC use is just for controlling index files, handling table relationships, allowing long field names and creating field and record validation rules.  Other than the long field names, implementing these .DBC aspects are pretty straight forward.  I never tried storing local Procedures and Views in a .DBC but would wager they would be challenge.

Thanks again for all of your efforts and your willingness to accommodate non-Clipper functionality.

Regards,

Jeff