Tad, давай путать пользователя не будем (и себя тоже). Если SQLite_db стал менеджером, то он им и стал, те поддерживает общепринятую (нами) технологию беспроводных соединений и является сервером идентификатора базы без нарушения совместимости со старыми схемами с прямолинкованными элементами.

И вообще, получилась весьма интересная технология, которая совместима, и со старым схемами, и с новыми, да еще и видна отовсюду
------------ Дoбавленo:


Ну, это -- да. Ну скажи обязательно, когда попробуешь. Ты первый, из пользователей, кто юзает ретранслированные идентификаторы с реальными базами.
------------ Дoбавленo:

С ретрансляторами есть одна особенность -- не желательно цеплять к одному ретранслятору несколько разноименных баз, тк мы не сможем определить без дополнительного синхроимпулься, идентификатор какой базы сейчас ретранслируется. Те, на ретрансляторе, в текущий момент, активен последний идентификатор, полученный коммандой doOpen SQLite_db

nesco, если уж есть желание сделать БД беспроводными, то надо унифицировать всю вкладку сразу в едином интерфейсе, а не клепать под каждую технологию свои элементы.

Что имеется ввиду: надо делать ровно по одному элементу на каждото представителя источника данных и предоставлять им вот такой интерфейс
имеем:
DS_SQLite
DS_MySQL
DS_Ole
DS_ODBC

ну и по одному элементу на каждую операцию
DSC_Exec
DSC_ExecScalar
DSC_Query

в таком виде во всяком случае решается проблема с заменой источника данных в большой программе, чего давно весьма и весьма не хватает.

по поводу всяких там трансляторов я бы торопиться не стал. Не очень удачная это идея...

Пока впечатления от применения, особенно в одном мультике, - в основном положительные.
Вечером попробую в схеме, где 4-е разных БД используются одновременно.

для стороннего наблюдателя использование Managed SQLite тем хуже (в плане понимания), чем с большим количеством баз идет работа в пределах одной схемы. Тут обязательно надо вытягивать LH на имя менеджера иначе визуально будет невозможно понять, что к чему обращается.

чем больше полезность открытия, тем трагичнее последствия его неверного применения

Тут я не понял -- почему Как раз этого сильно и не хватает. Не зря же Tad спросил -- а как передать идентификатор из мультка в мультик. К тому же я попытался макисмально корректно освободить идентификаторы, чтобы не вызывать непредвиденных ситуаций. Я исследовал поведение модуля SQLite_db в динамическом мультике с возможностью его штатного уничтожения и все отработало нормально
------------ Дoбавленo:


Ну так не зря же это появилось после создани LH. К тому же, никто не запрещает использовать линки, они-то остались, можно же делать, и так, и эдак, как хочешь
------------ Дoбавленo:



Вопрос, а как это сделать, если у них разные методы работы с базами Тут надо посмотреть и перварить эту идею. Вечером обязательно более подробно обговорим, пока, я въехал только частично.
------------ Дoбавленo:


Да, кстати, я ничего и не клепал (кроме ретранслятора), а просто добавил интерфейс менеджера

в данный момент на этот вопрос определенного ответа нет. После реализации такой штуки в mra почему-то появилось ощущение, что так лучше не делать. Ну скажем при таких включениях теряется возможность отследить всех клиентов данного менеджера... А уж это к чему приведет в дальнейшем - большой вопрос.

Кроме того есть подозрение, что правильная схема это та, в которой иерхания привязок строится четко сверху вниз без ответвлений с возвратами на верхние уровни. На простом житейском опыте это выражается в том, что если я вижу некий клиент, то я точно знаю, что найду менеджера от него либо тут же, либо на N уровней выше, где N есть число в среднем не превышающее 1-5 единиц. С трансляторами это N будет тождественно равно количеству контейнеров. В тоже самое время его применение вообще говоря абсолютно ничего принципиально нового и интересного нам не дает => пока впечатление ниже нуля, хотя (напоменаю) говорить об этом с такой же уверенность как когда-то о менеджерах (только с обратным знаком) не рискну за неимением опыта использования.
------------ Дoбавленo:


ну так и источники данных разные, а вот запросы везде являются строкой, и ответв во всех случаях это наборы MT


а вот так делать не стоило... Как интересно после таго можно будет понять забыл ли я к элементу handle дотянуть или там просто менеджер в свойстве прописан Нет уж, предлагаю договориться - старые и хорошо отлаженные элементы мы постепенно перестаем трогать и делаем для этих целей новые разделы вкладок. Тем более если это касается менеджеров.

Вот мы и пришли к этому. Это проблема обострилась только сейчас, когда ты столкнулся именно с тем, что могут рядом находтся одинаковые элементы, но принадлежащие разным менеджерам. А я с эти уже столкнулся, а пользователи визжат уже давно. Но я ставлю метки (цветные квдратики), и потому всегда могу найти, кто какой группе принадлежит.

А транслятор -- это эксперимент, посмотреть, как оно будет с ним и без него. Тут вопрос однозначный -- хочешь ставь, а хочешь не ставь
------------ Дoбавленo:


Ну ты же пропал куда-то, я еще вчера про это думал, хотел поговорить -- как лучше сделать, отдельно или встроить. Вечером у меня закрались сомнения, что надо бы сделать отдельно, а то запутаются. Я обязательно это переделаю.
------------ Дoбавленo:


Кажется, начинаю понимать

посмотрел на SQLite_Exec и понял, что это не тоже самое, что делалось для mra. И вопрос тут поэтому как рез НЕ однозначный - присутствие вот этого в коде
говорит о том, что элемент на самом деле содержит аж три варианта получения handle вне зависимости от того, хочу я этого или нет... не стоит так проектировать элементы.


торопиться не стоило в любом случае

Тут вопрос возникает -- на кой ляд DS_ODBC делать, когда есть OLE, разве OLE не чере ODBC работает

Да и с MySQL млин... проблема, там NIC чего-то мутил, да и нет у меня баз MySQL, на чем можно проверить и настроить.

Давай, я сначала попробую и отлажу методы на SQLite и OLE, а затем все остальное
------------ Дoбавленo:


Ну да, так и есть. С этим я понял -- оставить старые элементы и не трогать их. Ну хорошо, а как совместить менеджера и ретранслятор, там по-любому получается, либо это, либо другое
------------ Дoбавленo:


Давай откатим, никаких проблем. Но вот Tad решил проверить на реальных базах, очень бы неплохо результата дождаться, а затем все вернуть и сделать по-другому, но уже с учетом реальных результатов

так я уже раза три писал про вкладку mra..
работает не зависимо ни от кого и ничего в коде добавлять не требуется

конкретнее скажу только после ознакомления с этим самым транслятором

Да то же самое, только не лучшей реализации. Над переделать, вот и все, я уже понял как это сделать.

Давай, я все же откачу назад, доделаю, отлажу, а потом посмотрим. Только ты иногда на связь вечерком выходи, так бы подсказал раньше с mra, и я бы на грабли не наступал

во время творческого креатива предпочитаю не отвлекаться на посторонние вещи

nesco, на какую мозоль Вам наступил?

Nic, ой ли

Сократ мне друг, но истина дороже (с)





Так что, авторы тут, может быть, и правильные, но вот редакторы предпочли промолчать, что кто-то переводил на 5-ю версию, да и Blob взялся ниоткуда

Если что-то и правится на SVN, то только с согласия автора: правило такой.