|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Вот, заменил вроде кусок проги, что могу тестировать хоть что-то... Действие: модуль следящий за процессами 1А) Меняет строку в таблице БД Код: plaintext 1.
============================ модуль UserInterface с Listview 1Б) по таймеру(Interval=1000) ловит файл, сгенерированный в п.2А (выше) и обновляет строчку в ListView Все корректно... Но дальше: в UserInterface есть кнопка "Обновить". Смысл: вся информация в ListView (700 строк в моем тесте) считывается из вышеупомянутой таблицы Table Сразу после обновления одной строчки(1Б) жмем этот обновить и видим что Строка заменилась СТАРЫМИ данными. Нет, с какого-то раза НОВЫЕ данные появляются, но это может быть через несколько секунд. Т.е. вывод какой: команда 1А выполняется СЛИШКОМ ДОЛГО. Когда вместо Table была текстовуха, ничего подобного не было. А я еще планирую пункты 2А и1Б заменить на 2АА) генерирует строчку в БД с указателем на строку обновленную в п.1А ============== 1ББ) по таймеру читает 2АА) из БД и заполняет одну(или несколько) строчку ListView из основной таблицы Table. А если там еще будет старое значение. И вообще, эти тормоза это не дело. М.б. подход неправильный? А какой правильный? Текстовухи оставить и не лезть в эти БД? Процессы кот. отслеживаются достаточно динамичные и задержки с отображением в несколько секунд мне не нужны... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 16:05 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Ээээ...все гораздо хуже. Это не СЛИШКОМ ДОЛГО, это ж, это потеря данных, это НЕНАДЕЖНО. Действие: модуль следящий за процессами 1) Добавляет строку в Table через INSERT INTO на следующем шаге через короткое время (информация по данному процессу изменилась): 2) Запрашивает по какому-то критерию эту же строку через SELECT ...WHERE и если она есть (RS.EOF=false) то 3) Делает ей обновление через UPDATE. Так вот засада в том, что на запрос в п.2 БД отвечает ("дарагой, да нет такой строки" RS.EOF=true), очевидно не успев обновиться согласно п.(1) Это не тормоза, это Ж, это гнилая технология. Это даже уже не знаю что делать... Это не на 700 строчках, это на одной строчке глючит. Идеи есть, кроме как послать все эти ADODB и БД в еБД? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 18:04 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Тэкс. Что-то ты не то наворотил, все должно работать нормально, без задержек. Вопрос для начала такой, а ты часом не используешь ДВА РАЗНЫХ коннекшна к одной базе? Если так - переделай на один. Если один - показывай фрагменты кода. ЗЫ: Или это вообще две разных программы? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 19:05 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий771) Добавляет строку в Table через INSERT INTO на следующем шаге через короткое время (информация по данному процессу изменилась): 2) Запрашивает по какому-то критерию эту же строку через SELECT ...WHERE ... Так вот засада в том, что на запрос в п.2 БД отвечает ("дарагой, да нет такой строки" RS.EOF=true) В одном коннекшне запросы стопудово работают синхронно (если только ты не запускаешь асинхронно умышленно), поэтому такой ситуации просто не может быть ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 19:22 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Shocker.ProЗЫ: Или это вообще две разных программы? Естественно. 1) модуль следящий за процессами 2) модуль UserInterface с Listview Это как минимум. Могут быть еще другие "клиенты", но эти 2 основные. Поэтому естественно Shocker.Proиспользуешь ДВА РАЗНЫХ коннекшна к одной базе Причем указанные 2 модуля должны держать коннекты непрерывно. Переделать в один не могу, нарочно разделял. Тот который "следящий за процессами" может быть "сервисом NT under local system account". Тот который "UserInterface с Listview", может быть вообще не запущен, прога все равно будет делать "дела". Можно конечно "отключаться/подключаться", но сам понимаешь... И потом это будет очень хаотический коннект/дисконнект. Приложение достаточно динамическое. Глобальные цели: 1) Улучшение "динамики", особенно при большом количестве строк и (или) одновременных процессов. 2) Легкость в добавлении новых ф-ций: поле напр. в БД проще добавить, чем переписать обработку текстовух. 3) Одновременный безпроблемный доступ к одной и той же "таблице". ("следящий за процессами" может добавить/редактировать строчку, User может строчку "редактировать"/удалить). Если я сейчас добавлю "обновление ListView через БД" с долблением БД по таймеру то при таком раскладе вообще все встанет. Т.е. операция Execute выполняется "несколько секунд", что неприемлимо. С таблицей-текстовухой: прочитал, нашел, поменял, сохранил- таких проблем не было. И переклиниваний из-за одновременного доступа к одной и той же текстовухе тоже не заметил, хотя логично предположить что это потенциальная проблема "текстовой" версии. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 19:30 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Ну я конечно понимаю что WHERE field LIKE '%" & somevalue & "%'" м.б. не лучший вариант (извесно кстати что строчка только одна, ее и надо получить) лучше наверно (по возможности! не всегда возможно!) WHERE field='value' но не похоже что глобальная проблема в этом. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 19:37 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77Т.е. операция Execute выполняется "несколько секунд", что неприемлимо. Так сколько выполняется Execute - имеется ввиду, что синхронная операция выполняется несколько секунд? (то есть в пределах одного приложения, другого пока не рассматриваем) Дмитрий77Ну я конечно понимаю что WHERE field LIKE '%" & somevalue & "%'" м.б. не лучший вариант (извесно кстати что строчка только одна, ее и надо получить) Отвратительный вариант. Если знаешь ключ строки - работать надо с ним. Засунь его в тэг листвью. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 19:49 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Shocker.ProДмитрий77Т.е. операция Execute выполняется "несколько секунд", что неприемлимо. Так сколько выполняется Execute - имеется ввиду, что синхронная операция выполняется несколько секунд? (то есть в пределах одного приложения, другого пока не рассматриваем). И как я это посчитаю? И зачем? Я и так вижу что несколько секунд. Посмотри в начало топика. 1A дает команду базе потом 1Б дает команду Listview "небазовым методом" (т.е. с т.зр. приложения команда 1A прошла) никаких доп.ключей в Execute я не использую. в ListView строчка обновилась потом я через Refresh читаю базу (таблицу) целиком и по виду той самой строчки понимаю что база команду 1A ни фига не выполнила и только после раза 5-го из базы скачивается "обновленная" информация Shocker.ProДмитрий77Ну я конечно понимаю что WHERE field LIKE '%" & somevalue & "%'" м.б. не лучший вариант (извесно кстати что строчка только одна, ее и надо получить) Отвратительный вариант. Если знаешь ключ строки - работать надо с ним. Засунь его в тэг листвью. Тэг я кажется для сортировки дат использую. Ну а при чем тут ListView. Такие "умные запросы" не UserInterface, а "модуль следящий за процессами" посылает, ему про ListView вообще ничего не известно. Критерием для поиска строчки является значение одного из полей (в нек. случаях часть поля), кот. не повторяется по логике программы. Не кажется ли Вам, что вся эта кухня тухлятинкой попахивает? Ну, потерял несколько дней, бывает. А то ведь и вправду через год волосы на себе рвать буду... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 20:55 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Shocker.Pro, зачем в тег, у листвью есть свой кей. ТС , что за СУБД ? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 20:57 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
big-duke, База mdb. Тестовый экземпляр создан в Access-2000. Предполагается создавать программно. Но если так дальше пойдет, то до этого боюсь не дойдет. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 21:46 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
И как я это посчитаю? Код: plaintext 1. 2.
Поэтому естественноНеестественно. Модуль, следящий за процессами, можно сделать в виде ActiveX exe, подключаться к нему через GetObject, просить соединение. А лучше не просить и вообще избавиться от таймера и дурацкого файла - надзиратель должен генерировать события с данными для интерфейса. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 23:25 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77И как я это посчитаю? И зачем? Я и так вижу что несколько секунд. Посмотри в начало топика. 1A дает команду базе потом 1Б дает команду Listview "небазовым методом" (т.е. с т.зр. приложения команда 1A прошла) Так еще, раз, ты меня не понял. Сколько времени выполняется конкретно команда Execute? (видимость обновленных данных в другом приложении пока не рассматриваем). Если несколько секунд - факт, что ты делаешь что-то неправильно. Дмитрий77Ну а при чем тут ListView. Такие "умные запросы" не UserInterface, а "модуль следящий за процессами" посылает, ему про ListView вообще ничего не известно. Данные надо обновлять по ключу, а не по Like. Тот, кто посылает команду Update, должен знать ключ строки, для того он и предназначен. Иначе ты навешиваешь блокировку по транзакции на всю, блин, таблицу, пока идет сканирование по Like, естественно, другие процессы начинают тормозить. Дмитрий77Не кажется ли Вам, что вся эта кухня тухлятинкой попахивает? Ну, потерял несколько дней, бывает. А то ведь и вправду через год волосы на себе рвать буду... Если считаешь, что проще и быстрее ездить на велосипеде, потому что не смог разобраться с педалью сцепления в автомобиле - твое право. И даже достоинства у велосипеда есть неоспоримые. Но, скажем, смотраться на выходные на дачу проще все же на авто. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2011, 23:52 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
AntonariyИ как я это посчитаю? Код: plaintext 1. 2.
Ты не понял суть "задницы". Вот типичный кусок кода надсмотрщика: Код: plaintext 1. 2. 3.
Файл name.ext (в нем находится одна строчка str, которая дублирует ту строчку в Table, что я посылаю в БД командой Update) Этот файл считывается таймером приложения, где ListView и обновляется одна строчка в ListView. И обновление этой строчки в ListView происходит быстро (из текстовухи, которая генерируется уже после Update) Посему понятно что debug.print DateDiff ничего плохого не покажет. А вот после того как строчка ListView обновилась (из текстовухи,которая генерируется уже после Update) Я в приложении где ListView жму кнопку "перегрузи весь ListView из базы", и весь ListView запрашивается из базы. И в том числе та строчка. И с ней все остальные И эта строчка оказывается со старыми данными (тем которое были до Update). Теперь понятно объянил? AntonariyЕще было бы интересно узнать, сколько записей в таблице, что так нещадно апдейтится.] Пробовал 700 строчек, пробовал 1 строчку. Результат примерно одинаков. Update давно отработал, а информация в базе не обновилась. А маразм доходит до того, что если из надсмотрщика делать код: Код: plaintext 1. 2. 3. 4.
то этот update не срабатывает, т.к. "та строчка что добавлена в (1)" еще не оприходовалась базой на момент когда ее надо уже править. т.е. я понимаю что 2-3сек не критично для секретарши которая ковыряет в носу, забивая при этом И-МЯ....ФА-МИ-ли---ЯЯЯЯЯ воз-расст <АББ-НАВИТЬ> но м.б. просто данная технология не для данной задачи? Честно, слышал что люди имеют проблемы при работе с БД, но не ожидал что это такое Г. Мою реализацию конечно можешь обсмеять, сказать много умного про ActiveX, SQL-сервер и т.п. Но проблема то не в этом. А проблема в том, что время "реальности/доступности" обновленных данных измеряется се-кун-дами, а это неприемлимо. Вот я счас потратил несколько дней чтобы имплементировать БД-access (частично, но можно тестировать). Это при том что я это хоть немного знаю. А прикинь я счас месяц потрачу на изучение каких-то новых "технологий" и будет такая же Ж. М.б. лучше направить усилия на оптимизацию моих "текстовых БД"? Shocker.ProТак еще, раз, ты меня не понял. Сколько времени выполняется конкретно команда Execute? (видимость обновленных данных в другом приложении пока не рассматриваем). Очень недолго выполняется, см.выше., или это непонятно из приведенного кода. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 00:34 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77А маразм доходит до того, что если из надсмотрщика делать код: Код: plaintext 1. 2. 3. 4.
то этот update не срабатывает, т.к. "та строчка что добавлена в (1)" еще не оприходовалась базой на момент когда ее надо уже править. Нет, при едином коннекте такого гарантированно вообще не может быть. Обновив данные ты тут же получишь обновленные, а не старые. Так что просто ты что-то не так делаешь, но я никак не могу понять из приведенных фрагментов - что именно. Можешь вычленить в чистый проект только этот код и выложить его вместе с тестовой таблицей БД? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 00:43 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Shocker.Pro, легко сказать "вычлени в чистый проект". В надсмотрщике я даже Debug.Print и /verbose применить легко не могу ибо он запускается из-под другого приложения и читает данные других модулей. Я добавил этот "дебаг" в лоб, раз уж просили посчитать (придется удалять потом) -сарказмов и лекций просьба не надо. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
Время самого паршивого execute составило 3 милли секунды, что приемлимо; до/после идут парами. Но при этом из БД считываются старые данные еще несколько секунд после... >Нет, при едином коннекте такого гарантированно вообще не может быть. Возможно, что-то напутал и вы правы. С этим думаю смогу разобраться. Но вот с задержкой обновления, когда считываешь эту таблицу факт есть факт. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 01:14 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77>Нет, при едином коннекте такого гарантированно вообще не может быть. Возможно, что-то напутал и вы правы. С этим думаю смогу разобраться. Но вот с задержкой обновления, когда считываешь эту таблицу факт есть факт. Честно говоря, и это несколько странно. Тогда тем более хотелось бы оба проекта в "очищенном" виде "для опытов" (с) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 01:27 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Shocker.Pro, Код: plaintext 1. 2. 3. 4.
Сейчас чуть добавил дебага. IF RS.EOF=false срабатывает корректно, но почему-то иногда может не сработать adoConn.Execute (UPDATE table SET... WHERE та строчка что добавлена в (1) т.е. может сработать, а может не сработать. При этом к строке апдейта я придраться не сумел. >Тогда тем более хотелось бы оба проекта в "очищенном" виде "для опытов" (с) Не смешите меня, я этими опытами уже 2 года занимаюсь. Это не будет работать в отрыве от всего приложения. Данные на вход "надсмотрщика" поступают из C++ плагина, кот. работает из под C++ приложения, кот. держится на нескольких dll и т.п. >Честно говоря, и это несколько странно. а что странного? Скорее всего глобальная проблема в следующем. Каждое Connection работает со своей "локальной копией" таблицы, базы и всей дребедени что с этим связано. Естественно по каким-то (медленным) законам идет обмен с "базой", но это действительно секунды, а не миллисекунды. Другой Connection работает со своей "локальной копией", которой про первую "копию" ничего не известно. Для обычной офисной базы этого более чем достаточно. Для динамической задачи этого не достаточно. Как вариант можно попробовать закрывать Connection (а не только рекордсет) после каждой операции, а потом открывать по новой. Можно попробовать отказаться от Execute и открывать рекордсеты "по-полной" Попробую завтра поиграться (применительно к тому "участку" проги что сделал). Но непонятно выдержит ли сама база и ADODB такой долбеж, а он и так не хилый. и главное будет ли это НАДЕЖНЫМ решением. Во времени я скорее всего сильно не проиграю. Т.е. на данном этапе надо довыяснить приемлимость модели, пока ответ "НЕТ". Текстовые файлы выдерживают. Что касается конструкций like %%, ну лучше конечно=, но это думаю "в рамках". По "ключу" вряд ли удастся. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 02:19 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77Как вариант можно попробовать закрывать Connection (а не только рекордсет) после каждой операции, а потом открывать по новой. Ага, так и есть. Если так делать, то все синхронно. Но при этом время на считывание 700 строк возрастает на 50% (+70мс на мощном компьютере), это дольше чем прочитать текстовуху. И еще непонятно, сколько мы теряем на "обработку одной записи", и не возникнет ли ситуации, что поток входящих данных за единицу времени превысит "максимальную пропускную способность" для обработчика. Т.е. если есть 50 процессов, и за секунду поступило 50 файлов, надо за эту секунду переконнектиться с базой 50 раз. Если на один реконнект тратится пусть 50мс, то 50Х50=2500мс=2,5сек. Как-то неправильно. Можно конечно делать реконнект по таймеру раз в сек (как я и делаю с данными). Connect>переработка данных> дисконнект. Остается еще понять, при дисконнекте база сразу ли проапгрейдится... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 03:17 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77, поддержка Майкрософт о Вашей проблеме ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 04:02 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77а что странного? Скорее всего глобальная проблема в следующем. Каждое Connection работает со своей "локальной копией" таблицы, базы и всей дребедени что с этим связано. Коннекшн не работает с таблицей вообще - это прерогатива рекордсета, а его-то как раз ты открываешь заново, поэтому он не может его кешировать. Несколько секунд - на мой взгляд очень много, не должно быть такого. Поэтому я просил очищенный тестовый вариант - чтобы можно было бы поиграть с параметрами соединения и самими запросами. Пока основное подозрение на like - из-за того, что он каждый раз при обновлении он сканирует (а может и блокирует) всю таблицу, возможно долго идет фиксация транзакции. Но это все надо пробовать руками на живом примере - теоретизирование результатов не даст. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 10:34 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
пробуй камнемДмитрий77, поддержка Майкрософт о Вашей проблеме The writer must start a transaction, using ADO's Connection.BeginTrans, prior to writing the data. The writer must make the database updates and then commit the transaction (using ADO's Connection.CommitTrans). The reader must call JRO.JetEngine.RefreshCache passing in it's connection prior to attempting to read the data. ну на первый взгляд - по делу ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 10:38 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Shocker.ProДмитрий77а что странного? Скорее всего глобальная проблема в следующем. Каждое Connection работает со своей "локальной копией" таблицы, базы и всей дребедени что с этим связано. Коннекшн не работает с таблицей вообще - это прерогатива рекордсета, а его-то как раз ты открываешь заново, поэтому он не может его кешировать.. Это все игра слов, анатомия и т.п. (вскрытие трупов и изучение "всей дребедени" не является целью) а суть я похоже угадал, и слава богу что хоть так. А пробуй камнем подсказал как правильно, за что ему наверно заранее спасибо, и думаю так и надо. Сейчас времени нет, а вечером обязательно попробую и отчитаюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 11:33 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Shocker.ProПока основное подозрение на like - из-за того, что он каждый раз при обновлении он сканирует (а может и блокирует) всю таблицу, возможно долго идет фиксация транзакции. Но это все надо пробовать руками на живом примере - теоретизирование результатов не даст. C Like я согласен что лучше по возможности надо менять на ='value'(не всегда возможно, но в большинстве случаев у меня возможно, это из-за лени вычислить точное значение их налепил), я уже убрал вчера кроме одного-двух мест, но "живой пример" показывает что это особых выигрышей на таблице в 1000 строк не дает и несоизмеримо с описанной выше проблемой, по сути которой пока все сказано выше. По хорошему еще надо добавить в запрос: 1) ищи только первое значение (наф. перелопачивать все, если уже нашли чего искали) 2) ищи его начиная с последних записей (sorted by key который incremented по убыванию, но не уверен что это sorted само по себе не добавит тормозов, одно дело всю таблицу в listview выводить, а другое дело просто короткий запрос) Если здесь подскажете, воспользуюсь. Почему с последних записей. Потому что нижняя часть записей это фактически статический архив процессов (м.б. потом имеет смысл перенести в отдельную таблицу, сейчас не хочу , надо тогда чуть менять структуру проги, это не будет проблемой сделать потом при желании, здесь мне извините видней). Поясню: например в почтовой программе есть письма "готовые к отправке", "отправля емые " (в тек. момент) и "отправ ленные " (архив). Shocker.ProПоэтому я просил очищенный тестовый вариант - чтобы можно было бы поиграть с параметрами соединения и самими запросами. Это примерно эквивалентно тому, что заново все написать. Я уже написал что это нереально при всем уважении к Вам и вашему желанию помочь. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 13:03 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77По хорошему еще надо добавить в запрос: 1) ищи только первое значение (наф. перелопачивать все, если уже нашли чего искали) 2) ищи его начиная с последних записей (sorted by key который incremented по убыванию, но не уверен что это sorted само по себе не добавит тормозов, одно дело всю таблицу в listview выводить, а другое дело просто короткий запрос) Код: plaintext
Поле, по которому идет сортировка, надо индексировать (можно даже сделать убывающий индекс, не знаю, повлияет ли это существенно на производительность), тогда в сочетании с TOP 1 запрос будет выполняться достаточно быстро Дмитрий77Поясню: например в почтовой программе есть письма "готовые к отправке", "отправля емые " (в тек. момент) и "отправ ленные " (архив). Надо просто ввести соответствующее поле с признаком и в WHERE дополнительно отбирать по этому признаку. Дмитрий77Shocker.ProПоэтому я просил очищенный тестовый вариант - чтобы можно было бы поиграть с параметрами соединения и самими запросами. Это примерно эквивалентно тому, что заново все написать. Я уже написал что это нереально при всем уважении к Вам и вашему желанию помочь. Ну это отладка методом последовательного приближения. Вот тут 7886988 подобную работу пришлось проделать, но она того стоила, ибо баг был побежден. Получается либо уполовинивать свой проект, проверять баг, если есть уполовинивать дальше и т.п. Либо наоборот создать чистый проект только с существенными функциями (в нашем случае это два проекта, один с инсертом, другой с селектом по таймеру) и смотреть, есть ли баг. Тут тебе виднее. Впрочем, надо сначала попробовать совет от микрософта. Однако, если даже если он поможет, это не отменяет оптимизации работы с БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2011, 13:50 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Shocker.ProВпрочем, надо сначала попробовать совет от микрософта. Да, проверил. Все путем. Основная проблема с задержкой обмена в несколько секунд решается. Но это было ясно без кодов и без проверки после того как. 1. Я предположил что re-connect спасет, и это подтвердилось проверкой. Хотя понятно что долбеж connect-disconnect не есть гуд. 2. Пробуй камнем ткнул в правильное решение проблемы. Спасибо ему еще раз. Единственное. Конструкция (обновиться перед чтением): Код: plaintext 1. 2.
Microsoft Jet and Replication Objects 2.6 Library (msjro.dll) Ответа по поводу какую версию ADO подключать я так и не получил (вы упомянули про 2.8 и типа усе есть, но я бы не форсировал...из осторожности), поэтому считаю логичным, если уж добавлять refrerencы то вот эту пару Код: plaintext 1.
Или все-таки CreateObject? Вот все беспокоюся...Меня честно это сторона вопроса беспокоит гораздо больше чем Like %%. Т.е. предпочту ездить на велосипеде чем разбиться на недоделанном ЛА. P.S. При наличии парашюта и навыков по применению оного можно и по крайнему варианту. Но есть проблема: не все пользователи - парашютисты. По поводу лайков и прочего. Ну это на самом деле рихтовка по сравнению с задержками на секунды. Тем не менее не буду злоупотреблять советами. Shocker.ProПоле, по которому идет сортировка, надо индексировать . бог с ним, сделал: Код: plaintext 1. 2. 3. 4.
Shocker.ProОднако в SELECTe можно получить ключевое поле и использовать его в UPDATE. Это лучше, чем Like в Update... в сочетании с TOP 1.... В большинстве ф-ций применил конструкцию: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Однако идеализировать не надо, есть исключения: 1. В одном месте я все таки применяю LIKE (констукция field имеет вид "СЛОВО(StrValue)", где СЛОВО - могут быть разные): Код: plaintext 1. 2.
не всегда оно есть. Строчка может обновляться целиком (т.е. все новые значения полей содержатся в свежепоступивших данных). Тогда первый запрос с SELECT отсутствует, т.е. тогда Код: plaintext 1. 2.
Но это повторюсь рихтовка. Чтобы оценить динамику, надо все доделать, тогда смогу запустить краш-тесты (скажем по 50 одновременных процессов с разрастанием таблицы до нескольких тысяч записей). Вот тогда и посмотрим, как эти 50 строк будут "одновременно" обновляться при скажем 10000 записей в таблице (реально обычно 1-3 процесса и 10-100 записей, но динамично-массовые исключения должны быть предусмотрены и также реально могут иметь место быть на отдельных пусть редких user-системах). Понятно что без решения первой проблемы ни о какой динамике говорить вообще нельзя, но она тьфу-тьфу решилась. Shocker.ProНу это отладка методом последовательного приближения.. Ну а как ты хотел. Запускается через Shell из под другой проги, в Debuggeре не посмотришь, в отрыве от контекста не проверишь, /verbose особо не вставишь, надо дописывать строки, потом удалять или комментировать, но такие комментарии в большом кол-ве это "мусор" в коде. Добавь сюда до кучи еще протектор, без обработки которым некот. модули вообще работать не будут. Shocker.Proв нашем случае это два проекта, один с инсертом, другой с селектом по таймеру.. Не упрощайте, и того и другого и третьего в обоих хватает.... У меня там не 2 проекта а два десятка модулей, если не больше. Хотя согласен, не все лезут в БД с целью ее изрикошетить, таких не много. Эти 2 -основные. Shocker.ProТут тебе виднее... Ясно дело...Но какую-то часть осилил. Можно двигаться дальше. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 02:50 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77Единственное. Конструкция (обновиться перед чтением): Код: plaintext 1. 2.
Microsoft Jet and Replication Objects 2.6 Library (msjro.dll) Конечно же требует, это раннее связывание. Дмитрий77Ответа по поводу какую версию ADO подключать я так и не получил (вы упомянули про 2.8 и типа усе есть, но я бы не форсировал...из осторожности), поэтому считаю логичным, если уж добавлять refrerencы то вот эту пару Код: plaintext 1.
Не вижу логики в использовании версии 2.6 против 2.8. Или у вас есть объективные предпочтения к 2.6 ? Дмитрий77Или все-таки CreateObject? Вот все беспокоюся...Меня честно это сторона вопроса беспокоит гораздо больше чем Like %%. Т.е. предпочту ездить на велосипеде чем разбиться на недоделанном ЛА. Почитайте про раннее связывание VS позднее связывание. Дмитрий77По поводу лайков и прочего. Ну это на самом деле рихтовка по сравнению с задержками на секунды. Тем не менее не буду злоупотреблять советами. Это не рихтовка, а грамотное проектирование. Так что вы правильно сделали, что последовали совету Shocker.Pro. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 08:29 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77Ответа по поводу какую версию ADO подключать я так и не получил (вы упомянули про 2.8 и типа усе есть, но я бы не форсировал...из осторожности) Версии 2.8 сто лет в обед, она вылизана (по крайней мере относительно старых версий, а глюки есть во всех) и никаких нареканий на нее я не слышал. Так или иначе у меня была в проекте проверка на то, чтобы версия была не ниже 2.8, потому что не работали какие-то функции, щас уже не вспомню какие. Я, в принципе, тоже не сторонник ставить САМЫЕ свежие версии софта, если старые работают нормально, но в данном случае, как я говорил, нареканий на 2.8 я не слышал. Shocker.Pro Код: plaintext 1. 2. 3. 4.
Совет - не надо злоупотреблять звездочкой, когда это не требуется. Если надо только ID, указывай в отборе только ID. Утрированный пример: через год ты в эту таблицу решишь добавить бинарное поле в которое положишь мегабайтный файл. И все конструкции Select * будут каждый раз при запросе считывать его на клиента. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 10:24 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
big-dukeНе вижу логики в использовании версии 2.6 против 2.8. Или у вас есть объективные предпочтения к 2.6 ? Почитайте про раннее связывание VS позднее связывание. Давайте разберемся: сейчас у меня типа так: Код: 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.
Сборная солянка. Есть 3 варианта: I. Код: plaintext 1.
II. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
III. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Как утверждает Shocker.Pro, библиотека всегда есть, т.е. получается ссылки (раннее связывание) можно использовать смело. Хорошо если так. А вдруг user покурочил систему? Сам долбо*б конечно, но тем не менее. Хоть сказать ему об этом в byby:... Опять же? big-dukeНе вижу логики в использовании версии 2.6 против 2.8. Или у вас есть объективные предпочтения к 2.6 ? Мне честно говоря на это наплевать. Мне надо чтоб программа ВСЕГДА ЗАПУСТИЛАСЬ. Я так понимаю особого отличия в версиях нет по крайней мере начиная с какой-нибудь 2.5 По поводу конкретно 2.8 смущает вот эта "двойственность": Код: plaintext 1.
Почему ADO 2.6?... Чисто субъективно Код: plaintext
и только эта версия. Значит пусть будут одинаковые, что-то в этом есть. !!!Дальше. Конструкция (В-I и В-II) Код: plaintext 1.
я так понимаю предписывает использовать объект строго версии 2.6. А если в системе вдруг нет 2.6 а есть 2.5 и(ли) 2.8 например... Просто в варианте 3 Код: plaintext
про номер версии намеков нет. Т.е. я так понимаю система на ходу присасывается к той версии, что сочтет нужной и все работает. Ну а если уж совсем дело дрянь, то можно хотя бы уйти на byby: "культурно попрощавшись" с юзером. Мне честно говоря вот эти ссылки...поди почитай. Читать можно умно и долго. Потом выпускаешь прогу и через неделю приходит mail с скриншотом "ActiveX not able to create object" где юзер на корявом английском справедливо вопрошает. Have you any idea (solution) about this? Вот поэтому я и спрашиваю:не что почитать а как надо чтоб всегда запустилось и работало на всех OS:от Win XP 32bit-до-Win7 64bit? а не как можно? И вопрос этот далеко не праздный. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 10:54 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
> Автор: Дмитрий77 > где юзер на корявом английском справедливо вопрошает. > Have you any idea (solution) about this? У каждой программы есть свои требования для нормального функционирования. И тот кто их не читает имеет проблемы. Я не знаю как в инсталяторе проверить наличие установленной версии АДО или чего-то другого. Как вариант, можно сделать startup object - Sub Main в которой через CreateObject проверить "создаваемость" всех интересуемых объектов и их версий и при наличии расхождений с требованиями выдавать предупреждение о несоответствии минимальным требованиям. Если расхождений нет, тогда запускать уже рабочую форму программы. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 11:20 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
ПОЛУОФФ: Игорь Горбонос, установленная версия ADODOB Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 11:55 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Топик открыт. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 14:19 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
пробуй камнем ПОЛУОФФ: Игорь Горбонос, установленная версия ADODOB Код: plaintext
Код: plaintext 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 14:21 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77А вдруг user покурочил систему? Сам долбо*б конечно, но тем не менее.У него при этом не будет работать треть софта на машине, мне кажется, так что ему немедленно будет грозить переустановка MDAC ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 14:30 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77, А знаешь, че я тебе скажу. У меня в файле проекта (vbp) написано следующее: Код: plaintext 1.
при этом и IDE и скомпилированный проект работает с 2.8 автоматически ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 14:39 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
всё правильно, работает самый последний (актуальный) зарегистрированный компонент по имени вашего GUID из референса ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 14:45 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
big-dukeТопик открыт. Благодарствую. Shocker.Pro Код: plaintext 1.
при этом и IDE и скомпилированный проект работает с 2.8 автоматически Ну т.е. ссылается именно на "2.0 Library", а реально работает с "2.8 Library"? Я тоже попробовал поставить ссылку как у вас и у меня база "открылась". При этом база создана Access2000, а насколько помню для Access2000 нужен mdac2.5 (vb6 SP5 когда-то ради этого специально ставил). Konst_Oneвсё правильно, работает самый последний (актуальный) зарегистрированный компонент по имени вашего GUID из референса Т.е. неважно что я ставлю в reference (2.0, 2.5 или 2.8), а все равно будет работать 2.8 (последняя) и это в общем и целом эквивалентно выбору версии при Код: plaintext
Shocker.ProДмитрий77А вдруг user покурочил систему? Сам долбо*б конечно, но тем не менее.У него при этом не будет работать треть софта на машине, мне кажется, так что ему немедленно будет грозить переустановка MDAC Наверно так. Игорь Горбонос, усложнять жизнь поисками в реестре и CreateObject наверно тогда не стоит? Ну т.е. я прекращаю париться, оставляю Код: plaintext 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 19:53 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77Ну т.е. ссылается именно на "2.0 Library", а реально работает с "2.8 Library"?да Дмитрий77Т.е. неважно что я ставлю в reference (2.0, 2.5 или 2.8), а все равно будет работать 2.8 (последняя) и это в общем и целом эквивалентно выбору версии при Код: plaintext
По идее да. У меня так же автоматически меняются версии для подключенных MS Word и MS Excel и проект работает с той версией офиса, что найдет на клиентском компе. Кстати, если он не найдет офиса вообще, exe-шник запускается даже при раннем связывании и спокойно работает до первого обращения к офису, где и ругается на "Can't create object" (повторяю - при раннем связывании, не только при позднем) - с ADO будет, думаю, то же самое. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2011, 20:03 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Shocker.ProДмитрий77 Код: plaintext
Совет - не надо злоупотреблять звездочкой, когда это не требуется. Если надо только ID, указывай в отборе только ID. Ну, пока смог этим воспользоваться только в двух местах, причем в одном "только ID",в другом 2 поля: Код: plaintext 1.
Shocker.Pro"Утрированный пример: через год ты в эту таблицу решишь добавить бинарное поле в которое положишь мегабайтный файл. Ну, это уж слишком, файлы в таблицу я класть в ближайшей пятилетке не собираюсь. Shocker.ProКстати, если он не найдет офиса вообще, exe-шник запускается даже при раннем связывании и спокойно работает до первого обращения к офису, где и ругается на "Can't create object" (повторяю - при раннем связывании, не только при позднем) - с ADO будет, думаю, то же самое. Исходя из всего сказанного думаю, что оставляю как есть, т.е. с ссылками на 2.6+2.6 big-dukeПочитайте про раннее связывание VS позднее связывание. Я глянул чуть-чуть, якобы позднее связывание чуть добавляет "тормозов",хотя я не думаю что это сравнимо с мировой революцией. В данном случае думаю можно оставить раннее, еще и потому что каждый раз при правке кода с CreateObject придется раскомментировать для удобства отдельные места, что в данном случае будет несколько объемно. Игорь ГорбоносУ каждой программы есть свои требования для нормального функционирования. И тот кто их не читает имеет проблемы. Это да. Но половина не читает. Половина из тех кто читает не понимает о чем речь. Если даже в лоб выдать фразу ".NET Framework v. такая-то" не установлен, большинство не знает что это такое и как установить. Конкретно с .NET (т.к. были проблемы несмотря на "требования"), пришлось добавить 1) Понять установлен/не установлен и какая версия (через реестр по методу как тут про ADO было предложено) 2) Выдать сообщение о том что не установлен с кнопкой далее и словами что это надо и предупреждением что установка будет долгой 3) По кнопке далее установить. На самом деле чтобы все эти процедуры проверки/установки сделать качественно, надо затратить существенные усилия. В случае с ADO наверно самое правильное не предпринимать ничего. В этой связи вспоминается пример с CDO.Message. (хотя у меня в коде там позднее связывание) Раньше зачем-то вынул его из XP и пытался устанавливать с программой. При установке на Vista эта процедура стала "часто ругаться". Решил вообще удалить "доустановку". За два года не нашлось человека у которого бы не работало CDO и кто бы мне об этом сообщил. Видимо с ADO надо поступить также, т.е не делать ничего. Предполагая слишком много малореальных вариантов и способов их обхода можно понаделать кучу сбственных ляпов. Shocker.ProДмитрий77А вдруг user покурочил систему? Сам долбо*б конечно, но тем не менее.У него при этом не будет работать треть софта на машине, мне кажется, так что ему немедленно будет грозить переустановка MDAC Скорее винды. Мне один написал: не могу распаковать setup.zip. ZIP был сделан штатным XP-архиватором...Такого не предусмотришь. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 01:58 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77Shocker.Proнемедленно будет грозить переустановка MDAC Скорее винды. была такая у меня темка... в копилку Эквивалент переустановки MDAC под WinXP ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2011, 10:07 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Shocker.Pro, да и ко всем вобщем вопрос: С OleDB.OleDbConnection никто с Access не работал (в .NET)? Т.е. в свете озвученной здесь темы Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection Строчка Код: vbnet 1.
чтобы не было проблем при интенсивной работе с базой. Аналог для OleDB.OleDbConnection? Не, я пока не нарвался на проблему, но это надо много кода написать, чтоб нарваться. А сюрпризов не хочу. Поиск по интернету наводит на плохие мысли. М.б. ну его, эту "новейшую технологию" и подключить ADODB к .NET -проекту? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 13:22 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77М.б. ну его, эту "новейшую технологию" и подключить ADODB к .NET -проекту?+1 Объектная модель System.Data шизофренична и перегружена, хотя некоторые вещи, тебе пока не нужные, делаются проще. В дотнете есть собственный ADODB, брат-близнец классического, правда он не всегда присутствует в списке сборок. Если в списке его нет, то можно найти вручную в C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies\adodb.dll Если будешь работать с MSSQL, советую освоить EntityFramework, он удобнее ADODB, хотя может не все. На все остальное сгодится System.Data, причем это остальное как раз те вещи, что делаются просто. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 14:20 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Antonariy, Ну, этот собственный adodb я нашел по указанному тобой пути (вставил через обзор). Но меня смущает Версия 7.0.3300.0 (а не 4.0) Т.е начнешь ставить на другие системы, на x64 и т.д. - кабы не было проблем. С классическим ADODB проблем не возникает. И как быть с JRO. С учетом вот этой поправки Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection BeginTrans/CommitTrans -> Jro не нужен? которую я прокомментировал но никто не подтвердил JRO.RefreshCash вроде как и не надо. Если это так Так ли? то можно использовать OleDB как рекомендовано. SQL-Запросы те же, синтаксис похожий. Или все-таки действительно ну его, и использовать классический ADODB + перекатывание кода в лоб из VB6. Все таки хочу допонять путь по которому итти перед тем как чего-то делать. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 14:48 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Дмитрий77Т.е начнешь ставить на другие системы, на x64 и т.д. - кабы не было проблем.Кидай в папку с программой — вообще никаких проблем, это тебе не MDAC. Дмитрий77И как быть с JRO.Я даже не знаю что это. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 14:51 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
AntonariyДмитрий77И как быть с JRO.Я даже не знаю что это. Это то, без чего есть вероятность 1) поменять строчку в таблице 2) А в следующем действии прочитать ту же строчку без учета изменений сделанных в п.(1) При работе с записной книжкой это не важно (нединамическая операция). А вот когда я пишу тек. статистику телефонного вызова (факса) в эту "строчку", где интервал записи-чтения-записи может составлять пару миллисекунд это уже критично. Поэтому логичным является вопрос. Эквивалентно ли жесткое соблюдение BeginTrans/CommitTrans при update/insert/delete действию JRO.RefreshCash после которого я уверен что все предыдущие изменения будут отражены при выполнении последующих обращений. JRO.RefreshCash -контролирует что все изменения точно попали из кэша в БД. Access (база .mdb имеется ввиду) по умолчанию сбрасывает кэш раз в 5 секунд, если я не ошибаюсь. Просто с \Primary Interop Assemblies\adodb.dll нужен также аналог для JRO а если без JRO можно обойтись, соблюдая BeginTrans/CommitTrans то почему б тогда все-таки не System.Data.OleDB... ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 15:11 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Я бы забил на акс и юзал sql compact. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 15:18 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Antonariy, НЕ, я к такому фундаментальному шагу не готов. mdb для моих целей вполне нормально. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 15:26 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
а зачем тебе JRO ? он вообще-то для контроля/изменения струтуры jet-баз ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 15:35 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Konst_One, Ну 10 раз уж одно и то же переписываю: Дмитрий77Это то, без чего есть вероятность 1) поменять строчку в таблице 2) А в следующем действии прочитать ту же строчку без учета изменений сделанных в п.(1) JRO.RefreshCash -контролирует что все изменения точно попали из кэша в БД. Access (база .mdb имеется ввиду) по умолчанию сбрасывает кэш раз в 5 секунд, если я не ошибаюсь. 10132170 Shocker.Proпробуй камнемДмитрий77, поддержка Майкрософт о Вашей проблеме The writer must start a transaction, using ADO's Connection.BeginTrans, prior to writing the data. The writer must make the database updates and then commit the transaction (using ADO's Connection.CommitTrans). The reader must call JRO.JetEngine.RefreshCache passing in it's connection prior to attempting to read the data. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 15:48 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
автор1) поменять строчку в таблице для этого не нужен JRO ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 15:50 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Konst_One, Для (1) -нет не нужен. А для гарантии отсутствия этого? Дмитрий772) А в следующем действии прочитать ту же строчку без учета изменений сделанных в п.(1) Я задал вопрос: 14934467 Дмитрий77 Если я при всех командах UPDATE DELETE INSERT INTO делаю BeginTrans/CommitTrans То верно ли что я застрахован от следующей ситуации: 1) поменял строчку в таблице 2) А в следующем действии прочитал ту же строчку без учета изменений сделанных в п.(1) И мне не надо делать JRO.RefreshCash? (в том числе для классического ADODB). Считай что между UPDATE(строка) и SELECT(та же строка) может пройти 1 миллисекунда (например). Время релаксации-утрясания кэша для mdb БД = 5 секунд (кажется). JRO.RefreshCash сбрасывает кэш. Но там молчат. Т.е. ответственности за это утверждение никто брать на себя не хочет. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 15:58 |
|
БД, она тормозит с обновлением что ли...
|
|||
---|---|---|---|
#18+
Konst_One, понимаешь в чем задница. Он не только пишет в кэш. The writer must start a transaction, using ADO's Connection.BeginTrans, prior to writing the data. The writer must make the database updates and then commit the transaction (using ADO's Connection.CommitTrans). -это решает вопрос записи в реальную БД. Он гад еще и читает из кэша. Поэтому сдается мне что The reader must call JRO.JetEngine.RefreshCache passing in it's connection prior to attempting to read the data. необходимо. Потому что первая часть BeginTrans/CommitTrans лишь гарантирует, что в реальной БД будет обновленная строчка. Но не гарантирует, что из кэша не будет затем прочитана НЕобновленная (старая) строчка. А JRO это как раз гарантирует. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 16:10 |
|
|
start [/forum/moderation_log.php?user_name=%D0%95%D1%80%D0%BD%D0%B5%D1%81%D1%82]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
75ms |
get tp. blocked users: |
1ms |
others: | 2732ms |
total: | 2912ms |
0 / 0 |