Page 2 of 2

Re: Speedtest CLIPPER vs. xHarbour - COMMIT

PostPosted: Fri Apr 30, 2021 11:52 am
by karinha
Can someone explain this command to me? Thanks.

Code: Select all  Expand view

   set( _SET_HARDCOMMIT, .F. )
 


Regards.

Re: Speedtest CLIPPER vs. xHarbour - COMMIT

PostPosted: Fri Apr 30, 2021 12:07 pm
by Antonio Linares
Joao,

https://harbour.harbour-project.narkive.com/9YO3sx4r/speedtest-clipper-vs-xharbour-commit

dbCommit() make two things:
1. write application memory buffers to file.
2. send to OS request to flush disk buffers releated to open file.

The 1-st action is executed also by any other rdd operation which
may cause record reloading or may need to synchronize modifications,
f.e. unlock. You can simulate it in many different ways, f.e. by skip(0).

The 2-nd action is unique to dbcommit and it's not necessary for any
synchronizations in simultaneous/concurrent/network access. The whole
job here is sending information to Operating System which is automatically
redirected if necessary by OS to File Server that we ask to flush OS or
FS disk I/O write buffers physically to disk. OS / FS can ignore our request,
can execute it immediately or can only mark that it should be done
in some nearest future. It's in practice out of programmer control and
does not have to be.
In [x]Harbour you can disable this part of dbCommit() by:
set( _SET_HARDCOMMIT, .F. )
In COMIX by:
cmxSys( 1002, .f. )
As I said it does not cause any interactions to concurrent access.
Try to add set( _SET_HARDCOMMIT, .F. ) to above code and check the results.
Then write a message to your OS / network client / file server authors
and ask why COMMIT request executed from DOS application makes sth different
then executed from real Windows application. Of course if you need such
information. Probably DOS emulation layer buffers few commit requests in
some short time period, f.e. 1 sec. and then send them as one. But I only
guess. Anyhow it's not Harbour problem. Harbour only sends commit request
for open file handle to the OS and this is single function call inside
each user dbCommit() if _SET_HARDCOMMIT is not disabled. All time overhead
if any is out of Harbour code.

Re: Speedtest CLIPPER vs. xHarbour - COMMIT

PostPosted: Fri Apr 30, 2021 1:20 pm
by karinha
Gracias Maestro. Viviendo y aprendiendo.

Code: Select all  Expand view

   HB_LANGSELECT( 'PT' )     // Default language is now Portuguese
   HB_SETCODEPAGE( "PT850" )

   RDDSETDEFAULT("DBFCDX")
   RDDREGISTER( "DBFCDX", 1 ) // RDT_FULL

   SET AUTOPEN OFF
   SET CENTURY ON
   SET DATE BRITISH
   SET TIME FORMAT TO "HH:MM:SS"
   SET EPOCH TO YEAR( DATE() ) - 30
   SET SOFTSEEK OFF
   SET WRAP ON
   SETCANCEL( .F. )
   SET CONFIRM OFF
   SET DELETED ON
   SET _3DLOOK ON
   SET UNIQUE OFF
   SET ESCAPE OFF
   SET EXACT ON  
   SET EXCLUSIVE OFF
   SET MULTIPLE OFF
   // SET( _SET_HARDCOMMIT, .F. )
   SET HARDCOMMIT OFF  // Asi, és mejor.
   SET OPTIMIZE ON
 


Regards, saludos.

Re: Speedtest CLIPPER vs. xHarbour - COMMIT

PostPosted: Fri Apr 30, 2021 2:45 pm
by Rick Lipkin
To All

I still contend that when when you finish adding or editing a record in a .dbf .. a simple Goto Recno() is just as good as dbCommit() .. because you are moving the record pointer which flushes the buffers ...

Rick Lipkin

Re: Speedtest CLIPPER vs. xHarbour - COMMIT

PostPosted: Fri Apr 30, 2021 3:55 pm
by karinha
Rick Lipkin wrote:To All

I still contend that when when you finish adding or editing a record in a .dbf .. a simple Goto Recno() is just as good as dbCommit() .. because you are moving the record pointer which flushes the buffers ...

Rick Lipkin


Sorry. I do not agree.

https://vivaclipper.wordpress.com/2014/01/17/dbcommit/

https://vivaclipper.wordpress.com/2014/03/15/hb_frecno/

https://vivaclipper.wordpress.com/?s=RECNO%28%29

dbCommit (), Forces Windows to record data in the field in case of a power failure, for example.

Regards, saludos.

Re: Speedtest CLIPPER vs. xHarbour - COMMIT

PostPosted: Fri Apr 30, 2021 4:42 pm
by Enrico Maria Giordano
karinha wrote:dbCommit (), Forces Windows to record data in the field in case of a power failure, for example.


I agree.

EMG