Swing na rede local

Olá

Não faça isto em hipótese alguma. ODBC é horrível e matará sua aplicação. Simplesmente use o modo normal de fazer isto em Java criando conexões com o bando de dados.

pedromuyala:

:?: Então tenho a seguinte pergunta:
Agora quanto ao software (os class), como vou fazer? Preciso colocá-los em cada máquina ou somente na máquina 3 (G:) e chamo ele pela rede mesmo?

Instale os jars em cada máquina.

MVC? Explique melhor sua dúvida.

[]s
Luca

Olá Luca,

OK. Mas como a máquina 1 (E:) e máquina 2 (F:) vão conseguir acessar o Postgree que está instalado na máquina 3 (G:) sem usar o ODBC?

Mesmo instalando o jar em cada máquina eles vão acessar o banco de dados que está em outra máquina?

Luca:

MVC? Explique melhor sua dúvida.
Luca

Tente imaginar a seguinte situação:

1. Existe um usuário na máquina 1 (E:) que consulta um cliente X. Ele deixa a consulta lá aberta na tela (mostra visão de X).
2. Existe um usuário na máquina 2 (F:) que realiza alterações do mesmo cliente que está lá aparecendo na tela da máquina 1, o cliente X (altera modelo de X).
3. O correto é que assim que for atualizado o cliente X na máquina 2 (F:) imediatamente a visão do cliente X na máquina 1 (E:) seja notificado da alteração para reenderizar e tornar a visão consistente.

Então, mesmo colocando o jar em cada máquina (1,2 e 3) se ocorrer a situação acima o fluxo que citei vai acontecer ou não?

Se não entender, já peço desculpa antecipadamente :oops: mas eu vou tentando expor o problema até ficar visível!
É que sou iniciante em Java tenho muitas dificuldades. Agradeço a atenção Luca, obrigado por estar aqui no tópico!

Olá

pedromuyala:

…Mas como a máquina 1 (E:) e máquina 2 (F:) vão conseguir acessar o Postgree que está instalado na máquina 3 (G:) sem usar o ODBC?..
Mesmo instalando o jar em cada máquina eles vão acessar o banco de dados que está em outra máquina?

Sim, normalmente. É assim que se faz em Java. A conexão é feita direto na máquina onde está a base de dados. Veja a qualquer tutorial de JDBC. NUNCA se usa ODBC em Java.

pedromuyala:

…
O jar (sistema) trabalha usando MVC. É um programinha que cadastra, altera, exclui e consulta clientes.

Tente imaginar a seguinte situação:

1. Existe um usuário na máquina 1 (E:) que consulta um cliente X. Ele deixa a consulta lá aberta na tela (mostra visão de X).
2. Existe um usuário na máquina 2 (F:) que realiza alterações do mesmo cliente que está lá aparecendo na tela da máquina 1, o cliente X (altera modelo de X).
3. O correto é que assim que for atualizado o cliente X na máquina 2 (F:) imediatamente a visão do cliente X na máquina 1 (E:) seja notificado da alteração para reenderizar e tornar a visão consistente.

Então, mesmo colocando o jar em cada máquina (1,2 e 3) se ocorrer a situação acima o fluxo que citei vai acontecer ou não?

Não é bem assim que se costuma trabalhar. Há vários modos considerados “normais”. Um deles considerado otimista é deixar que os 2 clientes tentem a atualização e só se efetiva uma delas. Mas existem vários modos de trabalhar e quando você aprender mais sobre JDBC chegará a conclusão qual será o mais adequado para a sua aplicação.

O modo como descreveu é possível de ser implantado mas se 2 máquinas abrirem a mesma ficha de cadastro no modo de alteração, quando a máquina 1 receber a notificação de que os dados na base foram alterados, se perderão os dados que o usuário digitou do mesmo jeito que se perdem quando a alteração não for possível porque outro atravessou seu caminho.

Sugiro ler algum tutorial de JDBC mas quando for escrever sua aplicação considere a hipótese de usar o Hibernate (mais uma coisa para aprender)

[]s
Luca

Olá Luca,

Luca:

pedromuyala:

…
O jar (sistema) trabalha usando MVC. É um programinha que cadastra, altera, exclui e consulta clientes.

Tente imaginar a seguinte situação:

1. Existe um usuário na máquina 1 (E:) que consulta um cliente X. Ele deixa a consulta lá aberta na tela (mostra visão de X).
2. Existe um usuário na máquina 2 (F:) que realiza alterações do mesmo cliente que está lá aparecendo na tela da máquina 1, o cliente X (altera modelo de X).
3. O correto é que assim que for atualizado o cliente X na máquina 2 (F:) imediatamente a visão do cliente X na máquina 1 (E:) seja notificado da alteração para reenderizar e tornar a visão consistente.

Então, mesmo colocando o jar em cada máquina (1,2 e 3) se ocorrer a situação acima o fluxo que citei vai acontecer ou não?

Não é bem assim que se costuma trabalhar. Há vários modos considerados “normais”. Um deles considerado otimista é deixar que os 2 clientes tentem a atualização e só se efetiva uma delas. Mas existem vários modos de trabalhar e quando você aprender mais sobre JDBC chegará a conclusão qual será o mais adequado para a sua aplicação.

O modo como descreveu é possível de ser implantado mas se 2 máquinas abrirem a mesma ficha de cadastro no modo de alteração, quando a máquina 1 receber a notificação de que os dados na base foram alterados, se perderão os dados que o usuário digitou do mesmo jeito que se perdem quando a alteração não for possível porque outro atravessou seu caminho.

Sugiro ler algum tutorial de JDBC mas quando for escrever sua aplicação considere a hipótese de usar o Hibernate (mais uma coisa para aprender)

[]s
Luca

Ah sim concordo plenamente. Mas e se for só uma tela de consulta em uma máquina e editável em outra máquina?
Acredito que a máquina que alterar os dados deverá notificar as máquinas que tem a consulta sobre aqueles dados que eles se tornaram inconsistentes. Acredito eu, não sei!

Digo isso porque um tempo trabalhei com um banco de dados DBase (.DBF) e lembro que o programa que mostrava o banco tinha esse recurso, ou seja, se uma máquina está com a tabela em aberto e uma outra alterar aquela tabela imediatamente todas as visões NÃO-EDITÁVEIS erão avisadas da inconsistencia. Foi daí que tiri a idéia que os programas em JAVA deveriam também trabalhar nessa complexidade.

Abração Luca, valew por estar aqui! [color=red]Obrigado![/color]

Olá

pedromuyala:

…e se for só uma tela de consulta em uma máquina e editável em outra máquina?
Acredito que a máquina que alterar os dados deverá notificar as máquinas que tem a consulta sobre aqueles dados que eles se tornaram inconsistentes.

Sua tela de consulta pode ser avisada da alteração se você escrever código para isto. Com programas xBase usando tabelas .dbf isto não era automático, a gente tinha que escrever código que fazia isto. A única diferença é que com Java é relativamente mais fácil.

[]s
Luca

Ou seja, o que eu via no xBase na verdade era uma especie de thred() que de tempo em tempo atualizava a visão?
Ou o programa que mostrava o banco de dados tinha uma arquitetura MVC?

Lembro que era mais ou menos isso: Pegando a imagem anexa no primeiro post, o banco de dados (os DBF’s) estavam na máquina G: e o programa que consultava esses dbf’s (o DBU) era instalado em todas as máquinas (no caso E:\ e F:). Se E:\ estava mostrando o conteúdo de cliente.dbf e F:\ alterasse o conteúdo de cliente.dbf, imediatamente E:\ atualizava a visão que F:\ alterou. Já se o campo a ser alterado estava sendo editado em E:\ e F:\ tentasse alterar, um erro era mostrado em F:.

[color=red]Obrigado Luca![/color]

Olá

1. MVC não é isto. Estude também o que se considera MVC no Swing (que é diferente de MVC em aplicações web)

2. O que você diz… [color=darkblue]… Lembro que era mais ou menos isso…[/color] … não era assim. Quem atualizava precisava avisar quem estava consultando ou quem estava consultando precisava ler o registro atualizado na tabela .dbf

[]s
Luca

Tem alguma sugestão de material legal? :idea:

O que acontecia, agora falando com certeza é o seguinte: Se eu tenho a tabela Clientes.dbf aberta em várias máquinas e em uma delas eu atualizo, insiro ou excluo um registro, todas as outras máquinas imediatamente se atualizam. E o visualizador de tabelas (DBU) é instalado individualmente em cada máquina porém o dbf está sempre em uma única máquina que é de onde todas as máquinas coletam e mostram os dados dela.

Isso que eu queria implementar em programas JAVA. Mas não sei como.
Valew Luca, [color=red]abração![/color]

Olá

Qualquer tutorial de Swing, logo no início

Não era assim. O registro só era atualizado depois de nova consulta. E o DBU fazia uma nova consulta cada vez que você rolava a tela. Caso estivesse aberta uma ficha (ou tela de um único registro), só era alterada se fosse carregada de novo (feita uma nova consulta a base). Aliás, qualquer programinha em Clipper ou Visual Foxpro que tivesse alguma serventia, tinha que fazer estas verificações se o registro não tinha sido alterado em outra máquina.

O mesmo se pode fazer em Java.

[]s
Luca

Segue uma imagem sobre uma sugestão de como resolver este problema.

flws

2009/8/3/5547380d9efc1e3c1ede937c1f5e7933_40271.png829×707 24.5 KB

Cara em relação o .jar, faço da seguinte forma compartilho uma pasta em uma maquina ex.: \servidor\meuapp onde instalo o JVM em todas que usarão o aplicativo, então crio atalho apontando para esse caminho, com isso não preciso atualizar o .jar em cada maquina, só a do “servidor”, e o postgre fica nessa maquina “servidor” com o ip ex.: 192.168.0.1 no string de conexão uso esse ip.

Em relação ao assunto do abrir registros no DBF, programei muito tempo em clipper, e fazia da seguinte forma, quando um usuario abria o registro para alteração, nenhuma outra maquina tinha acesso ao registro, sómente quando o primeiro liberava, mas no SQL, eu nunca fiz isso, até porque não tenho motivo para ter esse controle !!!

Olá Luca, bom dia!

Luca:

Olá

Qualquer tutorial de Swing, logo no início

Não era assim. O registro só era atualizado depois de nova consulta. E o DBU fazia uma nova consulta cada vez que você rolava a tela. Caso estivesse aberta uma ficha (ou tela de um único registro), só era alterada se fosse carregada de novo (feita uma nova consulta a base). Aliás, qualquer programinha em Clipper ou Visual Foxpro que tivesse alguma serventia, tinha que fazer estas verificações se o registro não tinha sido alterado em outra máquina.

O mesmo se pode fazer em Java.

[]s
Luca

Rapaz, olha se eu tiver um tempo vou gravar um vídeo e coloco na net para você ver melhor.
Tenho certeza cara que a atualização é feita sem ninguém passar nem perto do pc.
Valew Luca, assim que conseguir eu posto!

Olá

Nem preciso ver. Na época do Clipper desenvolvi sistemas de gestão para várias empresas. E por mais que parecesse que o DBU era avisado automaticamente, isto não acontecia. Aliás o fonte do DBU era público e era um programinha bem simples.

Um dos modos mais corretos de trabalhar com DBF era fazer simplesmente o que o luisvix falou.

E a gente fazia isto em relação a TODOS os registros envolvidos na transação. Exemplo (fictício): ao alterar um registro de uma nota fiscal, todos os itens da nota eram bloqueados e ainda se bloqueava os registros das faturas, duplicatas, livros fiscais e todos os demais envolvidos na transação.

Os meus sistemas trocavam mensagens entre as estações e sempre que alguém tentava abrir um registro travado por outra, pipocava uma mensagem na tela avisando que o registro estava em uso ela tal estação que abriu. Mas isto fui eu quem fiz, nada automático do Clipper.

Ah, uma coisa importante que meus sistemas faziam era todo dia ao abrir, consistir os dados justamente para saber se alguém tinha feito alguma alteração “por fora” usando um DBU da vida. Caso afirmativo, soltava alarmes e minha responsabilidade ficava resguardada.

[]s
Luca

Acho que Java Web Start pode te ajudar um pouco, tente dar uma estudada nisso tbm.

Olá fantomas, bom dia!
Obrigado por ajudar neste tópico também!

fantomas:

Segue uma imagem sobre uma sugestão de como resolver este problema.

flws

Parece ser a solução ideal mesmo. Vou precisar estudar sobre JMS, DBMS, e outras dúvidas no geral!
Sugere algum artigo, livro,…?
Um abração, [color=red]Obrigado![/color]

Olá Luis, bom dia!

Então eu também fazia dessa forma com os programas em Clipper. Só que na conexão com o banco nem era necessário configurar IP nem nada. Criava o aruivo dentro da pasta onde estava o programa e usava “USE CLIENTES”, já era. Mas como eu sei que fazia esses programas com estruturas do tipo “qualquer jeito”, eu quero mudar isso agora que estou em Java e fazer de uma forma que a comunidade entenda sem muito sacrifício.

Um abração, obrigado por estar aqui no tópico![color=red]Valew![/color]

Luca:

Olá

Nem preciso ver. Na época do Clipper desenvolvi sistemas de gestão para várias empresas. E por mais que parecesse que o DBU era avisado automaticamente, isto não acontecia. Aliás o fonte do DBU era público e era um programinha bem simples.

Um dos modos mais corretos de trabalhar com DBF era fazer simplesmente o que o luisvix falou.

E a gente fazia isto em relação a TODOS os registros envolvidos na transação. Exemplo (fictício): ao alterar um registro de uma nota fiscal, todos os itens da nota eram bloqueados e ainda se bloqueava os registros das faturas, duplicatas, livros fiscais e todos os demais envolvidos na transação.

Os meus sistemas trocavam mensagens entre as estações e sempre que alguém tentava abrir um registro travado por outra, pipocava uma mensagem na tela avisando que o registro estava em uso ela tal estação que abriu. Mas isto fui eu quem fiz, nada automático do Clipper.

Ah, uma coisa importante que meus sistemas faziam era todo dia ao abrir, consistir os dados justamente para saber se alguém tinha feito alguma alteração “por fora” usando um DBU da vida. Caso afirmativo, soltava alarmes e minha responsabilidade ficava resguardada.

[]s
Luca

Mas Luca, porque isso acontece aqui então cara? Tem uma explicação?
Porque cara eu também desenvolvia os sistemas nessa hierarquia que você falou. Pegou até um exemplo bom da nota fiscal.
Mas tenho absoluta certeza que quando os 2 DBU’s em máuinas distintas tem o mesmo DBF aberto e algo for alterado em uma das máuinas imediatamente a outra se atualiza sem eu precisar encostar na outra.

Obrigado Lucão por estar ajudando, [color=red]valew mesmo![/color]

Olá Luiz Aguiar! Boa tarde!

Obrigado pela dica, vou estudar sim! Qualquer coisa volto a postar! [color=red]Um abraço.[/color]