FiveTech Support Forums

nageswaragunupudi wrote: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.

Otto wrote:I think CLOSE is enough.

Otto wrote: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.

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

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

#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

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

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

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