Olá.
No sistema existe um tabela com os valores das sequências, essas
sequências dependem da empresa então eu não posso usar as sequências
do postgres.
Eu preciso ler e alterar este valor.
O problema é que as vezes ocorre uma leitura antes que tenha terminado
de alterar o valor.
Eu vi que existe o
On 10/25/07, Evandro Ricardo Silvestre [EMAIL PROTECTED] wrote:
Leodinei Bielak wrote:
Olá.
No sistema existe um tabela com os valores das sequências, essas
sequências dependem da empresa então eu não posso usar as sequências
do postgres.
Eu preciso ler e alterar este valor.
Como
Entao como era meio urgente, eu fiz uma PEQUENA GAMBIARRA..
agora a nivel de aplicacao, quando eu altero um registro, eu guardo em
uma tabela auxiliar os seguintes dados
PID, TABLE, COD
onde pid é o pid da conexao que esta alterando, table é o nome da
tabela CLIENTES por exempolo.. eo COD é o
E se sua aplicação terminar de uma maneira inesperada ??
O registro ficará lá e ninguém mais conseguirá alterar o registro
Prevendo justamente este caso que eu armazeno tambem o PID da conexao
que travou o registro. Entao eu testo se pid continua ativo. se o pid
nao está mais ativo,
Em Qui, 2007-06-28 às 15:56 +0200, ..:: Rodrigo Machado ::.. escreveu:
Prevendo justamente este caso que eu armazeno tambem o PID da conexao
que travou o registro.
Não, você está fazendo tudo errado, por falta de paciência de aprender.
Por favor estude transações. Coloque teu
Para Bloquear (lock) os registros e saber que esta bloqueado pela outra
aplicação use o FOR UPDATE NOWAIT isso irá avisar que o registro está
travado.
exemplo
SELECT * FROM clientes WHERE cod = '0001' FOR UPDATE NOWAIT
Claro que tudo isso feito dentro de uma transação.
Moises.
Não, você está fazendo tudo errado, por falta de paciência de aprender.
Desculpa companheiro, tive muito pouco tempo para aprender,
mas quero muito aprender, agradeco a todos que nos ajudam.
sobre isolamento serializável, todos me falaram disso, vou estudar
isto com mais calma.
Mas a
Em Qui, 2007-06-28 às 16:43 +0200, ..:: Rodrigo Machado ::.. escreveu:
Mas a resposta do companheiro moises vai fazer com que eu elimine esta
tabela auxiliar.
SELECT * FROM clientes WHERE cod = '0001' FOR UPDATE NOWAIT..
ja testei.. e deu certo.. se um registro está bloquado, ele retorna
Pessoal, pintou mais uma duvida,
será que existe alguma forma de saber qual foi a estacao, ou serve
mesmo o PROCPID que está mantendo o/ou os registros bloqueados com FOR
UPDATE?
Existe esta informacao em alguma tabela de sistema, ou funcao no postgresql ??
Pois imagina que o FULANINHO comecou
pg_stat_activity.
eu ainda gosto da solução dos outros colegas. controle pela transação. perde
umas duas estudando que vai valer BEM mais a pena.
abraço.
--
Atenciosamente,
Sebastian Selau Webber Colombo
Não adianta ter a melhor solução, o windows fode com ela tb!!!
Em Qui, 2007-06-28 às 22:44 +0200, ..:: Rodrigo Machado ::.. escreveu:
Pois imagina que o FULANINHO comecou alterar um cliente, eu vou ter
que manter o registro bloqueado até que o fulaninho termine
Por essas e outras é que não se deve fazer na mão o que o controle de
transações faz por
eu ainda gosto da solução dos outros colegas. controle pela transação. perde
umas duas estudando que vai valer BEM mais a pena.
Obrigado pela dica.. vou seguir seu conselho..
Mas me diz..
a travez da transacao.. tem como o segundo usuario saber se pode ou
nao alterar o registro? e ser avisado
Em Qui, 2007-06-28 às 23:02 +0200, ..:: Rodrigo Machado ::.. escreveu:
a travez da transacao.. tem como o segundo usuario saber se pode ou
nao alterar o registro? e ser avisado de tal coisa?
Se isto for possivel.. vou implementar na minha aplicacao
O tempo que você já gastou, e ainda
pg_stat_activity.
Certo, aqui eu posso pegar o IP da estacao que está conectada, posso
fazer referencia ao PROCPID.. perfeito..
Mas como saber qual PROCPID está mantendo bloqueado certo registro??
___
pgbr-geral mailing list
vc é teimoso hein!?
isso vc vai ver na view pg_locks.
--
Atenciosamente,
Sebastian Selau Webber Colombo
Não adianta ter a melhor solução o windows fode com ela tb!!!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
além do mais, podemos te ajudar a sanar as tuas dúvidas...
Estou muito agradecido pelas colaboracoes...
e estou muito interesado em controlar por transacoes assim como os
amigos me indicarao..
Mas me respondam o seguinte:
Vou poder bloquear um registro, e deixalo somente leitura para todas
as
Mas me respondam o seguinte:
Vou poder bloquear um registro, e deixalo somente leitura para todas
as demais estacoes?
Caso em uma segunda estacao alguem tentar alterar o mesmo registro,
vou poder avisalo que este registro está sendo alterado por outro
usuario, ou melhor, inclusive mostrar qual
Em Qui, 2007-06-28 às 23:33 +0200, ..:: Rodrigo Machado ::.. escreveu:
Vou poder bloquear um registro, e deixalo somente leitura para todas
as demais estacoes?
Isso é básico no PostgreSQL.
Caso em uma segunda estacao alguem tentar alterar o mesmo registro,
vou poder avisalo que este
além do mais, podemos te ajudar a sanar as tuas dúvidas...
abraço
agua mole, pedra dura. tanto bate até que fura... heheheh
--
Atenciosamente,
Sebastian Selau Webber Colombo
Não adianta ter a melhor solução o windows fode com ela tb!!!
___
Desculpe caros colegas.. mas acho que nao estamos falando o mesmo idioma entao..
Está é uma regra basica do funcionamento do meu sistema.. presiso sim
ou sim bloquear um registro e nao permitir que outros usuarios alterem
o mesmo, avisando-o antes de tentar fazer alguma alteracao..
Vamos a um
Em Qui, 2007-06-28 às 23:50 +0200, ..:: Rodrigo Machado ::.. escreveu:
Acontece que como esta venda esta em aberto, quando eu for alterar..
nao vou poder permitir que dois usuarios alterem a mesma venda..
Ah, então teu problema é completamente diferente.
Você fez uma transação
O que o SGBD deveria te ajudar é em criar uma restrição de integridade
correspondente; por exemplo, um CHECK CONSTRAINT. Mas isso ainda não é
suportado
(http://www.postgresql.org/docs/8.2/interactive/sql-createtable.html).
A menos que se bagunce um pouco o modelo para que na mesma tupla
Em Sex, 2007-06-29 às 00:19 +0200, ..:: Rodrigo Machado ::.. escreveu:
neste problema o SELECT FOR UPDATE NOWAIT ja me resolve.. perfeitamente.
Não resolve não. E se algum componente do sistema — servidor, rede,
cliente — falhar? A tupla será liberada, e baubau.
--
Leandro Guimarães
Bom dia companheiros,
Sou meio iniciante no MUNDO SQL, e estou desenvolvendo uma aplicacao
com o postgresql como banco.
Estou tentando implementar a seguinte ideia.
Presiso bloquear um registro para atualizacao, quando o usuario for
alterar por exemplo o cadastro do cliente quero bloquear este
De: ..:: Rodrigo Machado ::.. [EMAIL PROTECTED]
Para: Comunidade PostgreSQL Brasileira
pgbr-geral@listas.postgresql.org.br
Enviadas: Quarta-feira, 27 de Junho de 2007 12:08:36
Assunto: [pgbr-geral] Bloquear Row
Bom dia companheiros,
Sou meio iniciante no MUNDO SQL, e estou desenvolvendo uma
..:: Rodrigo Machado ::.. wrote:
Ja tentei SELECT FOR UPDATE
mas nao consegui fazer funcionar.
Como assim não conseguiu fazer funcionar? Pode ser mais específico? O
que não está funcionando? Podes enviar um exemplo (curto) para podermos
identificar a sua dificuldade?
--
Euler Taveira de
Pessoal, consegui usar o FOR UPDATE.. na verdade eu presisava comecar
uma transaction
Entao vamos até que ponto eu ja sei fazer..
BEGIN;
SELECT * FROM CLIENTE WHERE COD='0001' FOR UPDATE;
e por ai eu fico.. até que o usuario altere todo o cliente.. no final
eu vou fazer
UPDATE CLIENTE SET..
Então… use o nível de isolamento serializável, e esqueça o FOR UPDATE.
Muito mais prático.
Vou estudar esse negocio de isolamento.. obrigado pela dica.
Mas e agora, quando o segundo usuario quer alterar o mesmo cliente o
postgres fica la.. esperando até que o primeiro termine..
mas
Teria ai algum exemplo onde eu faco uma consulta bloqueando os
registros retornados.
e depois outra consulta onde retorna os mesmos dados mas de alguma
forma indicando que é somente leitura...
é possivel?
Obrigado...
___
pgbr-geral mailing list
29 matches
Mail list logo
