Problema com GUID do Servidor de Aplicação
Estou desenvolvendo um sistema em 3 camadas com dbExpress+MySQL, meu servidor já está funcionando, porém na aplicação do cliente o TSocketConnection ainda naum está reconhecendo o servidor de aplicação (naum acha o GUID aquele numerozinho de identificação global e mais frescuras...).
Jah registei o servidor das duas maneiras q sei, run/parameters coloquei /RegServer e pelo prompt... outra o scksvr.exe está sendo executado.
Naum sei mais o q fazer... alguma sugestão? ou eskeci de algo :roll: ???
Obrigada
Jah registei o servidor das duas maneiras q sei, run/parameters coloquei /RegServer e pelo prompt... outra o scksvr.exe está sendo executado.
Naum sei mais o q fazer... alguma sugestão? ou eskeci de algo :roll: ???
Obrigada
Fer_nanda
Curtidas 0
Respostas
Denis
13/04/2004
Oi Fernanda,
Vc. não precisa configurar aquele número Guid. Faça o sequinte. Deixe o programa scktsrvr.exe executando em uma máquina. Depois execute o programa servidor, pelo menos uma vez. Ele se encarrega de fazer as alterações em registros que forem necessárias.
Depois, dentro do próprio programa cliente, configure o componente SocketConnection para acessar aquela máquina onde esta a aplicação servidora rodando. Apenas preencha o nr do IP na propriedade address, depois selecione server name. Irá aparecer a sua conexão remota. Onde tem serverGuid, apague o que tiver. Para evitar problemas. E depois é só criar os clientDatasets.
Vc. não precisa configurar aquele número Guid. Faça o sequinte. Deixe o programa scktsrvr.exe executando em uma máquina. Depois execute o programa servidor, pelo menos uma vez. Ele se encarrega de fazer as alterações em registros que forem necessárias.
Depois, dentro do próprio programa cliente, configure o componente SocketConnection para acessar aquela máquina onde esta a aplicação servidora rodando. Apenas preencha o nr do IP na propriedade address, depois selecione server name. Irá aparecer a sua conexão remota. Onde tem serverGuid, apague o que tiver. Para evitar problemas. E depois é só criar os clientDatasets.
GOSTEI 0
Fer_nanda
13/04/2004
Oi Denis, obrigada pela ajuda.
Na verdade o problema naum era esse... o q gerou isso foi o fato de eu ter criado o remote data module com as propriedades Instancing: MultipleInstance e ThreadingModel: free.
Tinha a informação que esse último seria indicado para as chamadas por threads de uma única vez, e que o Apartment seria indicado para o tratamento de todas as chamadas do rdm, qdo se utiliza BDE, o q naum é meu caso.
Bom se souber, gostaria de ter esses modelos de comunicação esclarecidos.
obrigada novamente
Na verdade o problema naum era esse... o q gerou isso foi o fato de eu ter criado o remote data module com as propriedades Instancing: MultipleInstance e ThreadingModel: free.
Tinha a informação que esse último seria indicado para as chamadas por threads de uma única vez, e que o Apartment seria indicado para o tratamento de todas as chamadas do rdm, qdo se utiliza BDE, o q naum é meu caso.
Bom se souber, gostaria de ter esses modelos de comunicação esclarecidos.
obrigada novamente
GOSTEI 0
Fer_nanda
13/04/2004
O problema já está resolvido... é só titulo de curiosidade.
valeu
valeu
GOSTEI 0
Leandro_si
13/04/2004
Fernanda,
Multiple Instance : Instancing - isso fará que uma nova instância do objeto seja criada para cada aplicação cliente.
Threading Model : Apartment - cada objeto COM é executado dentro de seu próprio thread.
espero ter ajudado!
Leandro Silveira
leandro_si@ibest.com.br
FreeLancer
Multiple Instance : Instancing - isso fará que uma nova instância do objeto seja criada para cada aplicação cliente.
Threading Model : Apartment - cada objeto COM é executado dentro de seu próprio thread.
espero ter ajudado!
Leandro Silveira
leandro_si@ibest.com.br
FreeLancer
GOSTEI 0
Fer_nanda
13/04/2004
Fernanda,
Multiple Instance : Instancing - isso fará que uma nova instância do objeto seja criada para cada aplicação cliente.
Threading Model : Apartment - cada objeto COM é executado dentro de seu próprio thread.
espero ter ajudado!
Leandro Silveira
leandro_si@ibest.com.br
FreeLancer
Olah Leandro, obrigada pela resposta.
Vc tem algum exemplo prático utilizando o Threading Model : Apartment? tipo...qdo é interessante usá-lo, em q situação entende? pq?
obrigada
GOSTEI 0
Rômulo Barros
13/04/2004
Olá pessoal... Em 3 camadas, gosto de trabalhar com o componente DCOMConnection. Mas, entre outras coisas, pq trabalhamos com dcomconnection, sockets ... .. ... .. se poderemos trabalhar com SOAP?
Já que o SOAP chegou, vcs acham que deveremos abandonar as tecnologias citadas anteriormente?
Já que o SOAP chegou, vcs acham que deveremos abandonar as tecnologias citadas anteriormente?
GOSTEI 0
Romulocpd
13/04/2004
Fernanda,
Multiple Instance : Instancing - isso fará que uma nova instância do objeto seja criada para cada aplicação cliente.
Threading Model : Apartment - cada objeto COM é executado dentro de seu próprio thread.
Olá Leandro,
Se eu usar o Instancing como Single Instance ele irá gerenciar corretamente a execução das queries? Por exemplo se tenho uma stored que retorna o proximo codigo de cliente, ela irá cuidar do pool de solicitações corretamente?
Ou será que o Multiple Instance é a melhor opção?
Obrigado
Romulo
GOSTEI 0
Brunolspp
13/04/2004
Salve Galera!!!
Algumas dicas sobre as arquitetura DCOM, SOAP e BSS(Borland Socket Server - scktsrvr.exe)
O DCOM é legal, porem da muitos problemas de incompatibilidades e dificil distribuição e inviavel para aplicações geograficas, tem otimos recursos, porem da mta dor de cabeça pra distribuição e manutenção.
O SOAP, originalmente se destina a aplicações de interfaces, principalmente para sistemas hetereogeneos, e de facil desenvolvimento e distribuição, mas peca mto em performance, escalabilidade e segurança. Porem atende a alguns niveis de requisiç~eos e aplicação.
O BSS e o melhro deles, e o mais rapido, estavel e se aplica a distribuições via internet, intranet extranet e td q funciona com ip, facil de distribuir e desenvolver, mais escalavel tb. Tenho varias aplicações de risco funcionando nessa arquitetura.
Com relação a thread models, em se tratando de BSS, o melhor e usar multiple instances com threading model single, e a forma mais rapido e segura. O uso de shareds no cliente tb e crucial.
Mais exemplos com codigo fonte, slides e td mais vcs encontram em:
http://cc.borland.com/Author.aspx?ID=795118
tb tem um grupo de discução somente deste assunto: nddv@yahoogrupos.com.br
e neste mes na reuniao do DUG-SP vamso apresentar um workshop de desenvolvimento multicamadas com BSS e interfaces IntraWeb e Win32.
E no mais estou as ordens para o que precisarem.
Algumas dicas sobre as arquitetura DCOM, SOAP e BSS(Borland Socket Server - scktsrvr.exe)
O DCOM é legal, porem da muitos problemas de incompatibilidades e dificil distribuição e inviavel para aplicações geograficas, tem otimos recursos, porem da mta dor de cabeça pra distribuição e manutenção.
O SOAP, originalmente se destina a aplicações de interfaces, principalmente para sistemas hetereogeneos, e de facil desenvolvimento e distribuição, mas peca mto em performance, escalabilidade e segurança. Porem atende a alguns niveis de requisiç~eos e aplicação.
O BSS e o melhro deles, e o mais rapido, estavel e se aplica a distribuições via internet, intranet extranet e td q funciona com ip, facil de distribuir e desenvolver, mais escalavel tb. Tenho varias aplicações de risco funcionando nessa arquitetura.
Com relação a thread models, em se tratando de BSS, o melhor e usar multiple instances com threading model single, e a forma mais rapido e segura. O uso de shareds no cliente tb e crucial.
Mais exemplos com codigo fonte, slides e td mais vcs encontram em:
http://cc.borland.com/Author.aspx?ID=795118
tb tem um grupo de discução somente deste assunto: nddv@yahoogrupos.com.br
e neste mes na reuniao do DUG-SP vamso apresentar um workshop de desenvolvimento multicamadas com BSS e interfaces IntraWeb e Win32.
E no mais estou as ordens para o que precisarem.
GOSTEI 0