Как же меня достал этот глюк в LogOut...

[Губин Игорь]

При работе с LogOut наблюдается плавающе-постоянный глюк:

Внутри LogOut - Commit ключи в создаваемом файле создаются некорректно. Т.е. запись может быть добавлена (Add), а вот в ключах она не отразилась (Get даёт ошибку)...

В очередной раз наткнулся в старых кодах... Причём это может не проявляться годами, а в какой-то момент на каких-то определённых записях всё ломается.

[finsoftrz]

Ни разу не сталкивался на С6.

[Губин Игорь]

Ни разу не сталкивался на С6.

с10, с11

[Игорь Столяров]

а вот в ключах она не отразилась (Get даёт ошибку)

Вопрос в том, насколько вообще правомерна такая операция ...
Предположим, я внутри внутри LogOut - Commit добавляю запись с ID = 123
В это время с другой рабочей станции кто-то делает GET(ID = 123) записи.
Скорее всего получится фигвам ... хотя может зависеть от конкретного драйвера БД.

[Губин Игорь]

Вопрос в том, насколько вообще правомерна такая операция ...
Предположим, я внутри внутри LogOut - Commit добавляю запись с ID = 123
В это время с другой рабочей станции кто-то делает GET(ID = 123) записи.

Файл открывается 12h, т.е. никаких посторонних влияний. Работает с файлом единственный процесс

Драйвер TopSpeed

В мануале никаких запретов

[finsoftrz]

а вот в ключах она не отразилась (Get даёт ошибку)

Вопрос в том, насколько вообще правомерна такая операция ...
Предположим, я внутри внутри LogOut - Commit добавляю запись с ID = 123
В это время с другой рабочей станции кто-то делает GET(ID = 123) записи.
Скорее всего получится фигвам ... хотя может зависеть от конкретного драйвера БД.

Logout буферизует запись в оперативной памяти. В приведенном случае до commit get увидит новую запись только там, где выполняется операция. У всех остальных новые записи не видны, разумеется. Я тоже часто использую logout для ускорения работы. Только режу большие транзакции на порции по 50-100 тыс записей. Все нормально работает. Когда-то давно сталкивался, что если не резать транзакции, то начинало происходить торможение, видимо, своп или что-то подобное. Потом были проблемы с высвобождением памяти. Кто-то рекомендовал запускать очень большие транзакции отдельным exe, чтобы по завершении память возвращалась операционной системе. Это очень давно было. Все сказанное для topspeed, разумеется. В ряде случаев (если, например, мы конвертируем таблицы, то есть полностью создаем новый файл) ускорение дает append вместо add, с последующим build. Для btrieve быстрее было сразу add.

[Игорь Столяров]

Все сказанное для topspeed, то есть ускорение дает append вместо add, с последующим build.

Полностью согласен. Самое интересное, что на больших списках такая схема даёт хороший выигрышь и для драйвера In-Memory.

[Губин Игорь]

Только режу большие транзакции на порции по 50-100 тыс записей. Все нормально работает. Когда-то давно сталкивался, что если не резать транзакции, то начинало происходить торможение, видимо, своп или что-то подобное

Тут о другом речь.

Файл не очень большой, но к нему шло постоянное обращение в процессе его же создания. Когда лимитировал жёсткий диск LogOut очень сильно ускорял процесс.

Дело в том, что ты добавил запись через Add с некоторым уникальным значением поля (единственное в ключе), потом проверил, есть ли запись с таким значением поля, а get сказал - нету, но если добавить ещё одну запись с таким значением, то вылетает по Duplicate.

Код: Выделить всё

AFile  File
AKey Key(AField),Primary
Recodd
AField Long
End
End

LogOut (.1,AFile)
AField = 1
Add(AFile)
.....
AField = 1
Get(AFile,AKey)
IF ErrorCode() Then
AFiled = 1
Add(AFile)
IF ErrorCode() <> 0 Then Stop('Что за фигня').
End

Commit

[finsoftrz]

Похоже на баг. Во времена с6 такой вопрос обсуждался, и было сказано, что станция, которая добавляет записи в logout, сама их видит. То есть она делает get по буферу. Я обычно такое не использую, но, если правильно помню, то проверял, работало.

[Губин Игорь]

проверял, работало

Как правило работает.