On Wed, 01 Apr 2009, Massimo Belgrano wrote: Hi,
> Will be intresting this discussion on fivetech forum? > http://forums.fivetechsupport.com/viewtopic.php?f=3&t=15076 No, > > Speedtest CLIPPER vs. xHarbour - COMMIT > Is CLIPPER still faster in database management? No, > I am testing the COMMIT statement. > With Clipper the operation takes 9 sec. with xHarbour 77 sec > function main() > local I:=0 > msginfo("Start " + str( seconds() )) > use clientes new > for I := 1 to 1000 > append blank > clientes->nombre := str(recno()) > commit > next > msginfo("End " + str( seconds()) ) > return nil In the past at least five times I was answering for similar questions. I hope this is the last time. What commit() does is quite well documented in Clipper. I suggest to read also COMIX documentation and check what cmxSys( 1002 ) does. I think it's a basic information which should be well known by anyone who is working with Clipper. 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. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
