|
|
|
Насколько грамотна такая конструкция?
|
|||
|---|---|---|---|
|
#18+
есть что-либо криминальное в такой блокировке и транзакции? уж больно тормозит.... Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2007, 19:10 |
|
||
|
Насколько грамотна такая конструкция?
|
|||
|---|---|---|---|
|
#18+
В принципе, ничего особо криминального нет, кроме того, что нет и особого смысла в предварительных явных блокировках. А тормозит, скорее всего, команда REPLACE FOR ... Дело в том, что подобная команда накладывает блокировку на ВСЮ таблицу. Без исключения. Вне зависимости от того, попадают записи в FOR-условие или нет. А поскольку она у тебя внутри транзакции, то и висеть эта блокировка будет до окончании транзакции. Либо замени команду REPLACE FOR... на команду UPDATE-SQL, либо делай REPLACE в цикле, по одной записи за раз Код: plaintext 1. 2. 3. Одиночная команда REPLACE без указания SCOPE и (или) опций FOR, WHILE блокирует только одну текущую запись. Ту, которую и изменяет. Кроме того, если модификация затрагивает поля, участвующие в структурном индексе (поскольку есть INSERT, то затрагивает), то будет также блокирован и структурный индексный файл (CDX). Т.е. никакой другой пользователь не сможет изменить поля, влияющие на содержание индекса до завершения транзакции. А вообще-то, лично я сделал бы сначала все модификации в буфере таблиц, а затем уже через TableUpdate() осуществлял бы сброс. Можно и в транзакции, еси необходимо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2007, 00:38 |
|
||
|
Насколько грамотна такая конструкция?
|
|||
|---|---|---|---|
|
#18+
но REPLACE выполняется к третьей таблице, которую я явно не блокирую.... а вообще явную блокировку я поставил из-за того, что на днях вдруг у всех пользователей не стали записываться документы, выдавалось сообщение "Сохранение документа...." и тишина, всё висло.... а до этого явной блокировки не было и всё работало нормально.... я подумал, что может быть какая коллизия внутри транзакции (вобщем-то так и было, т.к. выполнялся ROLLBACK и пользователям выдавалось сообщение о неудачной попытке сохранения документы) и поставил явную блокировку RLOCK().... т.е. пользователи стали вставать в очередь и сохранять документы по очереди, но всё стало жутко тормозить.... но работать.. да, и REPLACE у меня всё-таки без FOR.... замена происходит по одной записи.... и если быть более точным, то второй инсёрт у меня выполняется в цикле примерно так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2007, 22:51 |
|
||
|
Насколько грамотна такая конструкция?
|
|||
|---|---|---|---|
|
#18+
Старайся избегать использования FOR для больших таблиц лучше сделать индекс использовать SEEK и WHILE. Вместо REPLACE FOR (кстати ALL тут лишнее) Код: plaintext 1. 2. ну и LOCATE меняй на SEEK а чтобы точно узнать где тормоз - в дебагере запускаешь Tools->Coverage logging..., указываешь файл с логом, затем выполняешь свой код, останавливаешь отладчик, а потом смотришь на итого в IDE через Tools->Coverage Profiler Там и увидишь сколько раз и сколько времени выполнялась каждая строчка в твоем коде ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2007, 11:55 |
|
||
|
Насколько грамотна такая конструкция?
|
|||
|---|---|---|---|
|
#18+
И на счет этого: Код: plaintext 1. Может возникнуть ситуация что код зациклится 2. Бессмысленно продолжать выполнение кода, если произошла ошибка 3. Ты никогда не узнаешь что в коде есть ошибка не связанная с блокировками 4. Надо не забыть вернуть на место прежний обработчик ошибок Лучше использовать TRY ... CATCH и обрабатывать только те ошибки, которые ожидаешь, а не все подряд. Всегда надо исходить из того что в коде остались ошибки, которые вскроются в будущем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2007, 12:10 |
|
||
|
Насколько грамотна такая конструкция?
|
|||
|---|---|---|---|
|
#18+
Ну на мой взгляд - ужасно... Нельзя в одном модуле смешивать все подряд... Ну как правило.. table1 table2 и пр.. этож ж ведь таблицы которые описывают что -то.. Значит так.. If OpenDbf("Суть таблицы 1") &&& ну например "товары" или "клинты" и т.п. А уже OpenDbf -свяжет суть с таблицей индексами - местами расположения и вообще возможностью открыть.. if OpenDbf("Суть таблицы 2") if OpenDbf("Суть таблицы 3") If Make("СУТЬ таблицы 1","состояние 2") &&& где состояние 2 - одно из реальных состояний в которых может находиться таблица 1.. Ну и все в таком виде... А уже там где -то в Make надо применять Insert SQL и подобные команды.. И никогда не делать Insert в "Сущность таблицы 1" иначе как через Make... ну надеюсь понятно... А то все в кучу... У программы... есть.. должны быть уровни... слои... Нельзя из одного слоя к другому обращаться... даже если хочется... Иначе надежность - пещерная... Грубо говоря .. у вас автомобиль.. руль.. педали... красиво... и провода вместо ключа .. красный и синий... а должен быть замок зажигания... сверху проводов.. Грубо говоря потом ... описав все сути и способы работы с ними.. просто склдадываете программу в кучу... из умных кусков... написание программ.. тестирование... изменение... ускоряется в разы... кстати классы здесь не панацея.. а лишь один из способов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2007, 18:44 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=34599219&tid=1589064]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
66ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
28ms |
get tp. blocked users: |
1ms |
| others: | 216ms |
| total: | 345ms |

| 0 / 0 |
