DBF . Commit

[Enrico Maria Giordano]

So, let is be clear on this:
1. COMMIT is safe and ensures all data is physically written the disk. But not necessary to make the changes visible to other users.
2. UNLOCK is all that is enough to make the changes visible to users across the network.

Hope Mr. Enrico agrees on this.

Yes, I agree.

[Otto]

Dear Enrico, dear Mr. RAo,

What about CLOSE.

Many users use

UNLOCK
COMMIT
CLOSE

in their code.

I think CLOSE is enough.

But we also need built-in functions that can detect the actual data status. And this status is the cache status. Like the EXPLORER

Perhaps it's possible to obtain these for Fivewin.


OT:
It's such a pity that only a few still use DBF here. Especially with mod harbour, DBF files are optimal.
It's like on a single-user system and without the overhead of an SQL server.
Especially for beginners who come from HTML but also need some database functionality - just like the Jet(access) engine users back in the day on the WEB - would be a big target audience for us.
But unfortunately, the view here is MVC and SQL.

One more question:
ChatGPT gave me an answer, suggesting I should use FFI.
Does HARBOUR really have this and are there examples?
To implement a similar function in Harbour, you might want to use Harbour's FFI (Foreign Function Interface) to call the necessary Windows API functions.

Best regards,
Otto

[Enrico Maria Giordano]

I think CLOSE is enough.

Yes, you don't need to COMMIT after CLOSE.

It's such a pity that only a few still use DBF here. Especially with mod harbour, DBF files are optimal.
It's like on a single-user system and without the overhead of an SQL server.
Especially for beginners who come from HTML but also need some database functionality - just like the Jet(access) engine users back in the day on the WEB - would be a big target audience for us.
But unfortunately, the view here is MVC and SQL.

I agree.

[Carles]

Hi,

Taking advantage of the fact that we are talking about this topic, I put here this always interesting note from Przemek

Hi,

Just to clarify some myths about Clipper and Harbour behavior
presented on different Clipper related forums.

In Harbour and Clipper:

1. When record or table is unlocked then just before this
operations RDD writes all local modifications in table and
index files.
2. DBSKIP(0) just like DBGOTO( RECNO() ) writes all local
modifications (if any) and then discards local record
buffer so record has to be read again when any field is
accessed.
3. DBCOMMIT() writes all local modifications in table and
index files then it sends to system or file server request
to flush (write) its disk buffers to physical device (HARD
COMMIT). It's out of application control what OS (or FS)
do with such request.

The locking and buffer flushing in Clipper and Harbour RDDs
is safe and user cannot desynchronize data using different
instruction order, i.e. DBSKIP(0)/UNLOCK/COMMIT,...
The only problems which can appear are in OS or FS, i.e. the
infamous opportunistic locks is MSDN networks which may completely
break applications using concurrently the same files and synced
by file range and file access locks. This is the most common
reason of problems in concurrent file access in current days.

If OS (or FS) does not ignore COMMIT request then using it
reduces the time when new data exists only in file server
buffers and can be lost by server power off event so in some
cases it's good to use it. Anyhow it strongly reduce performance
so the whole operation is much longer and the chance for sudden
write process interrupt bigger. Usually the best effects can be
reached when user group some write operation and then commit them
to force buffer updates.
In harbour COMMIT can be temporally disabled by
SET( _SET_HARDCOMMIT, .F. )
and then enabled by
SET( _SET_HARDCOMMIT, .T. )
Harbour remembers which RDD files where modified with
SET( _SET_HARDCOMMIT, .F. ) so when user reenable hard commits
and call dbCommitAll() commit requesta are sent for all modified
RDD files.

best regards,
Przemek

C.

[nageswaragunupudi]

Dear Mr. Otto

Can you show me how to add GetFileAttributesEx from WINDOWS API.

Code: Select all  Expand view  RUN

#include "fivewin.ch"

//----------------------------------------------------------------------------//

function Main()

   local cFile := "tutor01.prg"
   local hInfo

   SET DATE GERMAN
   SET CENTURY ON
   SET TIME FORMAT TO "HH:MM:SS"

   hInfo    := GetFileAttributesEx( cFile )

   ? "FileSize", hInfo[ "FileSize" ]
   XBROWSER hInfo AUTOFIT


return nil

//----------------------------------------------------------------------------//

function GetFileAttributesEx( cFile )

   local aRet
   local hRet  := {=>}

   if File( cFile )
      aRet  := FILEATTRIBEX( TrueName( cFile ) )
      hRet[ "FileSize" ]      := aRet[ 1 ]
      hRet[ "Updated" ]       := aRet[ 2 ]
      hRet[ "Created" ]       := aRet[ 3 ]
      hRet[ "LastAccessed" ]  := aRet[ 4 ]
#ifdef __XHARBOUR__
      HSetCaseMatch( hRet, .f. )
#else
      HB_HSetCaseMatch( hRet, .f. )
#endif
   endif

return hRet


#pragma BEGINDUMP

#include <hbapi.h>
#include <windows.h>
#include <hbdate.h>
#include <fwh.h>

static double hbdatetime( FILETIME fTime )
{
   FILETIME localFileTime;
   SYSTEMTIME systemTime;
#ifdef __XHARBOUR__
   long lDate, lTime;
   int iOk;
#endif
   double hbdt = 0.0;

   if ( FileTimeToLocalFileTime( &fTime, &localFileTime ) &&
        FileTimeToSystemTime( &localFileTime, &systemTime ) )
   {
#ifdef __XHARBOUR__
   hb_datetimeEncode( &lDate, &lTime, systemTime.wYear, systemTime.wMonth,
             systemTime.wDay, systemTime.wHour, systemTime.wMinute,
             ( double ) systemTime.wSecond, 0, &iOk );
   hbdt  = hb_datetimePack( lDate, lTime );
#else
      hbdt = hb_timeStampPackD( systemTime.wYear, systemTime.wMonth,
             systemTime.wDay, systemTime.wHour, systemTime.wMinute,
             systemTime.wSecond );
#endif
   }
   return ( hbdt );
}


HB_FUNC_STATIC( FILEATTRIBEX )
{

   WIN32_FILE_ATTRIBUTE_DATA fileAttributeData;

   if ( GetFileAttributesEx( hb_parc( 1 ), GetFileExInfoStandard, &fileAttributeData ) )
   {
      FILETIME localFileTime;
      SYSTEMTIME systemTime;
      LARGE_INTEGER fileSize;
      double tDate;

      fileSize.LowPart    = fileAttributeData.nFileSizeLow;
      fileSize.HighPart   = fileAttributeData.nFileSizeHigh;

       hb_reta( 4 );
#ifdef __XHARBOUR__
       hb_stornll( ( LONGLONG ) fileSize.QuadPart, -1, 1 );
       hb_stordtd( hbdatetime( fileAttributeData.ftLastWriteTime ) ,  -1, 2 );
       hb_stordtd( hbdatetime( fileAttributeData.ftCreationTime ) ,   -1, 3 );
       hb_stordtd( hbdatetime( fileAttributeData.ftLastAccessTime ) , -1, 4 );
#else
       hb_storvnll( fileSize.QuadPart, -1, 1 );
       hb_storvtd( hbdatetime( fileAttributeData.ftLastWriteTime ) ,  -1, 2 );
       hb_storvtd( hbdatetime( fileAttributeData.ftCreationTime ) ,   -1, 3 );
       hb_storvtd( hbdatetime( fileAttributeData.ftLastAccessTime ) , -1, 4 );
#endif
   } else { hb_ret(); }
}

#pragma ENDDUMP

[nageswaragunupudi]

Actually, we can get all this information with greater ease, using FileSystemObject.

Code: Select all  Expand view  RUN

function FileInfo( cFile )

   SET DATE GERMAN
   SET CENTURY ON
   SET TIME FORMAT TO "HH:MM:SS"

   DEFAULT cFile := "customer.dbf"

   if File( cFile )
      WITH OBJECT( CreateObject( "Scripting.FileSystemObject" ):GetFile( TrueName( cFile ) ) )
         XBROWSER { { "Size", :Size }, { "LastModified", :DateLastModified }, ;
            { "DateCreated", :DateCreated }, { "LastAccessed", :DateLastAccessed } } ;
            TITLE cFile ;
            AUTOFIT
      END
   else
      ? cFile + " does not exist"
   endif

return nil

[Otto]

Actually, we can obtain all this information with greater ease using the FileSystemObject.

Dear Mr. Rao,

Thank you so much. This is a very useful function and it's working well. This function detects data changes even if there was no commit.

Best regards,
Otto

[Rick Lipkin]

For Me ... all my data is written to memory variables when the data needs to be saved I can append the data or edit the data and the last thing I do with dbfcdx is to move the record pointer after I write to the disk with GoTo Recno()

ADO is a bit different with SQL .. Recordsets can be added to or edited one record at a time and when a committ is made all I do is issue oRs:Update(), and perhaps a SysReFresh() and I have never had any visability problems even in large networks .. The only reason I use dbfcdx is to write temporary data to use in a report writing the report database to the local workstation hard drive, and deleting the .dbf when I am done.

The only visability problem I can forsee is if a User has a dbf or oRs recordset up on their screen and that person goes to lunch .. I see no way a second workstation would be able to update stale data that is left un-attended on a workstation and have any visable changes when the user comes back ... again, I do not add or edit information to the live data .. data in is written to memory variables and data saved, is written from memory variables back to the datasource with an oRs:Update() or in dbfcdx goto recno().... I will say that I find dbCommitt() very slow when you are adding many records at one time with a dbCommitt between appends.

Rick Lipkin

[Enrico Maria Giordano]

This function detects data changes even if there was no commit.

This is not what I get. Please, show us an example that prints different date/time after REPLACE without COMMIT.

[Enrico Maria Giordano]

I will say that I find dbCommitt() very slow when you are adding many records at one time with a dbCommitt between appends.

Of course. One COMMIT at the end is enough.