Форум » [x]Harbour » Dbcommit() » Ответить
Dbcommit()
NickSam: Никогда не использовал в Харборе функцию Dbcommit(), так как где то читал плюс подтвердил сам это опытным путем, что в Харборе данные сами свопируются на диск и видны другим пользователям. Но недавно пришлось изучать чужой код где при групповой обработке данных Dbcommit() идет после каждого добавления/обновления записи, что страшно тормозит процесс. Есть ли в этом какой то сакральный смысл или это все таки аттавизм Клиппера?
Ответов - 7
gfilatov2002: NickSam пишет: Есть ли в этом какой то сакральный смысл Смысл состоит в принудительной записи буферов с данными на диск. Ниже см. тестовый пример: [pre2]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 [/pre2] Попробуй закомментировать строку с командой COMMIT и сравни результаты работы (как изменяется дата и время изменения базы).
NickSam: Григорий, да в Вашем примере все четко работает. Без COMMIT время файла не меняется и данные не пишутся в файл. Но если сделать вот такую конструкцию: if rlock() REPLACE FIELD -> test WITH "TEST" dbunlock() endif , то данные пишутся в файл (хотя время файла не меняется). Если сюда добавить Dbcommit(), то при групповой обработке данных скорость падает на порядок. Вот у меня и возник вопрос, нужен ли он если данные все равно пишутся на диск в файл.
PSP: NickSam пишет: Если сюда добавить Dbcommit(), то при групповой обработке данных скорость падает на порядок. Можно commit делать не в каждой итерации групповой обработки, а в конце. Всё ж споконЕй))
SergKis: NickSam пишет нужен ли он если данные все равно пишутся на диск в файл Все зависит от работы вашего приложения и от исп. данных. Если это одно раб. место и оно пишет читает, считает ... в единственном экземпляре, то dbCommit важен только для целостности базы, т.е. при обрыве электричества, нажатия выкл. в момент работы пользователем. Если у вас сетевая работа и исп. деньги и др. единицы материального учета в online режиме и в разных таблицах, документы, итоги, проводки ..., то без dbCommit или перемещения по базе (skip, goto ... тоже скидывают данные из буфера) будет рассогласование данных в получаемых отчетах на разных раб. местах.
NickSam: SergKis пишет: будет рассогласование данных в получаемых отчетах на разных раб. местах Поставил эксперимент. Обновляю запись, делаю dbunlock() без Dbcommit(), перемещений по базе нет. Обновленная запись видна другому пользователю.
Pasha: Вопрос с dbCommit я решал лет тридцать назад, с тех пор ставлю на автомате после любого обновления, или в конце группового. Лучше пусть будет медленнее, но надежнее А уже более 10 лет пользуюсь исключительно letodb за редким исключением, а там dbCommit - это передача данных с клиента на сервер, что почти одно и то же.
SergKis: NickSam Не спорю, но RDD имеет свой буфер, windows свой, на нескольких PC все повторяется, у PC сервера свое. Когда буфер из RDD ляжет на диск без dbCommit, я не скажу. А вам принимать решение, надо экономить время или нет с dbCommit Обновляю запись, делаю dbunlock() без Dbcommit(), перемещений по базе нет dbUnlock содержит скрытый типа dbSkip(0), с перечитыванием записи
полная версия страницы