|
|
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#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. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. Вот отчет на почти идентичных базах: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. - висяк 1м 26сек ПОСЛЕ отработки всех операторов (присвоения) в момент закрытия ссылок на базы (или явного "close") (при практически идентичных БД) никакие танцы с бубнами типа dbANY.Close и anyCollection.Refresh не ведут к существенному изменению (Refresh, как видно по отчету (1-й вариант), даже не изменил времен выполнения/закрытия). Что-то я тут упускаю, или действительно нет способа повлиять на этот феномен? Уж больно надолго все это. Причем дисковых операций вроде и нет, а процессор грузит на все 100. А уж ежели в Access2.0 (с маленькими синтаксическими помарками)... :o) там минут на 10 -15 зависание в норме. Но, что странно, - прочухивается сам. зы: код конечно не блеск - правлю по случаям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2003, 16:25 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#18+
Я, канешна, не гуру, но позволил себе скопировать и запустить изложенный текст. Для пробы использовались 2 одинаковых файла xxx.mdb и yyy.mdb. "Висяки" "откомментарил". Их нету. Усе отработалось махом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2003, 16:54 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#18+
Версия Акеса? - (я наблюдаю в 97, и 2-м). Размер файлов? (число таблиц) - (36/37 - мой тест) Наличие данных? (общий объем данных - до 3-mb - тест). То-то и оно, что все отрабатывается (даже с изменениями в таблицах) в приемлемое время, а завершение - минуты интенсивного счета на одном операторе вида Set ... = Nothing (...Close). mayBe файл рабочих группппп?/разрешения?/хотя пересоединился к файлу р/г на сетке - 1:28 - т.е. в пределах погрешности :) то же самое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2003, 17:50 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#18+
Действительно, в 97-м с более-менее немаленькой базой работает медленно. Поскольку я не могу пока ответить на твой вопрос, я его перефразирую: Вот этот код: Код: 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. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. в 97 аксесе при сравнении двух одинаковых файлов с несколькими десятками таблиц работает очень быстро. Но если "раскоментарить" первую из закоментаренных строк, появляются явные тормоза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2003, 19:25 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#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. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. Видимо, обращение к некоторым свойствам поля по имени почему-то заставляет Access как бы "кэшировать" операции до закрытия. Отсюда встречный вопрос: а нельзя ли вместа прохода по всем возможным свойствам поля проверить десяток нужных, как то: подпись, тип, источник строк и т.п. (кстати, а не в источнике строк ли дело? Любит Access на всякий случай проверять его корректность). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2003, 19:44 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#18+
Спасибо. Действительно, проверка только свойства .Name ("name") не вызывает таких тормозов как (хотя бы опрос) свойств Default, Constraint (не помню имен) и т.п. Но именно их я и проверяю. Идея о "несинхронной" обработке результатов изменений с задержанной обработкой по выходу интересна, но, боюсь, не верна: - Смешно, но аналогичная функция копирования индексов тормозов не вызывает. (хоть я и запускаю ее больше на этапе отладки процедуры "приведения" к таблиц с данными к нужному новому виду), не слишком полагаясь на безупречность своего кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2003, 20:23 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#18+
Итак, гуру в отпуске :о) Меня интересует вопрос именно потому, что даже когда в базе ничего не меняем, висяк возникает - пропорционально, видимо, количеству просмотренных полей объектов семейств TableDefs (обеих? баз). Хотелось бы избавиться от этой зависимости от "интимной жизни" Аксесса. Но переписывать задачу на sql вида Alter Table не хочется - все равно нужно будет осуществлять анализ dbSource по пропертям полей таблиц (семейства TableDefs) -если дело в обращениях к свойствам - висяки остануться (разве что впополам сократятся по времени). Путь создания новых таблиц по образцам (копирования структур из образца методом Tranfer) и вливания туда данных из (переименованных) старых таблиц тут не желателен - при несовместимости размеров/типов нужно принимать решение о конечном типе/размере полей (чтобы не потерять данных и/или, дополнительной функциональности, возможно реализованной в модифицируемом приложении, но не реализованной в "образце" сравнения). Т.е. этот путь обоснован для окончательной реализации "стандартной" процедуры конвертации (после создания полнофункционального эталонного образца), но при анализе (напр. в процессе ручной конвертации, что чаще, ибо обычно нет явных поколенческих "версий", но есть масса мелких модификаций приложений /как правило, даже не моих :0)/). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2003, 10:54 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#18+
Еще немного: (обеих? баз) Не обеих. Если выкинуть Set prpIn = fldIn.Properties(pName) и все, что ниже нее внутри последнего цикла, мы проходим по всем(!) пропертям базы1 через .Properties(i), но не обращаемся по имени к свойствам полей базы2, и зависаний нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2003, 11:16 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#18+
2Geo Спасибо. Я заметил это по Вашим постам, но не вижу разницы в том случае, если мы НИЧЕГО не меняем во второй базе. Т.е. Аксес, вы думаете, начинает заниматься "интимом" именно после обращения к пропертям по имени? А это наводит....! - тогда делаем перебор по индексу до нахождения имени (т.е. обращаемся по индексу, но не по имени), и ... Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. получаем: Код: plaintext 1. 2. 3. 4. 5. т.е. : циклы поиска не увеличили (существенно) времени исполнения, но, кажется время "закрытия" сократилось на 10+-2 сек. ? (проверка со "старой" процедурой сегодня - 1:27) ? С "новой", но без "исполняемой части (коментарий на все строки цикла If prpS.Value <> prpIn.Value ) - время закрытия - 1:18 -в пределах ошибки замера(+1-1) =1:16). Таким образом: !да, обращение по имени вызывает большую задержку закрытия, !но проблема в самом факте вызова имменно "пропертей" полей таблицы "вставки" (без вставки). Вызов проперти таблицы "источника" почему-то не вызывает таких проблем ???!!! Или просто проблема открытия одновременно 2-х баз в одном Workspace-е?? /проверю, позже. надеюсь вернуться :)/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2003, 12:42 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#18+
п.с. Только, если можно, на "ты". :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2003, 13:20 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#18+
п.с. Только, если можно, на "ты". :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2003, 13:20 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#18+
21-08-03, 16:54 Я, канешна, не гуру,... Лифчик, не подкалывай, плиз :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2003, 14:39 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#18+
проверил. 1. задание разных воркспейсов не приводит (к заметным) изменениям. А вот гемора не оберешься - требуется явное задание юзера и пароля. Если неохота - добавляй нового, вставляй (в цикле) во все группы, и надейся, что прав на открытие для правки таблиц хватит (а не толькона чтение макетов). Как будто сложно открыть воркспейс с текущим юзером. Он же не от балды тут груши околачивает. ссссс... 2. Вроде чуть (~10 сек) быстрее закрывается, если явно задать режимы открытия: Set dbsSource = DBEngine.Workspaces(0).OpenDatabase(FilePathSource, False, True) Set dbsIn = DBEngine.Workspaces(0).OpenDatabase(FilePathIn, False, False) (причем именно НЕмонопольный). и dbsSource.Close : dbsIn.Close или это ошибка измерения? (что-то теперь зависимости от способа вызова проперти по имени/номеру я не намерил). Зато можно явно замерить время закрытия каждой бд. На моем "стандартном наборе время поделилось ~ 24с/46с на закрытие dbsSource и dbsIn соотвтественно. Таким образом : время закрытия dbsSource растет с ~0 до 24 сек, только при условии, что я опрашиваю проперти таблиц второй базы (dbsIn). Что занятно. Осталось еще попробовать разделить открытия баз по времени. т.е. заполнять массивы, при открытии таблицы из первой базы, закрывать базу, открывать вторую, пытаться вставить массивы. Ибо, как я проверил, _последовательное_ (с закрытием первой перед открытием второй) открытие баз, перебор таблиц, полей и их проперти не приводит (как и ожидалось) к зависанию (по крайней мере до тех пор, пока ничего в свойства не пишется). ЗЫ. А гуру отмолчались. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2003, 19:01 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#18+
> ЗЫ. А гуру отмолчались. :( Значит, у них никаких идей... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2003, 20:14 |
|
||
|
давно зреет вопрос к гуру
|
|||
|---|---|---|---|
|
#18+
Пробно реализовал "разделение" по времени. Действительно считает медленнее (заполнение всех массивов с переопределением размеров), но закрывается шустрее. Приведу результаты, может быть интересно: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. (базы те же, что и раньше) - прогнал "туда и обратно" - то, что менялось - меняется и т.п. + Имеет видимо смысл вытаскивать только свойства из заданного перечня [имен] - а то заполение массивов времени требует многовато. :( теперь проблема, как это на совместимый с Акс2.0 синтаксис перевести :( Ему ж не скажешь: { ReDim Preserve tbl_S(nT).tfld(nF).mprp(nP) } Однако вопрос о том, что понуждает аксесс надолго задумываться в случае, когда к свойствам полей таблиц второй бд я обращался до закрытия первой (бд)остается. И можно ли обойти эту неприятную особенность, не прибегая к сложным развязкам (с созданием собственных сложных структур, что не только требует времени, но и может быть источником ошибок)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2003, 15:09 |
|
||
|
|

start [/forum/topic.php?fid=45&msg=32243885&tid=1679747]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
30ms |
get topic data: |
6ms |
get forum data: |
3ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 225ms |
| total: | 315ms |

| 0 / 0 |
