Здравсте.
Вообщем проблема вот в чем. Пытаюсь освоить трех звенку. Почитал хелп.. Почитал инет.
Вроде понял куда и чего надо делать, чтобы оно заработало.
Решил делать через DCOM.
На локальной машине все работает (когда и сервер и клиент на ней). Причем не важно, есть ли Делфи на этой машине или нет. Т.е. с midas.dll вроде разобрались.
А вот когда сервер на одной машине (Win2k3), а клиент на другой, уже проблема. Клиент не видит "сервер". Т.е. указываю имя компьютера, а то, что на нем крутится сервер, клиент не видит.
Вроде проблема в правах. Пытался поковырять dcomcnfg. Выставил все права на Everyone (остальные удалил) на полный контроль (где нашел). Не помогло.
Запускал даже на контроллере домена (без настройки прав, т.е. по дефолту). При этом клиентская машина была включено в него и пользователь был членом Domain Admins.
Регистрировал сервер через /regserver.
В списке зарегистрированных он появляется. Но клиент все равно не видит его.
Что надо еще прописать или настроить, чтобы они друг-друга увидели?

> Регистрировал сервер через /regserver


На обоих хостах регистрировал ?

> Сергей М. ©   (01.10.08 11:00) [1]

Не понял вопроса.
Регистрировал только на сервере.
Или вы про вариант, когда на одном компьютере? Тогда тоже регистрировал.
Может я не так понял? На клиенте тоже надо регистрировать чтоли?

> На клиенте тоже надо регистрировать чтоли?

естественно. DCOM работает с GUIDами, которые должны быть прописаны в реестре на клиенте.
Зарегистрируй библиотеку типов tlb на клиенте

Дико извиняюсь, но не догоняю.
Как зарегистрировать библиотеку не понял. Как импортировать понял. Зачем - не понял.
Я думал там все проще. Клиент подключается к серверу и....
Может где есть почитать именно про эту часть 3х звенки?
А то толком не нахожу инфу. Везде только про создание на одной машине. А про нюансы "распределения" на разные компьютеры - не нахожу.

> Как зарегистрировать библиотеку не понял

delphi/bin/tregsrv yourtypelib.tlb
можно и программно - RegisterTypeLib() при первом запуске клиента

Блин. Или я туплю... Или что.
Вообщем рассказываю как делал ПО ШАГАМ.

Сервер:
Создал приложение.
Добавил в него TRemoteDataModule. Дал ему имя. Instancig - Multiple. Threading Model - Netrual.
На него бросил ADOConnection, ADODataSet, DataSetProvider1.
Настроил их друг на друга и вписал строку запроса.
Сохранил. Откомпилил. Перебросил на другой компьютер (он же контроллер домена) ЕХЕ файл и midas.dll.
midas.dll бросил в Windows\System32 и сделал regsvr32.exe midas.dll
Мне сказало, что ОК.
Далее запустил свой сервер с параметром /regserver.
Посмотрел в dcomcnfg - он там появился.

Клиент:
Создал приложение.
На форму бросил DCOMConnection1, ClientDataSet1, DataSource1, DBGrid1.
Настроил их друг на друга.
У DCOMConnection1 свойство ComputerName выставил в имя моего сервера (компьютера). Решил выбрать (в дизайн тайме) ServerName - пусто.

Теперь что начал делать по вашим советам.
Сделал clickmaker ©   (01.10.08 14:29) [5] на клиенте.
Не помогло.
Сделал еще и на сервере.
Не помогло.
tbl файл брал от моего сервера. После компиляции там в папке создался.

Что я упустил или сделал не так??

при вызове DCOMConnection1.Open лезут какие-либо исключения?
сервер и клиент в одном домене?
на серваке есть доступ к этому COM-серверу у запускающего юзера на клиенте? (Security - Access permissions - Customize)
сервер - это обычный экзешник или сервис?

> clickmaker ©   (01.10.08 17:15) [7]


> при вызове DCOMConnection1.Open лезут какие-либо исключения?

Собсна до этого не доходит, т.к. я в данный момент пытаюсь в дизайн тайме настроить ServerName и другие параметры.


> сервер и клиент в одном домене?

Да.


> на серваке есть доступ к этому COM-серверу у запускающего
> юзера на клиенте?

Везде, где нашел, поставил Everyone на полный доступ и еще добавил Domain Admins (коим являюсь я) и Domain Users.


> сервер - это обычный экзешник или сервис?

Просто обычный ЕХЕ с обычной Формой.

> обычный ЕХЕ с обычной Формой.


Зачем серверу форма ? Кто на нее глазеть-то будет ?)

Ты бы потренировался что-ли на, скажем, Excel'е как на удаленном COM-сервере - при прочих равных условиях он хотя бы корректно регистрируется, так что при правильной настройке DCOM-конфигурации удаленный доступ к нему (см. CreateRemoteCOMObject) обычно не вызывает проблем.

> Собсна до этого не доходит, т.к. я в данный момент пытаюсь
> в дизайн тайме настроить ServerName и другие параметры

ты читал про ServerName в справке? Что там про реестр написано?
Используй ComputerName в рантайме

> Сергей М. ©   (01.10.08 17:33) [9]


> Зачем серверу форма ? Кто на нее глазеть-то будет ?)

Ну как же!! А фишечки рюшечки? Я на нее еще скины повешу!! (шука конечно).
Это только сейчас у него форма. Пока я просто пытаюсь понять что и как.


> Ты бы потренировался что-ли на, скажем, Excel'е как на удаленном
> COM-сервере - при прочих равных условиях он хотя бы корректно
> регистрируется, так что при правильной настройке DCOM-конфигурации
> удаленный доступ к нему (см. CreateRemoteCOMObject) обычно
> не вызывает проблем.

Блин... Видимо придется начать оттуда, если ничего не выйдет так.


> clickmaker ©   (01.10.08 17:59) [10]


> ты читал про ServerName в справке? Что там про реестр написано?

Собсна написано там вот что:
For DCOM and OLEnterprise connections, the servers must be registered in the system Registry.
И все. А как эту регистрацию провести и куда в реестре писать - ни слова.


> Используй ComputerName в рантайме

Не совсем понял, что это дает. Мне бы в дизайн тайме в начале получить соединение, чтобы легче и наглядней было создать остальные ClientDataSet'ы и другие настройки просто выбирая параметры из списка.

так ComputerName же тоже паблишед. Чего бы его не установить в дизайн тайме?

> clickmaker ©   (01.10.08 18:47) [12]

Опять не понял. Дык я же все делаю в дизайн тайме.

> DeadMeat   (02.10.08 08:15) [13]


т.е. ты выбрал имя компьютера, а список ServerName пустой ?

> Сергей М. ©   (02.10.08 09:14) [14]

Именно. А при тех же действиях, но на локальном компьютере (тоже в дизайн тайме) в нем появляется имя моего дата модуля. Т.е. чтото гдето не зарегистрировано это точно. Но я сделал все, как тут писали и это не помогло.

> DeadMeat   (02.10.08 09:22) [15]
>
>


Предлагаю самостоятельно разобраться в происходящем, внимательно изучив текст процедуры MConnect.GetMIDASAppServerList

> Сергей М. ©   (02.10.08 09:36) [16]

Последовал вашему совету. Правда почему то мой дебагер в этот юнит не заходит, поэтому пришлось изучать "на глаз".
Если я правильно понял, то оно ищет (используя GetServerList) в реестре CLSID. Руками поискав в реестре (на предмет ГУИДа моего сервера) я нашел что он там есть. Появляется после регистрации tlb файла и "уходит" после анрегистрации (не знаю как правильно это по русски).
Вот собсна и все, что я понял..
Может в службе какой проблема? Может в правах? Хотя права я крутил как только мог.

> почему то мой дебагер в этот юнит не заходит


Потому что в опциях отладки в св-вах проекта должна быть установлена опция "Use Debug DCU's".

Use Debug DCUs
The Debug DCUs contain debug information and are built with stack frames. When this option is checked, the compliler prepends the Debug DCU path (specified in Tools|Debugger Options on the General page) to the unit Search path specified in Project|Options on the Directories/Conditionals page.

То что список ServerName у тебя пустой (в дизайн-тайм или в ран-тайм - не важно) говорит только об одном - фабрика класса твоего MIDAS-сервера не зарегистрирована (или зарегистрирована некорректно) на том компьютере, на котором вызывается метод TDispatchConnection.GetServerList, т.е. на компьютере, где работает контроллер твоего MIDAS-сервера.

> я нашел что он там есть


При штатной регистрации в реестре должны фигурировать как минимум 3 ключа, где фигурирует CLSID твоего сервера.

Приведи сюда полные пути и содержимое этих ключей ..

Открыл в IDE файл Server.tlb (он у меня так называется). Там дерево.
Взял GUID от Server (это корень):


Поиск в реестре дал следующее:

(это GUID от IGHostDataServer - это я так назвал мой RemoDataModule)
В этом разделе три подраздела:
ProxyStubClsid
ProxyStubClsid32
TypeLib
Последний и содержит в себе тот GUID
Следующий ключ в реестре:


У него один подраздел:
1.0
В нем еще свои три:
0
FLAGS
HELPDIR
В подразделе 0 есть один подраздел:
win32
В нем прописано значение REG_SZ, содержащее путь к моему tlb файлу.
Есть еще два, но они дублируют содержимое первых двух и находятся в


В самом Server_TLB.pas:
Первый - это
. Это который в корне дерева.
Второй -
.
Третий GUID (который в реестре я не нашел) -

Вот собсна и все.

> GUID (который в реестре я не нашел) - CLASS_GHostDataServer:
>  TGUID = '{9BA5689E-17EE-4661-A999-A9F0212076AE}'


Ну вот тебе и объяснение наблюдаемого тобой "чуда".

Запусти свое серверное приложение как обычное приложение - при первом же запуске произойдет регистрация фабрики класса твоего MIDAS-сервера.

После этого лезешь в реестр , находишь вновь (по отношению к [21]) появившиеся ключи, касающиеся CLASS_GHostDataServer, и приводишь их пути и полное содержимое сюда.

p.s.
Результаты приводи в формате *.reg-формате - так легче читать и воспринимать творящееся в реестре

> Сергей М. ©   (03.10.08 12:17) [22]

Запустил. Не появилось ничего нового.
Попробовал зарегить сервер у себя (на клиенте) - GUID появился.
На всякий случай приведу ветки для обоих случаев сразу (когда регистрировал только tlb файл и когда регистрировал только сервер).
tlb:



--




==============

Server:



---




---




Получается, что для того, чтобы это дело заработало, надо регить сервера на клиенте (либо руками добавлять нужные записи) и править реестр.
Делаю вывод, что либо я чтото не вызываю (при запуске клиента), либо чтото не так регистрирую (на клиенте), либо дурак.

> чтобы это дело заработало, надо регить сервера на клиенте


Так тебе об этом давным-давно вроде бы уже сказано, см. [1])

Фабрика класса сервера д.б. зарегистрирована на обеих сторонах будущего взаимодействия.

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

Да и справка об этом говорит недвусмысленно:

The general steps for creating a multi-tiered database application are

1 Create the application server.
2 Register or install the application server.
3 Create a client application.

The order of creation is important. You should create and run the application server before you create a client. At design time, you can then connect to the application server to test your client. You can, of course, create a client without specifying the application server at design time, and only supply the server name at runtime. However, doing so prevents you from seeing if your application works as expected when you code at design time, and you will not be able to choose servers and providers using the Object Inspector.

Note

If you are not creating the client application on the same system as the server, and you are using a DCOM connection, you may want to register the application server on the client system. This makes the connection component aware of the application server at design time so that you can choose server names and provider names from a drop-down list in the Object Inspector. (If you are using a Web connection, SOAP connection, or socket connection, the connection component fetches the names of registered providers from the server machine.)

Как раз твой случай)

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

Этот CLSID ты можешь указать явно ручками, а можешь получить его из реестра по имени, если такая инф-ция там имеется в результате автоматической (см. выше цитату из справки) или эквивалентной ей ручной регистрации.

Блин извиняюсь... с тэгами напутал. После обеда голова слабо соображает.

> подключение уже делать по заранее записанному GUIDу или
> имени сервера


Серверной стороне имя MIDAS-сервера не нужно - она работает только с GUID.

Имя MIDAS-сервера нужно только клиентской стороне, если угодно - как минимум для удобства восприятия пользователем и/или программистом. Согласись, гораздо удобнее оперировать осмысленными именами, нежели длиннющей строкой лишенных смысла символов. Подобно тому как обращаться к хостам в Интернете неизмеримо удобней осуществлять по их доменным именам, а не по IP-адресам, хотя фактическое обращение осуществляется именно по IP-адресам, а функции разрешения имени в адрес возлагаются на распределенную DNS-систему.

Так вот разрешением имени в GUID как раз и заведуют соответствующие рег.записи в реестре. Если их нет, то разрешение невозможно.

> Сергей М. ©   (03.10.08 15:20) [29]

Ну насчет GUIDов и IPов все понятно. Я имею ввиду, правильно-ли то, что я понял? Что для процесса разработки (т.е. в дизайн тайме) надо иметь сервер у себя на локальной машине, а перебросив его на другую, делать только все только в рантайме?

Нет, не правильно. Точнее - не совсем правильно.

Сам сервер (т.е. его исп.модуль) у себя на лок.машине нужно иметь лишь для отладочных целей, в условиях когда удаленная его отладка невозможна и/или нежелательна. При этом его регистрация у себя на лок.машине, разумеется, обязательна.

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

Ну а в рантайм или в дизайнтайм происходит фактическое обращение к серверу (где бы он ни находился фактически) - это не имеет принципиально никакого значения.

> Сергей М. ©   (03.10.08 15:47) [31]


> Эту регистрацию можно сделать как запустив однократно приложение-
> сервер на лок.машине (после чего его исп.модуль на лок.машине
> впредь более не понадобится), так и внеся вручную соотв.
> записи в реестр.

Ага.. Вот в этом и проблема. Т.к. запустив его просто так, записи не добавились. Пришлось его именно регистрировать. Возникает вопрос, добавлять эти записи (тот ключ, которого не достает) вручную (в смысле самому в реестр) или есть штатный способ для этого? Не таскать же с клиентом постоянно сервер.
Вот в реальной ситуации уже при установке. Надо у заказчика (допустим) развернуть эту систему.
Примерные действия (на мой взгляд):
на машине сервере установка серверной части, путем ее регистрации (/regserver)
на машине клиенте установка клиентской части, путем ее регистрации
Вот второй пункт вызывает проблемы. Руками записывать данные в реестр (не хотелось бы) или использовать какой-то штатный способ для этого (хотелось бы)?

> Руками записывать данные в реестр (не хотелось бы)


Что-то ты тормозишь откровенно)

В "боевых" условиях никакой регистрации сервера в реестре на кл.стороне не требуется !

Если твой боевой клиент знает GUID сервера - этого вполне достаточно.

> [33] Сергей М. ©   (04.10.08 09:44)

Ну тупой... ну бывает.. ну что вы сразу. ;)
Просто меня постоянно сбивало с толку то, что в дизайн тайме у меня даже чисто с гуидом ничего не получалось. Я то проверял и этот вариант тоже. Но видать чего-то в другом месте было намучено и не срабатывало.
Теперь все ясно. Теперь хотя бы не буду ждать того поведения, которое ожидал.
Так или иначе...
ОГРОМНОЕ СПАСИБО за потраченное на меня время. Знаю, это не легко.
Благодарю еще раз... вопрос закрыт.

Так... С этим разобрались. Все работает. Все прекрасно (еще раз спасибо за помощь).
Теперь такой вопрос возник. Как этот сервер подружить с сервисом?
Вопрос именно в более-менее "стандартной" дружбе.
Т.е. регистрация COM объекта руками через WinAPIшные команды это я понял. Нашел как и где. Но вот не хотелось бы к такому прибегать. Хочется стандартное чтото. Чтобы свои штатные IDEшные средства.
Как например /regserver (ну почти IDEшное).
Просто в сервисе такое уже не прокатывает, как я понял. Службу та я создаю, а вот как зарегистрировать мой COM сервер "в ней".
Ожидаемое поведение такое:
инсталляция службы в систему
в процессе инсталяции службы, регистрация COM сервера
запуск службы
обращение клиента к COM серверу, не вызывающее повторного запуска ЕХЕ файла последнего (как при обычной регистрации сервера без службы)
деинсталяция службы, дерегистрация COM сервера

Повторюсь, хотелось бы найти штатные IDEшные или Делфийские средства, а не изощраться спаривая оных с WinAPIшными.
Я конечно понимаю, что Делфийские так или иначе вызывают WinAPIшные... но вот такое вот странное у меня желание.

ЗЫ. Пример из кладовки и одну из соответствующих тем на Королевстве смотрел. Это как раз то, чего хотелось бы избежать.

> Пример из кладовки и одну из соответствующих тем на Королевстве
> смотрел


Ссылки приведи ..

> Сергей М. ©   (07.10.08 08:33) [36]

Даже не знаю... С утра сижу и пытаюсь добавить сюда пост. Потом доперло... скорее всего спаморезка не пускает сразу много ссылок.

Здесь раз: delphimaster.ru/cgi-bin/http://pda.delphimaster.net/?id=1190904445&n=8
Оттуда два: delphimaster.ru/cgi-bin/http://pda.delphimaster.net/?id=1158154010&n=8
И там три: delphikingdom.info/asp/answer.asp?IDAnswer=54223
Рядом четыре: kladovka.net.ru/index.cgi?pid=dir&rid=24

Я их не проверял, но примерную суть понял. Все же чтото "постандартней" хотелось бы...

Понятно.
И что тебя в примере от Набережных С. (с) не устраивает конкретно ?

> Сергей М. ©   (07.10.08 10:24) [38]

Конкретно именно громоздоксть всей процедуры регистрации и установки. Т.е. то, что надо делать руками. Именно это и хотелось бы заменить на нечто, более "штатное" чтоли. С одной стороны это может показаться некой глупостью и детским садом, т.к. по сути один раз сделал и забыл. Но тем не менее..... Не могу поверить, что IDE не предоставляет подобных инструментов или визардов (нет нет.. я не избалованный батонокидатель)..
Но если таких (более "стандартных") средств нет, то конечно будем делать так... но "осень ни хоца" ©

> DeadMeat   (07.10.08 10:32) [39]


В случае когда сервис реализует COM-сервер, IDE в части регистрации COM-сервера идет лесом - регистрация сервера в ROT происходит в ран-тайм.

> Сергей М. ©   (07.10.08 11:03) [40]

Другими словами, таки все делать ручками?

> все делать ручками?


Делать что ?
О регистрации чего в дан.случае ты ведешь речь ?

> Сергей М. ©   (07.10.08 11:11) [42]

Я про регистрацию COM сервера в службе.
Если я правильно (надеюсь хоть в этот раз) понял, то IDE предоставляет возможности для:
1. создания полноценной службы
2. создания полноценного COM сервера
А вот спаривать одно с другим надо уже самому. Так?

> спаривать одно с другим надо уже самому. Так?
>


Именно.

И статья с примером от Набережных С. (С) это недвусмысленно и на огурцах демонстрирует.

Мало еще какие выкрутасы могут существовать, которые Борланд не мог предусмотреть (или не посчитал нужным, дабы не потакать дурацким прихотям всяк входящего), разрабатывая свое IDE !)

> [44] Сергей М. ©   (07.10.08 20:38)

Ясно... понял. Еще раз благодарю за инфу.