FiveTech Support Forums

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

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

Rick Lipkin

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

"

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.

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

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.

set( _SET_HARDCOMMIT, .F. )

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.

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

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

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