DBF . Commit

[Otto]

Dear Mr. Rao,
I believe we need your expertise and authority on a HARBOUR dbf matter.

Charly has posted a test. But I think this test is not meaningful because he commits after every data record update.

Is it really necessary to always commit? Don't the database commands fetch the values from the buffer?
Could you possibly clarify this situation?

Thank you in advance,
Otto

https://carles9000.github.io/?search=M%C3%A9tricas

Siempre que hagas cambios que pueden alterar la logica del programa, siempre habras de hacer un commit, independiente del rendimiento que tengas, que puede ser por varios temas. No hay mas. Si tu tienes en caja 100 y cojes 60, o actualizas al momento con commit o otro usuario puede cojer 100. Esto se entiende, no? Que tiene que ver el rendimiento? Que el uso de commit ralentiza ? Por supuesto

[Jimmy]

hi Otto,

the "Problem" most are not the DBF, the "Problem" is to "update Index"

Code: Select all  Expand view  RUN

SKIP(0)

this will have same Effect like COMMIT

[Rick Lipkin]

Goto Recno() works the same .. physically moves the record pointer back to itself thereby flushing and writing the buffers

Rick Lipkin

[Otto]

Hello all,
Is this statement really true?

Whenever you make changes that can impact the program's logic, you should always make a commit, regardless of performance, which can be influenced by various factors.
That's all there is to it. If you have 100 in the box and you take 60, you either update immediately with a commit or another user might take 100.
This makes sense, right? What does performance have to do with it? That using commit slows things down? Of course.

I mean, assuming the system doesn't crash. Do you really have to make a commit for another user to see a change?

Best regards,
Otto

[karinha]

Code: Select all  Expand view  RUN

// C:\FWH..\SAMPLES\COMMIT.PRG

FUNCTION Grabar()

   /*
   In this example, COMMIT forces a write to disk after a series
   of memory variables are assigned to field variables:
   */

   USE Sales EXCLUSIVE NEW

   MEMVAR->Name   := Sales->Name
   MEMVAR->Amount := Sales->Amount

   @ 10, 10 GET MEMVAR->Name
   @ 11, 10 GET MEMVAR->Amount

   READ

   IF Updated()

      APPEND BLANK

      RLOCK()

      REPLACE Sales->Name   WITH MEMVAR->Name
      REPLACE Sales->Amount WITH MEMVAR->Amount

      COMMIT
      UNLOCK

   ENDIF

RETURN NIL
 

Regars, saludos.

[Enrico Maria Giordano]

I mean, assuming the system doesn't crash. Do you really have to make a commit for another user to see a change?

No, as far as I know. It is the network system responsibility to handle those situations with the system buffers.

[vilian]

Enrico,

I think the same

[karinha]

"
COMMIT

Perform a solid-disk write for all active work areas

Syntax:

COMMIT

Description:

COMMIT is a database command that flushes Harbour buffers and performs a solid-disk write for all work areas with open database and index files. The solid-disk write capability is available under DOS version 3.3 and above. Under DOS 3.2 or less, COMMIT flushes Harbour buffers to DOS.

In a network environment, issuing a GO TO RECNO() or a SKIP0 will flush Clipper’s database and index buffers, but only a COMMIT will flush the buffers and perform a solid-disk write. Thus to insure updates are visible to other processes, you must issue a COMMIT after all database update commands (e.g., APPEND, REPLACE). To insure data integrity, COMMIT should be issued before an UNLOCK operation. Refer to the “Network Programming” chapter for more information on update visibility.
"

Regards, saludos.

[Carles]

Hi,

Thus to insure updates are visible to other processes, you must issue a COMMIT after all database update commands

Which is the problem ?

C.

[Otto]

I believe for the visibility of data for all network users in a Windows server system, cmxSys( 1002, .f. ) is sufficient.

In a centralized server scenario, a cache that sits between the hard drive and the application would indeed apply to all users accessing the server. When a user makes a change, this change should be reflected in the central cache and therefore be visible to all other users accessing the same file, provided the cache is properly managed and synchronized.

The function cmxSys( 1002, .f. ), when set to false, would likely affect the automatic commit or flush operations that write the cache to the hard disk. However, the changes, as long as they are in the cache, should be visible to all users accessing the server, since the cache is centralized and applies to all users.
-----------
set( _SET_HARDCOMMIT, .F. )
The deactivation of automatic commit operations could, however, increase the risk of data loss in the event of a system failure, as the data is stored in the cache and not on the hard disk.

[nageswaragunupudi]

set( _SET_HARDCOMMIT, .F. )

Yes.
The default is
SET HARDCOMMIT ON
After changing the value of a field, execution of UNLOCK is enough to make the change visible to all other users.

Documentation:

Code: Select all  Expand view  RUN

SET HARDCOMMIT ON | off | (<lOnOff>)

Arguments
ON | off | (<lOnOff>)

The option toggles if data of a changed record is immediately commited to disk with the REPLACE command. The value ON or .T. (true), which is the default, commits changed data immediately. OFF or .F. (false) switch this mode off. Description
Some replaceable database drivers support a delayed committing of records when their data is changed with the REPLACE command. The SET HARDCOMMIT setting influences this behavior. The default is ON.

Setting HARDCOMMIT to OFF can optimize record updates in databases but requires an explicit COMMIT command to indicate that data must be written to the database.
 

Simple DBUNLOCK()/DBRUNLOCK() is enough.

[Carles]

Hi,

After changing the value of a field, execution of UNLOCK is enough to make the change visible to all other users.

If _SET_HARDCOMMIT == .T. it's ok. If _SET_HARDCOMMIT == .F. then you need commit.

[Enrico Maria Giordano]

The option toggles if data of a changed record is immediately commited to disk with the REPLACE command.

This is not true, at least with xHarbour and DBFCDX. The file on disk is not updated till COMMIT.

[nageswaragunupudi]

Mr. Enrico

We all accept that you are an authority on Harbour and more on xHarbour.

But the documentation I reproduced here is xHarbour documentation as it is. (This documentation was released by xhb.com)



Do you mean this documentation is wrong?

[Otto]

I think it's important to distinguish between the record buffer and the hard drive cache.