Speedtest CLIPPER vs. xHarbour - COMMIT

Re: Speedtest CLIPPER vs. xHarbour - COMMIT

Postby karinha » Fri Apr 30, 2021 11:52 am

Can someone explain this command to me? Thanks.

Code: Select all  Expand view

   set( _SET_HARDCOMMIT, .F. )
 


Regards.
João Santos - São Paulo - Brasil - Phone: +55(11)95150-7341
User avatar
karinha
 
Posts: 7772
Joined: Tue Dec 20, 2005 7:36 pm
Location: São Paulo - Brasil

Re: Speedtest CLIPPER vs. xHarbour - COMMIT

Postby Antonio Linares » Fri Apr 30, 2021 12:07 pm

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.
regards, saludos

Antonio Linares
www.fivetechsoft.com
User avatar
Antonio Linares
Site Admin
 
Posts: 42052
Joined: Thu Oct 06, 2005 5:47 pm
Location: Spain

Re: Speedtest CLIPPER vs. xHarbour - COMMIT

Postby karinha » Fri Apr 30, 2021 1:20 pm

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.
João Santos - São Paulo - Brasil - Phone: +55(11)95150-7341
User avatar
karinha
 
Posts: 7772
Joined: Tue Dec 20, 2005 7:36 pm
Location: São Paulo - Brasil

Re: Speedtest CLIPPER vs. xHarbour - COMMIT

Postby Rick Lipkin » Fri Apr 30, 2021 2:45 pm

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
User avatar
Rick Lipkin
 
Posts: 2662
Joined: Fri Oct 07, 2005 1:50 pm
Location: Columbia, South Carolina USA

Re: Speedtest CLIPPER vs. xHarbour - COMMIT

Postby karinha » Fri Apr 30, 2021 3:55 pm

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.
João Santos - São Paulo - Brasil - Phone: +55(11)95150-7341
User avatar
karinha
 
Posts: 7772
Joined: Tue Dec 20, 2005 7:36 pm
Location: São Paulo - Brasil

Re: Speedtest CLIPPER vs. xHarbour - COMMIT

Postby Enrico Maria Giordano » Fri Apr 30, 2021 4:42 pm

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


I agree.

EMG
User avatar
Enrico Maria Giordano
 
Posts: 8701
Joined: Thu Oct 06, 2005 8:17 pm
Location: Roma - Italia

Previous

Return to FiveWin for Harbour/xHarbour

Who is online

Users browsing this forum: Google [Bot] and 49 guests