Em 10 de outubro de 2011 16:10, Fabrízio de Royes Mello
fabriziome...@gmail.com escreveu:
Todavia, melhor resolver mesmo na sua aplicação. Na minha visão,
tentar fazer UPDATE numa linha que não existe tem mesmo é que retornar
erro.
+1 (mas sei que cada caso é um caso)
Mas um UPDATE de
On 12-10-2011 23:51, Luís Eduardo Porte wrote:
Já efetuei outros testes de conexão do servidor e consigo.. não há bloqueios
não.
O que diz o log do FreeTDS? Já fizeste um programa em Perl utilizando DBI para
verificar se o problema é no DBI-link?
--
Euler Taveira de Oliveira - Timbira
Pessoal, com a chegada do horário de verão, estou com um probleminha para
resolver.
Aqui na empresa, possuímos diversos databases de vários sistemas espalhados
pelo Brasil inteiro, em um único servidor. Com o horário de verão chegando,
não é possível simplesmente alterar o parâmetro no
Em 13 de outubro de 2011 10:47, Pedro Ivo Bispo França
pe...@xbrain.com.brescreveu:
Pessoal, com a chegada do horário de verão, estou com um probleminha para
resolver.
Aqui na empresa, possuímos diversos databases de vários sistemas espalhados
pelo Brasil inteiro, em um único servidor. Com o
Obrigado pela resposta Edson! Queria deixar essa solução em último caso...
Vamos torcer que alguém venha com alguma ideia genial...
[]'s
Em 13 de outubro de 2011 10:58, Edson neto edson.edsn...@gmail.comescreveu:
Em 13 de outubro de 2011 10:47, Pedro Ivo Bispo França
pe...@xbrain.com.br
Pessoal mais uma vez preciso da vossa ajuda
Tenho o seguinte select
select distinct f.data_age, a.cod_key, a.cod_id, d.nome, d.end_abr, d.end_cad,
d.end_num, d.end_com, d.end_bai, d.end_cid, d.end_est, end_cep, a.pedido,
a.data_age, a.hora_age, a.hora_fim, a.codigo, b.descricao, c.qtd_item,
2011/10/13 Pedro Ivo Bispo França pe...@xbrain.com.br:
Aqui na empresa, possuímos diversos databases de vários sistemas espalhados
pelo Brasil inteiro, em um único servidor. Com o horário de verão chegando,
não é possível simplesmente alterar o parâmetro no postgres.conf pois
diversos estados
2011/10/13 Alexsander Rosa alexsander.r...@gmail.com:
Mas um UPDATE de uma linha que não existe não dá erro, apenas não faz
nada pois não encontra nenhuma tupla que satisfaça a cláusula WHERE.
No máximo retorna NOT FOUND numa procedure, mas não chega a dar erro.
Pois é, e o código tem de
Em 13 de outubro de 2011 11:49, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
2011/10/13 Alexsander Rosa alexsander.r...@gmail.com:
Mas um UPDATE de uma linha que não existe não dá erro, apenas não faz
nada pois não encontra nenhuma tupla que satisfaça a cláusula WHERE.
No
Em 12-10-2011 21:48, Tiago Adami escreveu:
Ok, entendi. Mas isto só se aplica quando você está usando SEQUENCES
em chaves primárias - possivelmente artificiais. Isto não funcionaria
com chaves naturais, do tipo CHAR ou VARCHAR, por exemplo. Agora
começo entender porque os arquitetos de
Em 12-10-2011 22:10, Guimarães Faria Corcete DUTRA, Leandro escreveu:
começo entender porque os arquitetos de software vivem reclamando
quando recuso a criação de chaves artificiais (geralmente colunas com
nome ID do tipo Integer) só porque fica mais fácil trabalhar com
Hibernate :)
Espero
Em 13-10-2011 11:49, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2011/10/13 Alexsander Rosaalexsander.r...@gmail.com:
Mas um UPDATE de uma linha que não existe não dá erro, apenas não faz
nada pois não encontra nenhuma tupla que satisfaça a cláusula WHERE.
No máximo retorna NOT FOUND
On 13-10-2011 10:47, Pedro Ivo Bispo França wrote:
O problema é que se eu altero o timezone da base, TODAS as datas da base,
mesmo as anteriores ao horário de verão, vão ser alteradas no output. Como
evitar isso? Talvez o a coluna is_dst em pg_timezone_names ajude em algo?
Não entendi direito
Euler, mas eu armazeno a data em um timestamp with time zone, porém, ele não
armazena o timezone no momento da gravação, a hora armazenada é a
equivalente em UTC, e no momento do display, ele faz o ajuste dependendo da
timezone atual. Confere? Não vejo um jeito de adaptar isso tudo e deixar os
2011/10/13 Pedro Ivo Bispo França pe...@xbrain.com.br:
Euler, mas eu armazeno a data em um timestamp with time zone, porém, ele não
armazena o timezone no momento da gravação, a hora armazenada é a
equivalente em UTC, e no momento do display, ele faz o ajuste dependendo da
timezone atual.
2011/10/13 Shander Lyrio shan...@nucleo45.com.br:
Examente por isto você pode sempre criar um índice unique na chave
natural que você usaria e que acha que garante unicidade. Teria o mesmo
efeito de garantir unicidade, e ainda facilitaria o uso do ORM. A que
custo?? Um pouco mais de
2011/10/13 Shander Lyrio shan...@nucleo45.com.br:
Em 13-10-2011 11:49, Guimarães Faria Corcete DUTRA, Leandro escreveu:
Pois é, e o código tem de capturar o NOT FOUND como qualquer outro
erro, e tratá-lo, seja abortando, convertendo num INSERT ou seja lá o
que fôr correto no caso.
Mas
2011/10/13 Shander Lyrio shan...@nucleo45.com.br:
Exato, para ter algo gerado automaticamente obviamente ele deveria
seguir um padrão onde o banco de dados pudesse gerar por si só este
valor. Caso contrário, não tem nem lógica enviar um insert para o
servidor sem a chave primária.
Se
entendi...
Estou pensando em por uma flag no banco, que diz se o estado participa ou
não do horário de verão. A aplicação, ao abrir a sessão le esse parâmetro, e
da um AT TIMEZONE correspondente, se a data estiver nos períodos de horário
de verão.
O que acham? Se tiverem uma idéia melhor, podem
Em 13 de outubro de 2011 13:57, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
2011/10/13 Shander Lyrio shan...@nucleo45.com.br:
ORM não resolve todos os males do mundo, ele resolve a grande maioria
deles, mas não todos. Para mim, insert, update e delete é 99% por
2011/10/13 Alexsander Rosa alexsander.r...@gmail.com:
De resto, damos preferência para stored procedures que fazem coisas
como emite_nota, baixa_estoque, etc. Com isso as regras de negócio
ficam no BD e podem ser acessadas por aplicações standalone, console,
web, mobile, etc de forma
2011/10/13 Pedro Ivo Bispo França pe...@xbrain.com.br:
Estou pensando em por uma flag no banco, que diz se o estado participa ou
não do horário de verão. A aplicação, ao abrir a sessão le esse parâmetro, e
da um AT TIMEZONE correspondente, se a data estiver nos períodos de horário
de verão.
Nossa...muito obrigado!! Ajudou bastante!! Vou tentar resolver o problema
desta forma!
Obrigado a todos que contribuiram
Em 13 de outubro de 2011 14:45, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
2011/10/13 Pedro Ivo Bispo França pe...@xbrain.com.br:
Estou pensando
Em 13-10-2011 13:48, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2011/10/13 Shander Lyrioshan...@nucleo45.com.br:
Eu acredito que o meio termo é, quase sempre, a melhor saída. Já vi
diversas discursões sobre isto aqui na lista e no final sempre chega-se
a conclusão que encontrar
Em 13 de outubro de 2011 11:07, Marcelo Silva (IG) marc...@ig.com.br escreveu:
Pessoal mais uma vez preciso da vossa ajuda
Tenho o seguinte select
select distinct f.data_age, a.cod_key, a.cod_id, d.nome, d.end_abr,
d.end_cad, d.end_num, d.end_com, d.end_bai, d.end_cid, d.end_est, end_cep,
2011/10/13 Shander Lyrio shan...@nucleo45.com.br:
O problema ocorre quando vários clientes de fusos horários diferentes
tem seu sistema hospedado em um mesmo servidor, o que não é incomum em SaaS.
Se o sistema roda no servidor, isso é bom — mas, se isso significa que
ele não se comunica
2011/10/13 Shander Lyrio shan...@nucleo45.com.br:
Não, quem chega a esta conclusão é quem está vivendo o processo do
desenvolvimento. Modelo relacional não explica tudo, tentar forçar tudo
a se encaixar no modelo relacional é contraproducente.
Modelo não é e nunca foi explicação, é
Em 13/10/2011 15:39, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2011/10/13 Shander Lyrioshan...@nucleo45.com.br:
O problema ocorre quando vários clientes de fusos horários diferentes
tem seu sistema hospedado em um mesmo servidor, o que não é incomum em SaaS.
Se o sistema roda no
2011/10/13 Flávio Alves Granato flavio.gran...@gmail.com:
Em 13/10/2011 15:39, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2011/10/13 Shander Lyrioshan...@nucleo45.com.br:
Imagina um sistema de logística onde gente do Brasil inteiro insere
dados, cada um estando em um fuso horário
Em 13-10-2011 15:39, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2011/10/13 Shander Lyrioshan...@nucleo45.com.br:
O problema ocorre quando vários clientes de fusos horários diferentes
tem seu sistema hospedado em um mesmo servidor, o que não é incomum em SaaS.
Se o sistema roda
Pessoalmente acho que o
melhor custo/benefício é trabalhar com o cache da aplicação, ele bem
administrado vai reduzir drasticamente a quantidade de consultas
enviadas para o banco de dados.
O seu achômetro pessoal vai contra a experiência geral da humanidade.
O cache da aplicação tem seu
Pessoal,
Gostaria de saber se existe a possibilidade de fazer two phase
commit em agrupamentos distintos no PostgreSQL 9 ou superior. Pode
ser inclusive com auxilio de algum pacote contrib ou projeto externo.
Grato,
Rogério Bassete
___
pgbr-geral
Qual o problema?
Concordo, não vejo problema a não ser quando o mesmo usuário é usado em
vários logins ao mesmo tempo e em diferentes lugares, fora isso acho
que é bem fácil de resolver.
Nesse caso, a gente volta à solução ideal — o cliente tem de informar
à aplicação onde está — e ao
Em 13/10/2011 15:59, Shander Lyrio escreveu:
Em 13-10-2011 15:39, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2011/10/13 Shander Lyrioshan...@nucleo45.com.br:
O problema ocorre quando vários clientes de fusos horários
diferentes
tem seu sistema hospedado em um mesmo servidor, o
Pessoal, então se em uma aplicação WEB não tem como solicitar do browser a
localização do usuário, então nos resta pré-cadastrar se um estado está ou
não utilizando o horário de verão e setar o timezone da sessão de acordo com
esta informação. Correto?
Abraços
Em 13 de outubro de 2011 16:12,
Em 13 de outubro de 2011 15:44, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
2011/10/13 Shander Lyrio shan...@nucleo45.com.br:
O que seria chave natural para um cadastro de clientes?? cpf se for
física ou cnpj se for jurídica? existe alguma melhor? e quando a esposa
Em 13/10/2011 16:16, Pedro Ivo Bispo França escreveu:
Pessoal, então se em uma aplicação WEB não tem como solicitar do
browser a localização do usuário, então nos resta pré-cadastrar se um
estado está ou não utilizando o horário de verão e setar o timezone da
sessão de acordo com esta
Pelo Google achei comentários como o [1] que menciona a respeito de pegar a
hora do cliente e não do servidor através de linguagem.
Seria a isso que que se refere?
[1] http://www.hardware.com.br/comunidade/hora-php/966338/
Abraços,
Eduardo Alexandre
Em 13 de outubro de
Em 13-10-2011 15:44, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2011/10/13 Shander Lyrioshan...@nucleo45.com.br:
O que seria chave natural para um cadastro de clientes?? cpf se for
física ou cnpj se for jurídica? existe alguma melhor? e quando a esposa
e o marido usam o mesmo
Gostaria de saber se existe a possibilidade de fazer two phase
commit em agrupamentos distintos no PostgreSQL 9 ou superior. Pode
ser inclusive com auxilio de algum pacote contrib ou projeto externo.
O PostgreSQL tem total suporte a 2PC.
Só cuidado pra não cair no dilema quero x peço y que
Em 13/10/2011 16:27, Eduardo Alexandre escreveu:
Pelo Google achei comentários como o [1] que menciona a respeito de
pegar a hora do cliente e não do servidor através de linguagem.
Seria a isso que que se refere?
[1] http://www.hardware.com.br/comunidade/hora-php/966338/
Sim, é disso mesmo
E analisando aqui, o pior não é nem descobrir a timezone do cliente. É
descobrir se ele está adotando ou não o bendito horário de verão. Isso é uma
questão política e não só geográfica. (A bahia está entrando recentemente no
horário de verão se não me engano)
Tem como saber se o usuário está ou
Em 13/10/2011 16:53, Pedro Ivo Bispo França escreveu:
E analisando aqui, o pior não é nem descobrir a timezone do cliente. É
descobrir se ele está adotando ou não o bendito horário de verão. Isso
é uma questão política e não só geográfica. (A bahia está entrando
recentemente no horário de
2PC é a saída pra você mesmo? O que *exatamente* você quer fazer?
Tenho clientes no seguinte cenário:
Server01 - IP 200.x.x.x:5432 (Matriz)
Server02 - IP 201.x.x.x:5432 (Filial 01)
Server03 - IP 202.x.x.x:5432 (Filial 02)
Quero abrir uma transação entre os 3 servidores distintos, inserir um
2011/10/13 Rogerio Bassete roge...@microwork.inf.br:
2PC é a saída pra você mesmo? O que *exatamente* você quer fazer?
Quero abrir uma transação entre os 3 servidores distintos, inserir um
registro e commitar tudo.
Lembra que, com replicação, a dependência da disponibilidade dos três,
e da
2011/10/13 Shander Lyrio shan...@nucleo45.com.br:
O Sistema roda na Web, um browser não passa automaticamente o fuso
horário numa requisição http, também não tem como você pedir para o
browser te passar esta informação do sistema operacional do usuário por
questões de segurança.
Que
Em 13 de outubro de 2011 17:21, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
2011/10/13 Rogerio Bassete roge...@microwork.inf.br:
2PC é a saída pra você mesmo? O que *exatamente* você quer fazer?
Quero abrir uma transação entre os 3 servidores distintos, inserir um
2011/10/13 Flávio Alves Granato flavio.gran...@gmail.com:
As vezes é bom não ter regras e as vezes é bom ter regras
Se não há regras, não há como criar um sistema… um sistema sem regras
é um sistema inconsistente.
às vezes é
bom ter relacionamentos e às vezes não. Concordo que o modelo
2011/10/13 Eduardo Alexandre eduardog...@gmail.com:
Pelo Google achei comentários como o [1] que menciona a respeito de pegar a
hora do cliente e não do servidor através de linguagem.
Seria a isso que que se refere?
[1] http://www.hardware.com.br/comunidade/hora-php/966338/
Basicamente sim,
2011/10/13 Pedro Ivo Bispo França pe...@xbrain.com.br:
E analisando aqui, o pior não é nem descobrir a timezone do cliente. É
descobrir se ele está adotando ou não o bendito horário de verão.
Por isso que se deve usar não a diferença de fuso (+2 ou -3, por
exemplo), mas o nome do fuso ou, mais
2011/10/13 Flávio Alves Granato flavio.gran...@gmail.com:
Agora tem, já que o Lula sancionou a lei que fixa os dias de início e
fim do horário de verão.
O problema não é haver lei, que sempre houve, mas o governo resistir a
emitir medidas provisórias acochambrando para a Globo transmitir a
2011/10/13 Shander Lyrio shan...@nucleo45.com.br:
Responder perguntas sempre dizendo, que se deveria procurar uma chave
natural, ou que se estivesse usando chave natural isso ou aquilo não
aconteceria, ou ainda que sugiro que procure chave natural não resolve o
problema de ninguém,
2011/10/13 Flavio Henrique Araque Gurgel fha...@gmail.com:
Basicamente sim, mas não basta a hora: tem de saber a diferença para
UTC, e isso se sabe pela cidade de referência do fuso.
A hora GMT é a hora zero de onde os fusos horários são calculados.
Em Informática, GMT foi substituída pela
Em 13-10-2011 16:16, Pedro Ivo Bispo França escreveu:
Pessoal, então se em uma aplicação WEB não tem como solicitar do browser
a localização do usuário, então nos resta pré-cadastrar se um estado
está ou não utilizando o horário de verão e setar o timezone da sessão
de acordo com esta
2011/10/13 Alexsander Rosa alexsander.r...@gmail.com:
Discordo do uso indiscriminado de chaves artificiais, isso traz mais
malefícios do que benefícios. No entanto, na minha opinião o código
do cliente não é uma chave artificial, pois ele aparece fora da
aplicação.
Perfeitamente! E por isso
Você pode utilizar então 2PC:
http://www.postgresql.org/docs/9.1/static/sql-prepare-transaction.html
Está disponível pelo menos desde o PostgreSQL 8.2 (talvez antes, não
tenho certeza nem documentação disponível).
Como nunca usei 2PC, já li essa página do manual e não consegui
simular. Na
2011/10/13 Rogerio Bassete roge...@microwork.inf.br:
Alguém poderia me fornecer um exemplo em psql ou link de uso de 2PC em
clusters distintos.
Não muda nada, porque cada cluster escuta numa porta diferente…
___
pgbr-geral mailing list
Em 13-10-2011 16:25, Flávio Alves Granato escreveu:
Em 13/10/2011 16:16, Pedro Ivo Bispo França escreveu:
Pessoal, então se em uma aplicação WEB não tem como solicitar do
browser a localização do usuário, então nos resta pré-cadastrar se um
estado está ou não utilizando o horário de verão e
Não muda nada, porque cada cluster escuta numa porta diferente…
Leandro, sem querer abusar, pode me fornecer um LOG do psql que simula
isso de exemplo?
Grato,
Rogério A Bassete
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
Em transações bancárias por exemplo sim, mas e nas outras
aplicações? Creio que um modelo hibrido seria bom onde objetos complexos
vivem em harmonia com o modelo relacional. Claro cada situação é uma
situação.
Esse modelo é o relacional, vide _The Third Manifest_… o modelo
relacional não
Em 13/10/2011 17:54, Shander Lyrio escreveu:
Em 13-10-2011 16:25, Flávio Alves Granato escreveu:
Em 13/10/2011 16:16, Pedro Ivo Bispo França escreveu:
Pessoal, então se em uma aplicação WEB não tem como solicitar do
browser a localização do usuário, então nos resta pré-cadastrar se um
estado
Em 13-10-2011 16:17, Flávio Alves Granato escreveu:
Creio que seja mais fácil do que você colocou em sua argumentação e que
pelo contrário seja uma questão de segurança saber a que real horário o
cliente acessou a sua máquina, se não seria a segurança do *indows
Você não tem como
O mais simples é isso mesmo, o usuário informa sua timezone. Num ERP
isto pode ser implícito, o usuário pode ser cadastrado com uma TZ fixa
ou a TZ pode ser associada ao servidor onde ele está se logando. Um
funcionário do operacional pode nem saber que existe TZ e esta ser
fixa no seu cadastro;
Em 13-10-2011 17:26, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2011/10/13 Shander Lyrioshan...@nucleo45.com.br:
O Sistema roda na Web, um browser não passa automaticamente o fuso
horário numa requisição http, também não tem como você pedir para o
browser te passar esta
Em 13/10/2011 18:18, Shander Lyrio escreveu:
Em 13-10-2011 16:17, Flávio Alves Granato escreveu:
Creio que seja mais fácil do que você colocou em sua argumentação e que
pelo contrário seja uma questão de segurança saber a que real horário o
cliente acessou a sua máquina, se não seria a
Alexandre, poderia citar os malefícios das chaves artificiais?
Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu:
2011/10/13 Alexsander Rosa alexsander.r...@gmail.com:
Discordo do uso indiscriminado de chaves artificiais, isso traz mais
malefícios do que benefícios. No entanto,
pessoal, como eu faço para pegar o mês anterior de uma data via SQL?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
On Thu, Oct 13, 2011 at 8:04 PM, Pedro B. Alves pedroalve...@gmail.com wrote:
pessoal, como eu faço para pegar o mês anterior de uma data via SQL?
SELECT CURRENT_DATE - interval '1 month';
-Leo
--
Leonardo Cezar
http://postgreslogia.wordpress.com
___
Leandro, sem querer abusar, pode me fornecer um LOG do psql que simula
isso de exemplo?
Imagine assim:
Servidores A, B e C
Comece a transação em cada um:
A BEGIN;
B BEGIN;
C BEGIN;
Faça alguma coisa em cada servidor:
A INSERT INTO foo VALUES (1,2,3,4);
B INSERT INTO foo VALUES (1,2,3,4);
C
Le 2011-O-13 17h56, Rogerio Bassete a écrit :
Não muda nada, porque cada cluster escuta numa porta diferente…
Leandro, sem querer abusar, pode me fornecer um LOG do psql que simula
isso de exemplo?
Desculpa, não estou em condições de montar um testes agora…
--
Le 2011-O-13 18h5, Flávio Alves Granato a écrit :
Onde se encaixa o modelo não relacional nesta teoria? O famoso NoSQL,
agora viu que não disse programação OO. Sim, acho que não é necessário
implementar a complexidade de um modelo relacional em todas as
situaçãos, apesar de ele poder ser
Le 2011-O-13 18h12, Shander Lyrio a écrit :
Sempre há uma chave natural, quase nunca faz sentido usá-la.
Absurdo.
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM:
2011/10/13 Flavio Henrique Araque Gurgel fha...@gmail.com:
[corte]
A sua aplicação deve ter ciência que os três PREPARE acima deram certo.
Se *todos* derem certo:
A COMMIT PREPARED 'xpto';
B COMMIT PREPARED 'xpto';
C COMMIT PREPARED 'xpto';
Terminou.
Utilize a função pg_prepared_xact() em
73 matches
Mail list logo
