Página 2 de 4
Enviado: 07 Mai 2007 09:46
por momente
Amigos Maligno e Leonardo,
Obrigado pela ajuda!
Eu me interessei em saber realmente oque seria este emulador de terminais pelo fato do Vagner ter relacionado com dbfs. Assunto inicial desta thread.
Valeu!
:)Pos
Enviado: 07 Mai 2007 15:38
por alaminojunior
Olá caros colegas, estivemos fazendo alguns testes com xHarbour x MySQL 5.
Aqueles exemplos que estão na pasta \contrib...
Conseguimos fazer funcionar aquele DBF2MYSQL.EXE. Ele transporta os dados belezinha !!!
Porém ao rodar o TSTMYSQL.exe, dá erro. "O tstmysql.exe encontrou um problema e precisa ser fechado"
Por acaso precisaria do Mediator para o sistema interagir com o Mysql ?
Caso sim , porque consigo transportar dados de um DBF para o Mysql ?
Se alguem puder dar uma luz, agradeço
Enviado: 08 Mai 2007 14:25
por Luiz
alaminojunior escreveu:Por acaso precisaria do Mediator para o sistema interagir com o Mysql ?
Caso sim , porque consigo transportar dados de um DBF para o Mysql ?
Se alguem puder dar uma luz, agradeço
Não é preciso usar nada extra (pelo menos se for trabalhar com querys)
Como nesse exemplo simples:
Código: Selecionar todos
// conectar ao servidor
oServer := TMySQLServer():New('localhost', 'root', '<senha>')
// verificar erro
if oServer:NetErr()
alert(oServer:Error())
endif
// realizar a consulta
oResult:=oServer:Query("show databases")
// verificar erro
if oResult:NetErr()
alert(oResult:Error())
endif
// exibir resultados
for f:=0 to oResult:RecCount()
? oResult:Database
oResult:Skip()
next
wait
Enviado: 09 Mai 2007 04:25
por Stanis Luksys
Olá...
Realmente... Eu vinha observando este tópico e estava esperando que alguém realmente falasse as diferenças de verdade, porque velocidade de atualização nos dados e consultas não é tudo, é apenas uma parte do que um banco de dados deve oferecer...
O que o Maligno falou, desta vez devo concordar... Eu sinceramente mesmo acho que este nem é assunto pra tanta discussão. O DBF é bom, é legal, é rapidinho e tudo mais, mas é pobre. Se o sistema não utiliza recursos muito avançados, ele suporta bem, nem é necessário migrar. Imagina o carinha aqui da farmácia da esquina usando um programinha clipper 5.2, pra que BD relacional????
Agora se o sistema é de grande porte mesmo, nem tem como passar pela cabeça de quem desenvolve, trabalhar em cima de dbf. Os SGBDs em geral oferecem os recursos que foram mencionados e que no DBF vc deve sempre tratar via sistema, nunca diretamente prevendo uma alteração em uma tabela, como uma trigger por exemplo.
Para exemplificar uma trigger, seria como se alguem alterasse seu DBF pelo DBU e ele (o DBF, não o DBU) soubesse que antes de fazer esta alteração ele deve executar uma rotina que você escreveu. Isso traz muita segurança e consistência nos seus dados.
Infelizmente é assim... Ja ouvi dizer de um tal SuperDBF, e sabe... Nem sequer fui atrás...
O lance é pegar uma apostilinha de SQL, acho q é a linguagem mais facil que existe. Ai é só aproveitar.
Agora se o sistema não tá nem perto de pedir arrego e já está em estágio "final", trocar pra que?
Falou ae galerinha!! hehe
Enviado: 09 Mai 2007 08:17
por Maligno
Stanis Luksys escreveu:Imagina o carinha aqui da farmácia da esquina usando um programinha clipper 5.2, pra que BD relacional????
Mesmo no carinha da farmácia da esquina, se eu usasse xHarbour, passaria longe dos DBFs. Até porque, conforme já comentei, em rede você pode usar um servidor de banco de dados e sendo monousuário a versão embutida (o Firebird tem - se não me engano o MySQL também), com uma simples DLL que faz o mesmo que o servidor faz. O usuário nem vai saber de nada. O que importa é a extensa lista de benefícios que o uso que os SGBDs oferecem. Por isso, mesmo que um DBF seja mais rápido, mesmo que seja mais simples e fácil, ainda prefiro um banco de dados como o Firebird. Se você já trocou para 32 bits na aplicação, pra que estagnar em DBF? Além do que, tem o lado prático. Hoje você vendeu para uma farmácia pequena. Se vender amanhã para uma grande rede, a aplicação será rigorosamente a mesma.
Infelizmente é assim... Ja ouvi dizer de um tal SuperDBF, e sabe... Nem sequer fui atrás...
Eu também não iria.
))
[]'s
Maligno
http://www.buzinello.com/prg
Enviado: 10 Mai 2007 11:34
por vagucs
O que torna o DBF muito mais eficiente, é, justamente, a emulação de terminal.
Como tudo vai ser processado no servidor, então seria como um acesso local.
Todo banco relacional trabalha via Sockets, mas foi bem lembrado pelo Maligno que o firebird tem DLL para acesso direto, o que dispensa isto, e não sabia que o MySQL tambem tem isto.
Bom é que andamos na mesma direção.
Acho que se uma empresa precisa da alta tecnologia de um banco relacional, meu voto ainda é para postgres, a grande vantagem dos STORED PROCEDURES é que você pode por exemplo validar a inclusão de CLIENTES e a mesma rotina seria valida até por inclusões feitas por outros meios, WEB, Acesso por gerenciador, isto é interessante, pois em si parte do programa está no banco de dados, você pode até fazer todo o processamento nele, fazendo com que seu sistema praticamente vire um FRONTEND. Dai uma das grandes vantagens do xHarbour, que você pode ter o mesmo sistema rodando em qualquer base de dados e dando ao seu cliente a opção de escolha.
Mas digo que, para quem está migrando recente, avalie a real necessidade do seu cliente. Já vi pessoas colocarem Banco relacional para num futuro proximo usarem suas "vantagens" o que nunca ocorreu, ou seja, se você agir dentro da real necessidade, terá um sistema mais acessível e com menos dor de cabeça para os clientes.
Um sistema bem programa, rodando em um servidor Linux com emulação de terminal em um servidor normal P4 3.4 2 Gb de rama e HD a escolha, segura 100 terminais em media com otimo desempenho, não vou falar que segura mais pois nunca vi ninguem usando.
Tenho um cliente em SP que tem filial na china, o pessoal entra remoto e tira pedidos direto no sistema em SP, e isto tudo usando DBF mesmo.
Não colocaram banco relacional pois nunca tiveram problemas com DBF e NTX nos ultimos 2 anos rodando o sistema com emulação de terminal.
Emulação de terminal como já citado, acontece de forma muito simples, você pode fazer um teste escolhendo uma distribuição Linux do seu agrado, indico aos amigos o uso do Centos que o mesmo REDHAT mas sem os pacotes que estão fora da GPL ou são pagos, você apenas instala o Linux e o SSH já estará ativo, compile seu programa e use o putty para acessar o servidor de maquinas Windows, você vai cair na linha de comando do Linux, mas pode fazer um script que ao usuario logar ir direto para seu sistema, rode o programa e pronto, você vai ter um tráfego minimo de tela e teclado, isto em modo texto, pois as telas no Linux para cada atualização tem meros 8k, ai se for necessário alguma otimização para aproveitar melhor e distribuir melhor os recursos do servidor, ai é com você.
Enviado: 10 Mai 2007 11:39
por vagucs
Há, tem umc lietne meu aqui em minha cidade mesmo, que tem um servidor Linux conectiva 10 com o programa que eu montei rodando com emulação de terminal.
O servidor é um Athlon 1.200 com 512 megas de RAM e HD 80 IDE 7200 RPM, 2 anos e meio rodando, nunca corrompeu indices, segura 20 terminais atoa, e olha que ele que nao precisou colocar mais, mas o sistema nao abre o bico, posso dizer que ele conseguirá pendurar uns 40 terminais com este servidor, a quantidade de memoria ocupada e HD e tempo de CPU é muito baixo, arrisco e posso cometer o erro de dizer que esta maquina segura bem mais de 40 terminais, mas sem ter como testar para ter certeza prefiro não garantir, mas que eu acho que segura, a segura viu... kakakakkaa
Enviado: 19 Abr 2008 08:33
por joserubenildosilva
Ola! Eu gostaria de saber mais sobre o uso do MYSQL. meu msn eh
rubenil@hotmail.com. Tenho um sistema em DBF compilado com xharbour.
mas todo dia tenho que indexar a base. todo dia
Enviado: 19 Abr 2008 15:38
por vagucs
Maligno.
Se usar as classes MySQL mesmo localmente, o trafego continua sendo via Socket, diferente do firebird, que tem rotinas para acesso direto.
Enviado: 20 Abr 2008 01:30
por fladimir
Tenho a mesma dificuldade, oriento os clientes ou faço um BAT q ao LIGAR o Servidor ele apaga os CDX e ao entrar na primeira estacao CRIA os Indices novamente, mas queria saber se tem como não ter q indexar TODO DIA, se deixo SEM executar esse procedimento com o tempo e dependendo o movimento o sistema torna-se instavel em um pouco tempo, agora se fizer todo dia a INDEXAÇÂO não tem problemas...., já vi sistemas por ai q tem muito movimento e não fica indexando constantemente e sim esporadimente tipo qdo troca a versão 1 vez por mês e olhe lá.... ALGUÉM SABE O CAMINHO DAS PEDRAS ?
Grato
Enviado: 20 Abr 2008 09:11
por vagucs
Tenho clientes que rodaram mais de 2 anos sem precisar reindexar com emulação de terminal, reindexei apenas por que mudei alguns campos no DBF.
Mesmo antes, quando estava em clipper problemas de corrupção de indices não eram comuns, sempre ficavamos uma media de 6 meses sem reindexar, apenas quando tinha manutenção quie precisava mesmo disto, que nos faziamos. Usava antes NTX com a SIX e depois com xHarbour.,
Enviado: 20 Abr 2008 17:10
por edmarfrazao
eu eustou usando xharbour +dbf+hwgui e estou adotando o Terminal Service(TS) com windows.
uns estão usando 2003 server com TS, mas custa +- 5.000,00 para 10 usuarios.
outros estão usando o xpunlimited(
www.xpunlimited.com), custa 350,00 para 10 usuarios e roda no xp ou vista
outros estou instalando a versão free(roda em 03 usuários).
o TS é excelente, não tem queda da estação, pois funciona tudo no servidor
nada de reindexar
o terminal pode ser linux ou Thing Client
Pode acessar via internet
pode usar o navegador web.
e tudo fica com antes no xharbour/clipper
Enviado: 21 Abr 2008 14:55
por TerraSoftware
Windows Xp roda terminal server para muitos usuários, basta saber configurar e ter as dlls certas.
Enviado: 21 Abr 2008 15:33
por janio
TerraSoftware escreveu:Windows Xp roda terminal server para muitos usuários, basta saber configurar e ter as dlls certas.
Pois mostre o caminho das pedras...
Jânio
Enviado: 22 Abr 2008 08:11
por TerraSoftware
Lá vai:
O Windows XP SP2 não permite que você tenha mais de uma sessão aberta, seja ela local ou remota. Isto significa que, se um usuário estiver conectado localmente e o usuário remoto tentar se conectar ele automaticamente e sem avisar, trava a tela do usuário local e libera uma conexão para o usuário remoto. Nas versões do XP anteriores ao SP2 era possível abrir mais de uma sessão, portanto, é usando alguns arquivos das versões anteriores que vamos conseguir habilitar este recurso novamente e assim você poderá fazer quantas conexões remotas quiser ao mesmo tempo.
Entre outras coisas é necessário ter o arquivo "termsrv.dll"
IMPORTANTE: Ter esta informação não significa necessariamente que eu faça isso e nem que eu tenha os arquivos em questão.
Certamente o google poderá ajudar muito.