database oDbf

[Loren]

Compañeros, buenas tardes:

Tengo una DBF con muchos campos. Necesito copiar un registro y pegarlo en otra DBF idéntica (hacer un duplicado de ese registro). Para evitar tantos "replace..." por cada campo, quiero utilizar la clase tdatabase

Code: Select all  Expand view

select 1
database oDbf
oDbf:load()    && copia
select  2
append blank
oDbf:save() && pega
 

Sin embargo, solo me crea el registro en blanco y nada más.
¿ Qué hago mal?

Gracias. Saludos.
LORENZO:

[nageswaragunupudi]

Code: Select all  Expand view

SELECT 1
DATABASE oDbf1
aCopy := oDbf1:Copy()

SELECT 2
DATABASE oDbf2
oDbf2:Append( aCopy )
 

[nageswaragunupudi]

Another method, without the overhead of creating 2 TDatabase objects.

Code: Select all  Expand view

SELECT 1
aData := FW_DBFToArray( nil, nil, nil, 1 )

SELECT 2
FW_ArrayToDbf( aData )
 

[nageswaragunupudi]

Simplest way

Code: Select all  Expand view

SELECT 1
hRec := FW_RecToHash()

SELECT 2
APPEND BLANK
FW_HashToRec( hRec )
DBUNLOCK()
 

[Marc Venken]

Witch off these techniques are the best when the source dbf will always have less fields than the target, but the fields always match in name and structure.

There must and will be one index field for matching and updating.

There will also be some replacement done (ex. a standard value that is needed) just before the update in the source dbf field.

[Marc Venken]

The Gatter() and scatter() functions are anno 2021 not preferred anymore right ?

[nageswaragunupudi]

Witch off these techniques are the best when the source dbf will always have less fields than the target, but the fields always match in name and structure.

We recommend FW_RecToHash() and FW_HashToRec().
This writes only common fields. The order of the fields is not important. It is the responsibility of the programmer to ensure compatibility of field types and sizes to avoid errors while writing.

There must and will be one index field for matching and updating.

The programmer has to locate the record containing the matching index and then lock the record before calling FW_HashToRec() for updating.

There will also be some replacement done (ex. a standard value that is needed) just before the update in the source dbf field.

After reading the data from the source dbf into the hash, the programmer can modify and field value in the hash before updating the destination dbf.

[nageswaragunupudi]

The Gatter() and scatter() functions are anno 2021 not preferred anymore right ?

The functions FW_DbfToArray() and FW_ArrayToDBF() work as Gather() and Scatter().
Hash functions are more flexible.

Gather() and Scatter() were originally used to editing records. TDataRow is better than these functions.

[Marc Venken]

After reading the data from the source dbf into the hash, the programmer can modify and field value in the hash before updating the destination dbf.

I looked at Hashes, and the look like arrays

Code: Select all  Expand view

   local aData:= {;
      { 'codigo' => 'uno',    'nombre' => 'Juan' },;
      { 'codigo' => 'dos',    'nombre' => 'Maria' },;
      { 'codigo' => 'tres',   'nombre' => 'Jose' },;
      { 'codigo' => 'cuatro', 'nombre' => 'Sonia' },;
      { 'nombre' => 'Pedro',  'codigo' => 'cinco' },;
      { 'edad'   => 18,       'codigo' => 'seis' };
   }

   XBROWSER aData FASTEDIT TITLE "ARRAY OF HASHES"
 

How do you edit 1 hash then ? I have them in a loop and let say I want to set the date as a value insite 1 element

The dbf field = datum (D)

hRec := data->( FW_RectoHash() )

For DBF we know..
data->datum = date()

So how to edit the hash element from that record and the field datum ?

[nageswaragunupudi]

Code: Select all  Expand view

hRec := data->( FW_RectoHash() )
? hRec[ "datum" ]
hRec[ "datum" ] := date() + 20
(otheralias)->( FW_HashToRec( hRec ) )