Отправлено: 15.11.23 13:23. Заголовок: Dbcommit()

Никогда не использовал в Харборе функцию Dbcommit(), так как где то читал плюс подтвердил сам это опытным путем, что в Харборе данные сами свопируются на диск и видны другим пользователям.
Но недавно пришлось изучать чужой код где при групповой обработке данных Dbcommit() идет после каждого добавления/обновления записи, что страшно тормозит процесс.
Есть ли в этом какой то сакральный смысл или это все таки аттавизм Клиппера?

 Отправлено: 15.11.23 13:46. Заголовок: NickSam пишет: Есть..

NickSam пишет:

цитата:

Есть ли в этом какой то сакральный смысл

Смысл состоит в принудительной записи буферов с данными на диск.
Ниже см. тестовый пример:

REQUEST DBFCDX 
  
  
 FUNCTION MAIN() 
  
     LOCAL cDbf := "MYTEST.DBF" 
  
     RDDSETDEFAULT( "DBFCDX" ) 
  
     SET EXCLUSIVE OFF 
  
     //SET HARDCOMMIT OFF 
  
     DBCREATE( cDbf, { { "TEST", "C", 30, 0 } } ) 
  
     ? FILEDATE( cDbf ), FILETIME( cDbf ) 
  
     INKEY( 2 ) 
  
     USE ( cDbf ) 
  
     APPEND BLANK 
  
     REPLACE FIELD -> test WITH "TEST" 
  
     COMMIT 
  
     ? FILEDATE( cDbf ), FILETIME( cDbf ) 
  
     INKEY( 0 ) 
  
     RETURN NIL 
 

Попробуй закомментировать строку с командой COMMIT и сравни результаты работы (как изменяется дата и время изменения базы).

 Отправлено: 15.11.23 15:20. Заголовок: Григорий, да в Вашем..

Григорий, да в Вашем примере все четко работает. Без COMMIT время файла не меняется и данные не пишутся в файл.
Но если сделать вот такую конструкцию:
if rlock()
REPLACE FIELD -> test WITH "TEST"
dbunlock()
endif
, то данные пишутся в файл (хотя время файла не меняется).
Если сюда добавить Dbcommit(), то при групповой обработке данных скорость падает на порядок.
Вот у меня и возник вопрос, нужен ли он если данные все равно пишутся на диск в файл.

 Отправлено: 15.11.23 15:39. Заголовок: NickSam пишет: Если..

NickSam пишет:

цитата:

Если сюда добавить Dbcommit(), то при групповой обработке данных скорость падает на порядок.

Можно commit делать не в каждой итерации групповой обработки, а в конце. Всё ж споконЕй))

 Отправлено: 15.11.23 15:40. Заголовок: NickSam пишет нужен ..

NickSam пишет

цитата:

нужен ли он если данные все равно пишутся на диск в файл

Все зависит от работы вашего приложения и от исп. данных. Если это одно раб. место и оно пишет читает, считает ... в единственном экземпляре, то dbCommit важен только для целостности базы, т.е. при обрыве электричества, нажатия выкл. в момент работы пользователем. Если у вас сетевая работа и исп. деньги и др. единицы материального учета в online режиме и в разных таблицах, документы, итоги, проводки ..., то без dbCommit или перемещения по базе (skip, goto ... тоже скидывают данные из буфера) будет рассогласование данных в получаемых отчетах на разных раб. местах.

 Отправлено: 15.11.23 16:18. Заголовок: SergKis пишет: буде..

SergKis пишет:

цитата:

будет рассогласование данных в получаемых отчетах на разных раб. местах

Поставил эксперимент. Обновляю запись, делаю dbunlock() без Dbcommit(), перемещений по базе нет. Обновленная запись видна другому пользователю.

 Отправлено: 15.11.23 16:38. Заголовок: Вопрос с dbCommit я ..

Вопрос с dbCommit я решал лет тридцать назад, с тех пор ставлю на автомате после любого обновления, или в конце группового. Лучше пусть будет медленнее, но надежнее
А уже более 10 лет пользуюсь исключительно letodb за редким исключением, а там dbCommit - это передача данных с клиента на сервер, что почти одно и то же.

 Отправлено: 15.11.23 16:40. Заголовок: NickSam Не спорю, н..

NickSam
Не спорю, но RDD имеет свой буфер, windows свой, на нескольких PC все повторяется, у PC сервера свое.
Когда буфер из RDD ляжет на диск без dbCommit, я не скажу. А вам принимать решение, надо экономить время или нет с dbCommit

цитата:

Обновляю запись, делаю dbunlock() без Dbcommit(), перемещений по базе нет

dbUnlock содержит скрытый типа dbSkip(0), с перечитыванием записи