Shocker.ProВпрочем, надо сначала попробовать совет от микрософта.
Да, проверил. Все путем. Основная проблема с задержкой обмена в несколько секунд решается.
Но это было ясно без кодов и без проверки после того как.
1. Я предположил что re-connect спасет, и это подтвердилось проверкой. Хотя понятно что долбеж connect-disconnect не есть гуд.
2.
Пробуй камнем ткнул в правильное решение проблемы. Спасибо ему еще раз.
Единственное. Конструкция (обновиться перед чтением):
1.
2.
Public my_JRO As New JRO.JetEngine
...
my_JRO.RefreshCache adoConn
требует дополнительно ссылаться на
Microsoft Jet and Replication Objects 2.6 Library (msjro.dll)
Ответа по поводу какую версию ADO подключать я так и не получил (вы упомянули про 2.8 и типа усе есть, но я бы не форсировал...из осторожности),
поэтому считаю логичным, если уж добавлять refrerencы то вот эту пару
1.
Microsoft ActiveX Data Objects 2 . 6 Library (msado26.dll)
Microsoft Jet and Replication Objects 2 . 6 Library (msjro.dll)
По крайней мере этот вариант прокатил на чистой Win7 x64 (компилирую на XP 32 bit ясно дело).
Или все-таки CreateObject? Вот все беспокоюся...Меня честно это сторона вопроса беспокоит гораздо больше чем Like %%. Т.е. предпочту ездить на велосипеде чем разбиться на недоделанном ЛА.
P.S. При наличии парашюта и навыков по применению оного можно и по крайнему варианту. Но есть проблема: не все пользователи - парашютисты.
По поводу лайков и прочего. Ну это на самом деле рихтовка по сравнению с задержками на секунды.
Тем не менее не буду злоупотреблять советами.
Shocker.ProПоле, по которому идет сортировка, надо индексировать .
бог с ним, сделал:
1.
2.
3.
4.
Имя поля = ID
Тип данных = счетчик
Размер поля = длинное целое
Новые значения = последовательные
Индексированное поле = да (совпадения не допускаются)
Shocker.ProОднако в SELECTe можно получить ключевое поле и использовать его в UPDATE. Это лучше, чем Like в Update... в сочетании с TOP 1....
В большинстве ф-ций применил конструкцию:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Dim lng_ID As Long
...
my_JRO.RefreshCache adoConn
Set RS = adoConn.Execute _
("SELECT TOP 1 * FROM Table WHERE field='value' ORDER BY ID DESC")
...
If RS.EOF = False Then 'только если запись существует (по структуре базы она единственная)
...
lng_ID = RS!ID
...
adoConn.BeginTrans
adoConn.Execute ("UPDATE table SET " & SQLString & " WHERE ID=" & CStr(lng_ID))
adoConn.CommitTrans
Однако идеализировать не надо, есть исключения:
1. В одном месте я все таки применяю LIKE (констукция field имеет вид "СЛОВО(StrValue)", где СЛОВО - могут быть разные):
1.
2.
my_JRO.RefreshCache adoConn
Set RS = adoConn.Execute _
("SELECT TOP 1 * FROM table WHERE field LIKE '%" & StrValue & "%' ORDER BY ID DESC")
2.Shocker.Proа SELECT все равно есть.
не всегда оно есть. Строчка может обновляться целиком (т.е. все новые значения полей содержатся в свежепоступивших данных). Тогда первый запрос с SELECT отсутствует, т.е. тогда
1.
2.
adoConn.BeginTrans
adoConn.Execute ("UPDATE table SET " & SQLString & " WHERE field='value'")
adoConn.CommitTrans
Но это повторюсь рихтовка. Чтобы оценить динамику, надо все доделать, тогда смогу запустить краш-тесты (скажем по 50 одновременных процессов с разрастанием таблицы до нескольких тысяч записей). Вот тогда и посмотрим, как эти 50 строк будут "одновременно" обновляться при скажем 10000 записей в таблице (реально обычно 1-3 процесса и 10-100 записей, но динамично-массовые исключения должны быть предусмотрены и также реально могут иметь место быть на отдельных пусть редких user-системах). Понятно что без решения первой проблемы ни о какой динамике говорить вообще нельзя, но она тьфу-тьфу решилась.
Shocker.ProНу это отладка методом последовательного приближения..
Ну а как ты хотел. Запускается через Shell из под другой проги, в Debuggeре не посмотришь, в отрыве от контекста не проверишь, /verbose особо не вставишь, надо дописывать строки, потом удалять или комментировать, но такие комментарии в большом кол-ве это "мусор" в коде. Добавь сюда до кучи еще протектор, без обработки которым некот. модули вообще работать не будут.
Shocker.Proв нашем случае это два проекта, один с инсертом, другой с селектом по таймеру..
Не упрощайте, и того и другого и третьего в обоих хватает....
У меня там не 2 проекта а два десятка модулей, если не больше. Хотя согласен, не все лезут в БД с целью ее изрикошетить, таких не много. Эти 2 -основные.
Shocker.ProТут тебе виднее...
Ясно дело...Но какую-то часть осилил. Можно двигаться дальше.
