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


При штатной регистрации в реестре должны фигурировать как минимум 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 не предоставляет подобных инструментов или визардов (нет нет.. я не избалованный батонокидатель)..
Но если таких (более "стандартных") средств нет, то конечно будем делать так... но "осень ни хоца" ©