Obrigado pela dica Flavio, funcionou certinho.
Estava conferindo a documentação em português, mas ainda não tinha
encontrado esta informação.
Abraços!
Em 3 de abril de 2012 23:40, Flavio Henrique Araque Gurgel
escreveu:
> Veja a documentação do pg_hba.conf.
> http://www.postgresql.org/docs/9.1/st
> Primeiramente, me apresento a vocês, sou um novo usuário, não apenas
> da lista mas também do Postgres, conheço um pouco de Oracle e Mysql,
> mas decidi migrar para o Pg, por diversos motivos.
Bem vindo. Será muito feliz na sua escolha.
> Então, segui uns guias básicos para configurá-lo na minh
Boa noite lista!
Primeiramente, me apresento a vocês, sou um novo usuário, não apenas
da lista mas também do Postgres, conheço um pouco de Oracle e Mysql,
mas decidi migrar para o Pg, por diversos motivos.
Então, segui uns guias básicos para configurá-lo na minha máquina
(Ubuntu 11.10), e a instala
Obrigado pessoal, ainda estou fazendo alguns levantamento, mas me parece uma
boa pratica deixar na mesma base, ainda estou no inicio da analise de negócio,
mas já tenho uma base para estudo.
Novamente Obrigado a todos.
> Gostaria de saber como os grandes sistemas de ERP trabalham com Multi
> E
Em 3 de abril de 2012 16:10, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:
>
> Minha questão, que não estava clara e ainda está aberta, é se essa era
> uma solução necessária ou foi simplesmente a mais fácil de
> implementar.
>
Definitivamente não foi a mais fácil de impleme
Eu uso assim, separado por empresa, servidores diferentes.
Os pedidos começam do 1 a cada nova filial aberta ou CD criado.
Por exemplo, uma loja pode estar no pedido 327462/7 e outra no 879123/3.
O número depois da barra (na tela e onde mais é impresso) é o número da
"filial".
Em 3 de abril de 201
2012/4/3 Fabrízio de Royes Mello :
>
> Perfeito, mas não discordei do Dutra, apenas demonstrei que existem sim
> casos práticos em que existe sim essa *divisão* de bases de dados.
Ah, sim, claro.
Minha questão, que não estava clara e ainda está aberta, é se essa era
uma solução necessária ou foi
Em 03/04/2012 16:02, Fabrízio de Royes Mello escreveu:
Em 3 de abril de 2012 15:41, Flávio Alves Granato
mailto:flavio.gran...@gmail.com>> escreveu:
Fabrízio,
Ainda concordo com o Dutra, não há motivos para separar as bases,
mas também entendo o seu argumento de haver bases separ
Em 3 de abril de 2012 15:41, Flávio Alves Granato
escreveu:
> Fabrízio,
>
> Ainda concordo com o Dutra, não há motivos para separar as bases, mas
> também entendo o seu argumento de haver bases separadas para não "parar" a
> produtividade das filias. Mas realmente não vejo motivos para separar as
Em 03/04/2012 15:29, Fabrízio de Royes Mello escreveu:
Em 3 de abril de 2012 15:20, Guimarães Faria Corcete DUTRA, Leandro
mailto:l...@dutras.org>> escreveu:
> 2- Trabalham separando fisicamente as bases, cada empresa sua base?
Qual a graça? Nunca vi isso... tem quem trabalh
Fk da empresa na tabela, mais cada caso deve ser analisado.
Por exemplo:
Empresa: cnpj,
Deposito: id, nome, *empresa ( empresa.cnpj )*
Produto: id, nome, modelo
Item: produto, *deposito atual* ( deposito.id ), quantidade
Assim você pode ter itens do estoque por empresa.
Um cadastro de produt
Em 3 de abril de 2012 15:20, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:
>
>
>
>
> > 2- Trabalham separando fisicamente as bases, cada empresa sua base?
>
> Qual a graça? Nunca vi isso… tem quem trabalhe assim?
>
>
>
>
Tem muitos softwares que trabalham nesse formato, on
2012/4/3 Rogério Grando :
>
> Gostaria de saber como os grandes sistemas de ERP trabalham com Multi
> Empresas? Não sei se isso é uma informação confidencial
Uai, e por que seria?
> 1- Código da empresa nas tabelas (mestre) ?
É a solução ideal, e a que sempre vi.
> 2- Trabalham separando fis
Olá pessoal, Boa tarde a todos.
Gostaria de saber como os grandes sistemas de ERP trabalham com Multi
Empresas? Não sei se isso é uma informação confidencial, mas gostaria de ter
uma ideia.
1- Código da empresa nas tabelas (mestre) ?
2- Trabalham separando fisicamente as bases, cada empresa sua
A linha de comando que uso é a seguinte:
\rh\center\pg_dump.exe -h localhost -p 5432 -U postgres -F c -b -v -f
"\rh\backup\center_banco.backup" center
OBS: O pg_dump.exe e seus acessórios estão na pasta do sistema.
Obrigado.
Ronei
___
pgbr-geral mail
Em 03/04/2012 09:16, "Ronei Heck" escreveu:
>
> Senhores,
>
> Tenho um cliente que tem um micro celeron 2ghz e 2 gb ram que, se
formatar e instalar o win xp, o backup de 300 k leva meia hora pra fazer,
porém se formatar a instalar o win 7, este mesmo backup leva um minuto. O
cliente precisa que se
É bem pequena. O backup resulta num arquivo de 300k. A única coisa que
alteramos neste arquivo é os ips que irão acessar. O micro acabou de ser
formatado e o postgres recém instalado.
Obrigado.
Ronei
- Original Message -
From: Emerson Martins
To: Comunidade PostgreSQL Brasileir
Em 3 de abril de 2012 09:34, Francisco Porfirio <
francisco.porfi...@gmail.com> escreveu:
> Pessoal,
>
> No postgres 9.0.1 existe algo para limpar cache?
>
> Similar ao seguinte comando do oracle...
> alter system flush buffer_cache?
>
> Preciso desta informação para poder testar performance de al
Pessoal,
No postgres 9.0.1 existe algo para limpar cache?
Similar ao seguinte comando do oracle...
alter system flush buffer_cache?
Preciso desta informação para poder testar performance de algumas
consultas, e criação de determinados índices.
--
Atenciosamente
Francisco Porfirio Ribeiro Net
Senhores,
Tenho um cliente que tem um micro celeron 2ghz e 2 gb ram que, se formatar e
instalar o win xp, o backup de 300 k leva meia hora pra fazer, porém se
formatar a instalar o win 7, este mesmo backup leva um minuto. O cliente
precisa que seja o win xp.
Alguma luz do que pode estar aconte
Em 03/04/2012 08:13, Matheus de Oliveira escreveu:
> O que o Irineu passou está correto (acho), mas só para explicar, o
> PostgreSQL assim como C/C++ assumem que o operador de divisão quando
> feito para dois inteiros deve retornar um inteiro. Logo, caso queira
> decimal você deve converter pelo
O que o Irineu passou está correto (acho), mas só para explicar, o
PostgreSQL assim como C/C++ assumem que o operador de divisão quando feito
para dois inteiros deve retornar um inteiro. Logo, caso queira decimal você
deve converter pelo menos um dos elementos para decimal.
Att.
--
Matheus de Oliv
Obrigado Irineu
Resultou. Podes dizer-me o que fazem os dois pontos?
Obrigado
Em 03-04-2012 12:02, Irineu escreveu:
> Em 03/04/2012 07:25, Pedro Costa escreveu:
>> Pessoal este update retorna apenas números inteiros apesar de o campo
>> percentagem ser double precision:
>>
>>
>> update estac
Em 03/04/2012 07:25, Pedro Costa escreveu:
> Pessoal este update retorna apenas números inteiros apesar de o campo
> percentagem ser double precision:
>
>
> update estacionamento
> set percentagem = ((select count (n_passeio) from passeios where
> estacionamt =4)*100)/(select count(n_passeio)from p
Pessoal este update retorna apenas números inteiros apesar de o campo
percentagem ser double precision:
update estacionamento
set percentagem = ((select count (n_passeio) from passeios where
estacionamt =4)*100)/(select count(n_passeio)from passeios)
where classe like '4';
Já experimentei tamb
25 matches
Mail list logo
