Fórum Apollo server alguem usa? #267456

se vc. estiver querendo usar para que a sua aplicação acesse tabelas DBF no clipper e no delphi ao mesmo tempo não precisa de nenhum componente.
No clipper use a RDD que ativa os indices NDX do dbase, ao invés de NTX.
E no delphi eles (os indices NDX ) são abertos normalmente com o componente Ttable. Apenas fique atento com a opção manteined para que ela esteja como true quando abrir os indices pelo delphi.

Eu ja uso o clipper com indeces nsx e o delphi com apollo vcl funciona perfeitamente.

usar indices ntx( sao grandes e lentos )



A duvida e se alguem ja usar a versao server do apollo, para me dar referencia.

Ola Edmarfrazao,

Infelizmente tb não sei responder sua pergunta... Mas fiquei interessado no Apollo...

Sabe se ele trabalha bem com DBF/CDX (FoxPro). O Delphi corrompe os CDX do Clipper... e usar NTX denovo nem pensar... ;-)

Tem o link da página do Apollo ?

Ola pessoal

Tinhamos um sistema em clipper/Fivewin que utilizava dbf/cdx. Durante o desenvolvimento de um novo sistema agora em Delphi, tivemos uma fase em que alguns modulos estavam em clipper e outros em delphi utilizando exatamente a mesma base de dados. Para isso utilizamos essa bibliote Apollo que trabalha muito bem com esse formato FoxPro (dbf/cdx).
Isso funcionou perfeitamente, durante a migracao para o Delphi e mesmo depois de concluido utilizamos ainda por um bom tempo essa biblioteca. Comecamos a ter problema quando buscamos uma solucao mais robusta cliente/servidor. Testamos o Apollo server (para 2 usuario é free) e nao conseguimos bom resultado. Os tempos eram pessimos; tinhamos resultados diferentes quando rodava com o server e sem o server. Resumindo, nao conseguimos bom resultado e abandonamos essa solucao.
Optamos entao pela biblioteca ADS, cuja filosofia é semelhante : é possivel utilizar um ´servidor local´ ou um ´cliente/servidor´, ambos no formato dbf/cdx, com o mesmo codigo, somente mudando uma configuracao. Fizemos varios testes e a solucao é excelente. Ja temos isso rodando em todos os nossos clientes sendo a maioria com o servidor local (conceitualmente igual ao clipper, access, foxpro, etc...) e alguns com o cliente/servidor.
O servidor local é free. Nao tem custo nem para o desenvolvedor nem para o cliente. Tem uma limitacao de 35 usuarios concorrentes. O cliente/servidor tem que ser licenciado para cada cliente. Diferente do Apollo nao é possivel comprar uma licenca e distribuir para os nossos clientes. E nao é barato. Porem é excelente, valendo cada centavo.
Se alguem precisar de mais algum detalhe, estou a disposicao.
Um abraco a todos,
Fabio

A duvida foi esta mesmo , em alguns teste a versao de 02 usuariio, e mais rapido usando o local do que o servidor.


Voce sabe o custo do ADS server?


Sei que o ADS local e free, inclusive suportado pelo projeto xharbour(copilador compativel com clipper).

Complementando a mensagem anterior, vale informar que o Apollo VCL cumpriu bem o seu papel, sem nenhum problema. Só que a solucao ADS é realmente mais robusta. Em testes que fizemos em um cliente que faz 2.000 (dois mil) pagamentos por dia, via arquivo remessa do banco, e que portanto tem tabelas com 350.000 que sao manipuladas diaria e constantemente, com consultas e relatorios o ganho com o client/server é brutal. Em uma avaliacao da pior situacao que sao consulta por valores, nao indexados, no Apollo demorava por volta de 10 MINUTOS; no ADS local, que já é mais eficiente que o Apollo isso variava entre 5 e 8 MINUTOS; no client/server, que foi instalado nessa empresa, essa mesma consulta demora nao mais que 8 SEGUNDOS. O ganho aqui se dar por dois motivos basicos : 1) pela filosofia de trabalho client/server que obviamente é mais eficiente; 2) pelo amadurecimento da ferramenta, que comparado com o Apollo mostrou-se muito melhor.
O custo dessa maravilha, em dolar, é que nao e muito facil de repassar para os clientes. O licenciamento é feito pelo numero de usuario :
5 usuarios : US$ 888,00
10 usuarios : US$ 1.668,00
15 usuarios : US$ 2.556,00
25 usuarios : US$ 3.594,00 e assim por diante.

Um abraco,

Fabio

Ola Fabio,

Muito obrigado pelas explicações... Garanto que tem vários Clippeiros por aqui (assim como eu) que se beneficiarão muito com essas informações...

É dificil substituir um sistema que já está funcionando bem... entretanto o DBF puro tem limites que restringem o Clipper a pequenos negócios, pois não comporta grande volume de dados... Sem falar que a interface DOS está marginalizada...

O ADS, pode porporcionar uma transiçao mais tranquila de versão... e pelo que vi no site, é possivel adotar o ADS ainda no Clipper usando RDD...

Também estive pensando em migrar meu sistema Clipper para Linux usando (FlagShip ou xHarbour) e rodar todo o programa por SSH/Telnet. A soluçao pode ser mais barata, pois não depende de um Servidor Licenciado.. Visitei uma industria com 60 terminais que adotou essa soluçao e fiquei bem impressionado... O tempo de resposta é incrivel, pois roda tudo no servidor, dá pra por os 486 antigos para trabalhar, com boa performance, pois só há transito de telas e teclado... Dá pra continuar com o DBF, sem risco de corrupçao de indices/dados e com a possibilidade de grande volume de arquivos...

Ola Daniel,
Nosso sistema tambem estava em clipper e funcionou perfeitamente bem por longos anos. Mas chegou uma hora que os clientes nao queriam mais. E olha que nós esticamos essa hora. Num primeiro instante, perdemos quase um ano batendo cabeca com Delphi( na epoca versao 2), V.O. ( nao gosto nem de lembrar), V.B. (nao me lembro a versao mais parava ate o elevador do predio quando rodava o sistema piloto que desenvolvemos). Aí descobrimos o FiveWin. Em pouquissimo tempo passamos todo nosso sistema (sao 10 modulos) para o ambiente Windows, porem ainda compilando com o Clipper e dbf/cdx. Funcionou perfeitamente, porem tinhamos claramente que seria uma situacao transitoria. A grande vantagem disso é entender o funcionamento do Windows, forms, resource, etc... Nessa ferramenta o trabalho é mais simples porem mais braçal.
Quando resolvemos passar para Windows efetivamente, testamos novamente Delphi, VB e C++ builder. Nao tivemos muitas duvidas que o Delphi seria a melhor opcao. Isso foi a quatro anos. Ficamos 2 anos só desenvolvendo e ai nao tem choro; nao tem aproveitamento do anterior a nao ser a experiencia do negocio. E ja estamos a quase dois com a versao delphi nao rua.

Agora os clientes nao querem mais DBF. Mesmo quem nao tem a menor ideia do que é isso exatamente, quer uma coisa mais moderninha como Access por exemplo (ja ouvi isso mais de uma vez de cliente).
Sendo assim e tambem porque realmente ja estamos buscando uma alternativa mais robusta, é que trocamos pelo ADS. Ele nos permite que num primeiro instante utilizassemos o servidor local e o client/server. Esta fase ja esta consolidada. É importante ressaltar que ja nessa fase estamos trabalhando somente com componentes Tdataset, sendo totalmente compativel com ansi92 podendo utilizar comandos sql (select, create table, etc...). Com isso ja estamos nos preparando para um novo banco, ainda em avaliacao. O proprio ADS tem um formato proprio, para o qual estamos migrando, muito mais robusto que o dbf, com o qual nao é mais compativel. Com isso vamos conseguir sair do dbf, mas sempre, como dizemos aqui na empresa, fazendo a manutencao do aviao em pleno voo, visto que tudo isso tem que ser totalmente (ou quase) transparente para os usuarios.

Um abraco,

Fabio

Apenas mencionei esta maneira por ser nativa do Delphi. E tbm utilizo assim sem problema algum. Outro detalhe. A biblioteca apollo é paga ( pelo que sei até hoje). Claro que é muito boa mas é um investimento. O interessante era mesmo migrar para um SGBD ( interbase, firebird, mysql, oracle, etc...).
E nos dias de hoje uma economiazinha sempre é bem vinda....
Mas se quiser investir vai em frente....

Ola Fabio,

Mais uma vez muito obrigado por compartilhar sua experiencia conosco...

Também cheguei a ver uma demonstraçao do V.O. Mas o produto era horrivel, então me decidi por Delphi... (na epoca versao 3)

Mas somente com a versao 7, comecei a migraçao para valer... Sabe como é... sempre há solicitaçoes a atender, ou mudanças na legislação...

Como vc falou estou aproveitando somente a ´ideia´... o sistema está sendo todo re-escrito, usando o FB como BD...

Como disse antes, cheguei a cogitar a migraçao do Clipper para Linux e usar SSH, mas parei, porque meu sistema depende muito de periféricos de Automaçao Comercial, como ECF´s, Scanner, Gavetas, etc.... e via SSH não tem como interagir com esses equipamentos, pois o programa roda no Servidor e os periféricos estão plugados no Terminal...

Meus clientes atuais gostam do sistema, e fazem pouca pressao para mudança de plataforma... mas os clientes novos... É sempre a mesma pergunta: ´É for Windows ?´ :-) Acredito que até o meio desse ano, concluiremos a migraçao...