|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Перевод на .NET Код: vbnet 1. 2. 3. 4. 5. 6.
Ну, я полагаю эквивалентов для adOpenForwardOnly и adLockReadOnly в случае использования OleDbDataReader не требуется. Но меня очень волнует вопрос. Код: vbnet 1.
М.б. это не самый удачный пример, и в данном конкретном случае сойдет и без этого, но если программа общается с БД динамически, то отсутствие этой строчки приводит к БОЛЬШОЙ ЗАДНИЦЕ БД, она тормозит с обновлением что ли... Посему мне нужен эквивалент для JRO.RefreshCache How To Synchronize Writes and Reads with the Jet OLE DB Provider and ADO Либо аргументированные гарантии, что ситуаций подобных описанной не будет с замечательными .NET объектами OleDB.(и т.д. и т.п.) Вкратце. Задница, это когда я 1) запрашиваю запись, в зависимости от результата перезаписываю ее 2) через короткое время опять запрашиваю запись, в зависимости от результата перезаписываю ее 3) а при этом оказывается что запись на шаге (2) прочитана без учета изменений, сделанных на шаге (1) Не, я конечно могу использовать проверенный ADODB.... ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 05:11 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Не, м.б. правда проще ADODB подключить через COM и забить на "новейшую технологию"? ADODB проверена годами. Если OleDb не умеет обновлять кэш (был проделан поиск и возникло такое подозрение), то будут геморои. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 13:37 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Дмитрий77, ADODB - это враппер над OLEDB для скриптовых языков если што ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 13:44 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
ИзопропилADODB - это враппер над OLEDB если што Смейся, смейся. Но я задал конкретный вопрос: Код: vbnet 1.
Как обновить кэш в OLEDB? И мне нужен ответ на него 1) Надо сделать ТАК-ТО и ТАК-ТО или 2) В этом нет необходимости, ПОТОМУ ЧТО... ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 13:58 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Дмитрий772) В этом нет необходимости, ПОТОМУ ЧТО... надо делать коммит транзакции после апдейта ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 14:02 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Pallarisнадо делать коммит транзакции после апдейта Ты имеешь ввиду, что при всех командах UPDATE DELETE INSERT INTO надо делать BeginTrans/CommitTrans? И в этом случае при любых командах SELECT обновление кэша (my_JRO.RefreshCache adoConn) не нужно. Ну при условии, что все клиенты работающие с БД соблюдают правило BeginTrans/CommitTrans? Аналог BeginTrans/CommitTrans в OleDB есть, я видел. Если так, то я всегда это делаю. Хотя возможно не делал на момент описания и решения проблемы через JRO. Т.е. получается что и в VB6 (ADODB) кодах JRO лишний? Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 14:20 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
ИзопропилДмитрий77, ADODB - это враппер над OLEDB для скриптовых языков если што Если што, существует Microsoft.NET\Primary Interop Assemblies\adodb.dll Скрипты на него не натянешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 14:54 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Дмитрий77, задай наконец вопрос ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 15:12 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
pation, я задал вопрос. Если я при всех командах UPDATE DELETE INSERT INTO делаю BeginTrans/CommitTrans То верно ли что я застрахован от следующей ситуации: 1) поменял строчку в таблице 2) А в следующем действии прочитал ту же строчку без учета изменений сделанных в п.(1) И мне не надо делать JRO.RefreshCash? (в том числе для классического ADODB). Считай что между UPDATE(строка) и SELECT(та же строка) может пройти 1 миллисекунда (например). Время релаксации-утрясания кэша для mdb БД = 5 секунд (кажется). JRO.RefreshCash сбрасывает кэш. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 15:24 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Потому что согласно этому: 10132170 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:32 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Молчание? Я думаю так: Он не только пишет в кэш. 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 это как раз гарантирует. И получается что отсутствие механизма обновления кэша ПЕРЕД ЧТЕНИЕМ говорит не в пользу OleDB модели. Короче подключаю COM. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 16:17 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Дмитрий77, OleDb это универсальная технология доступа к данным которая не обязана учитывать детали реализации БД Access. Попробуй подлючиться к своей БД с помощью ACE OLEDB 12 . Возможно в этом новом драйвере нет таких проблем, иначе придется использовать ADODB. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 16:39 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
bazileПопробуй подлючиться к своей БД с помощью ACE OLEDB 12 . Возможно... Не буду пробовать. Это непроверенная технология. Да, лучше COM. AntonariyИзопропилДмитрий77, ADODB - это враппер над OLEDB для скриптовых языков если што Если што, существует Microsoft.NET\Primary Interop Assemblies\adodb.dll Antonariy, а знаешь что странно. Я счас добавил COM -> Microsoft ActiveX Data Object 2.6 Library (как привык -проверено) Путь -> C:\Program Files\Common Files\ system\ado\msado26.tlb А он мне вбабахал: Microsoft ActiveX Data Object 2.6 Library Тип: COM Версия 2.6.0.0 Но при этом Путь: C:\Windows\assembly\GAC\ADODB\7.0.3300.0_b03f5...\ADODB.dll Он мне пытается намекнуть что то что предлагал ты и COM это вообще одно и то же. Ссылку то на твой вариант Microsoft.NET\Primary Interop Assemblies\adodb.dll я удалил. Но м.б. не надо было играться с твоим вариантом и теперь где-то в проекте что-то надо чистить. И меня это несколько смущает. В VB6 я ничего не таскал за проектом на тему ADODB. И здесь я тоже ничего не хочу "кидать в папку с проектом", как ты написал. Не возникнет проблем? Счас допишу чуть кода "по старинке", посмотрю чего будет. М.б. вообще ссылки в баню и As Object /Create Object забабахать чтоб .NET не шибко умничал? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 17:14 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Дмитрий77 Да, лучше COM.После прочтения статьи на MS скажу, что без вариантов. Дмитрий77 Он мне пытается намекнуть что то что предлагал ты и COM это вообще одно и то же. Ссылку то на твой вариант Microsoft.NET\Primary Interop Assemblies\adodb.dll я удалил. Но м.б. не надо было играться с твоим вариантом и теперь где-то в проекте что-то надо чистить. И меня это несколько смущает. В VB6 я ничего не таскал за проектом на тему ADODB. И здесь я тоже ничего не хочу "кидать в папку с проектом", как ты написал.Нет, это не одно и то же. Для COM-библиотек студия делает .net-обертку с приставкой Interop, это она таскается. А почему путь через GAC? Наверное обертка конкретно для COM ADODB по каким-то причинам существует в готовом виде. Дмитрий77 Не возникнет проблем?В дотнете практически нет проблем совместимости, я по крайней мере ни с чем таким не сталкивался. Дмитрий77 М.б. вообще ссылки в баню и As Object /Create Object забабахать чтоб .NET не шибко умничал?Тогда будет создаваться объект последней версии, а не 2.6 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 17:45 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
AntonariyДмитрий77 М.б. вообще ссылки в баню и As Object /Create Object забабахать чтоб .NET не шибко умничал?Тогда будет создаваться объект последней версии, а не 2.6 А все равно будет последняя версия. Обсуждали уже 2.6 я пишу по принципу "Проверено, не рвануло, значит и дальше не рванет" ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 18:44 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Дмитрий77Antonariyпропущено... Тогда будет создаваться объект последней версии, а не 2.6 А все равно будет последняя версия. Обсуждали уже 2.6 я пишу по принципу "Проверено, не рвануло, значит и дальше не рванет" Antonariy, у меня плохие новости. Этот .NET гораздо тупее VB6. Тупее чем мы думали. Добавляю ADODB как COM (на XP) Переношу exe на 7 x64 Ругается матом. Удаляю COM, добавляю adodb.dll что ты сказал. Переношу exe на 7 x64 Ругается матом. Кидаю adodb.dll в папку с exe, все равно ругается. Убираю вообще все ссылки. Пишу (проверенным способом, устраняющим все конфликты версий): Код: vbnet 1. 2. 3. 4.
Наконец запускается. Скажу честно, это не очень удобно. Сначала добавляешь ссылку, чтоб написать код. Потом ее грохаешь и заменяешь на позднее связывание. Что думаешь? Net-exeшник часом не как x64 под 7-x64 стартует? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 20:05 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Дмитрий77 Удаляю COM, добавляю adodb.dll что ты сказал. Переношу exe на 7 x64 Ругается матом.Ну х.з., у меня так работало. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 21:08 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Дмитрий77 Что думаешь?Думаю, можно не грохать. Вряд ли студия разучилась удалять инфу о неиспользуемых компонентах. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 21:25 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
AntonariyНу х.з., у меня так работало. Судя по тому что ты здесь указал на C:\Program Files (x86) ты делал exe изначально на x64. Потом там еще есть опции компиляции (Target CPU x86, x64, универсальный какой-то, я Рихтера начал было читать, хотя забил). Хотя у меня в VB2010 EE нету, да и бог с ним, надеюсь что exe все-таки получается x86. Но, ты ж понимаешь что вариант ХЗ меня не устроит, поэтому видимо придется делать CreateObject. Но это неудобно. В VB6 при том что я ленился с ADODB менять на CreateObject (хотя хотел), проблем нигде не было. >Думаю, можно не грохать. Грохнуть-восстановить ссылку 5 сек, дольше код редактировать если надо что-то исправить (со слепыми объектами работать неудобно). ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2013, 22:34 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
автор Код: vbnet 1. 2. 3. 4. 5. 6.
Вот жутко интересно, под скромным комментарием 'работаем с записью, что скрывается? Исользуете ли Вы DataTable? авторВкратце. Задница, это когда я 1) запрашиваю запись, в зависимости от результата перезаписываю ее 2) через короткое время опять запрашиваю запись, в зависимости от результата перезаписываю ее 3) а при этом оказывается что запись на шаге (2) прочитана без учета изменений, сделанных на шаге (1) запрашиваю запись - откуда, снова запрос к БД или из DataTable? перезаписываею ее - Это означает, что Вы изменили DataRow из DataTable и выполнили операцию Update через короткое время опять запрашиваю запись - снова запрос к БД или будет достаточно обратиться за данными к DataTable? Если будет запрос к БД, то будь добр результат положи в DataTable в зависимости от результата перезаписываю ее - изменения вносим в DataRow соответствующей табл. данных и выполняем Update а при этом оказывается что запись на шаге (2) прочитана без учета изменений, сделанных на шаге (1) - Ээээээ, уж точно это не проблема ADO .NET, это уже логика работы сервера (уровни изолированности транзакций). ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 04:47 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Ermak, Все не в кассу. Имеем: 1) База Access 2) Две программы с разными, само собой, соединениями с этой базой. 3) У каждого соединения свой кэш. 4) Изменения, сделанные одним соединением, не успевают за требуемый очень короткий промежуток времени отразиться в кэше другого соединения. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 09:28 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Antonariy... 4) Изменения, сделанные одним соединением, не успевают за требуемый очень короткий промежуток времени отразиться в кэше другого соединения. А должны? Откуда другое соединение знает, что кэш должен обновиться? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 10:27 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Alex KuznetsovAntonariy... 4) Изменения, сделанные одним соединением, не успевают за требуемый очень короткий промежуток времени отразиться в кэше другого соединения. А должны? Откуда другое соединение знает, что кэш должен обновиться?Не должны и не знает. А надо. В этом и проблема. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 10:33 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
AntonariyAlex Kuznetsovпропущено... А должны? Откуда другое соединение знает, что кэш должен обновиться?Не должны и не знает. А надо. В этом и проблема.Значит должно быть уведомление от одного приложения другому, что нуна данные в кэше обновить... ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 10:53 |
|
Эквивалент JRO.RefreshCache adoConn при переходе ADODB.Connection->OleDb.OleDbConnection
|
|||
---|---|---|---|
#18+
Проблема не в уведомлениях, которые нафиг не нужны при миллисекундных периодах (кеш нужно обновлять перед запросом), а в отсутствии в дотнте инструментов для обновления кэша. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2013, 11:49 |
|
|
start [/forum/topic.php?fid=20&tid=1403904]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
60ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
70ms |
get tp. blocked users: |
1ms |
others: | 338ms |
total: | 507ms |
0 / 0 |