Pois é, como eu gostaria que você estivesse certo.Ficamos sabendo disso na
semana passada e foi um surpresa, inclusive nosso departamento fiscal entrou
em contato com SEFAZ-MG e confirmou. Dê uma olhada no item 4 que eu
transcrevo abaixo:
Oi pessoal... eu já resolvi. Eu havia criado uma variável com o mesmo nome do
campo da tabela.
De: Jean Domingues [mailto:[EMAIL PROTECTED]
Enviada em: quarta-feira, 19 de novembro de 2008 15:29
Para: pgbr-geral@listas.postgresql.org.br
Assunto: [pgbr-geral] Bug em pgPLSQL
Oi pessoal,
Inicialmente gostaria de agradecer a ateno.
Leandro DUTRA escreveu:
2008/11/19 Marlon David de Souza [EMAIL PROTECTED]:
Gostaria de saber se um problema de lentido (em consultas) poderia
ser atribudo ao fato de estar sendo usado uma verso do Postgres que
no est homologada para
Uma idéia é usar o DBLINK e vc conseguirá fazer tudo diretamente do
POSTGRESQL
[]´s
2008/11/19 Alexsandro Haag [EMAIL PROTECTED]
Pode simplesmente também instalar o Driver ODBC do PostgreSql no
Windows, criar uma entrada ODBC para a sua base, abrir o Access, clicar
com o botão direito sobre
Le 2008 nov. 20 à 07h57, Adriano Espinoza de Oliveira a écrit :
A numeração utilizada pela NF-e será distinta e independente da
numeração utilizada pela Nota Fiscal em papel. Ressalte-se que a NF-
e é uma nova espécie de documento fiscal:o modelo da NF-e é 55 e
os modelos das Notas
Le 2008 nov. 20 à 09h3, José Mello Júnior a écrit :
Uma idéia é usar o DBLINK e vc conseguirá fazer tudo diretamente do
POSTGRESQL
DBI Links?
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]
Le 2008 nov. 20 à 09h36, Marlon David de Souza a écrit :
- Já fiz o tunning do Post nessa máquina.
Você fez alguns ajustes, mas não completo, porque você não analisou
as
consultas específicas.
Concordo que é possível melhorar a consulta usada. No entanto, o que
acontece, é que rodando
Em 20/11/08, Marlon David de Souza[EMAIL PROTECTED] escreveu:
Inicialmente gostaria de agradecer a atenção.
Leandro DUTRA escreveu:
2008/11/19 Marlon David de Souza [EMAIL PROTECTED]:
Não, essa homologação afeta apenas o suporte pela Red Hat, não o
desempenho.
É o que eu também penso.
E
Bom Dia Pessoal...
Estou com um problema... estou fazendo um bakup das informacoes pelo pg_dump...
porem quando chega a um determinado registro ele da erro e aborta o backup...
eu sei o numero do registro... gostaria de saber como faco para saber o
conteudo desse registro tipo Um select
Apoio essa abordagem. Migrar para o postgresql via ODBC é relativamente
simples (caso tenha familiaridade com o access). Tivemos *cases* bem
sucedidos utilizando essa abordagem pegando do SQLServer e colocando no
MySQL e Postgresql.
2008/11/19 Alexsandro Haag [EMAIL PROTECTED]
Pode
Leandro, realmente é problema de modelagem, se você ler direito meu texto,
escrevi isso na segunda linha.
O sistema é antigo... e bla bla bla!!!
Minha dúvida e solicitação de ajuda não é sobre isso!
Adriano
2008/11/20 [EMAIL PROTECTED]
Le 2008 nov. 20 à 07h57, Adriano Espinoza de Oliveira a
[EMAIL PROTECTED] escreveu:
Le 2008 nov. 20 09h36, Marlon David de Souza a crit :
- J fiz o tunning do Post nessa mquina.
Voc fez alguns ajustes, mas no completo, porque voc no analisou
as
consultas especficas.
Concordo
Marlon David de Souza escreveu:
O Load Average varia entre 1.3 e 1.8 (isso com 60 conexões, porém
executando somente essa consulta em questão). Mesmo assim a consulta
leva entre 6 a 8 minutos. Como eu já disse essa mesma consulta, na
mesma base, porém em outra máquina mas com CPU Xeon mais
Emerson Casas Salvador escreveu:
Marlon David de Souza escreveu:
O Load Average varia entre 1.3 e 1.8 (isso com 60 conexes, porm
executando somente essa consulta em questo). Mesmo assim a consulta
leva entre 6 a 8 minutos. Como eu j disse essa mesma consulta, na
mesma base,
Conside criar o campo série e colocá-lo como parte da chave natural, uma vez
que mesmo no sistema tradicional sempre pode o Fisco mandar iniciar as NF do
zero e a previsão para a numeração está limitada a 6 dígitos.
[]´s
2008/11/20 Adriano Espinoza de Oliveira [EMAIL PROTECTED]
Leandro,
Adriano Espinoza de Oliveira escreveu:
Leandro, realmente é problema de modelagem, se você ler direito meu
texto, escrevi isso na segunda linha.
O sistema é antigo... e bla bla bla!!!
Minha dúvida e solicitação de ajuda não é sobre isso!
Amigo Adriano,
Entendo bem esse seu dilema... já
Marlon David de Souza escreveu:
Emerson Casas Salvador escreveu:
Marlon David de Souza escreveu:
O Load Average varia entre 1.3 e 1.8 (isso com 60 conexes, porm
executando somente essa consulta em questo). Mesmo assim a consulta
leva entre 6 a 8 minutos. Como
José, A numeração de NFe, vai até 9 digitos de 1 a 999.999.999.
Já consideramos colocar a série, mas a quantidade de alterações é tamanha
que essa solução acabou por se tornar inviável.Até porque o risco de algum
lugar ficar sem a alteração necessária nos joins, vai causar erros de
acumulo e etc..
Fazer uma conexão ODBC para o PostgreSQL... entrar no Access e mandar
exportar.
[]s
Claudimir Zavalik
Prezados,
Preciso passar um banco do Acess para o Postgres, algum sabe alguma forma
de
eu fazer isso?
Desde já agradeço!
___
pgbr-geral
2008/11/20 Marlon David de Souza [EMAIL PROTECTED]:
Não. A máquina do cliente tem um SCSI. Já a máquina que eu usei para testes
possui um SATA.
Isso faz toda a diferença, inclusive em consumo de processador.
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040
2008/11/20 Marlon David de Souza [EMAIL PROTECTED]:
Fiz isso e aparentemente o problema está na CPU. Ao executar a consulta,
inicialmente os dados são lidos do HD (somente da primeira vez, pois da
segunda ele pega do shared_buffers), mas a demanda é pequena. Depois disso
existe somente
Leandro DUTRA escreveu:
2008/11/20 Marlon David de Souza [EMAIL PROTECTED]:
Fiz isso e aparentemente o problema est na CPU. Ao executar a consulta,
inicialmente os dados so lidos do HD (somente da primeira vez, pois da
segunda ele pega do shared_buffers), mas a demanda pequena.
Olá!
Não dá para resolver com limit e offset?
Abraços
André
2008/11/20 Seta Digital - Suporte [EMAIL PROTECTED]
Bom Dia Pessoal...
Estou com um problema... estou fazendo um bakup das informacoes pelo
pg_dump... porem quando chega a um determinado registro ele da erro e aborta
o backup...
2008/11/20 Marlon David de Souza [EMAIL PROTECTED]:
corta
Mas, no caso, a que usa o SATA é 3x mais rápida!
Como assim? os SAS de 15k que tenho aqui NUNCA serão mais lentos,
mesmo com uma controladora tosca...
--
Sebastian SWC
http://sebastianswc.com
http://www.postgresql.org.br/
2008/11/20 Marlon David de Souza [EMAIL PROTECTED]:
corta
Mas isso não se torna perigoso (queda de luz, etc)?
deixo uma pergunta tentar responder a sua: pra que servem os no-breaks
e os discos redundantes?
--
Sebastian SWC
http://sebastianswc.com
http://www.postgresql.org.br/
2008/11/20 Marlon David de Souza [EMAIL PROTECTED]:
Eu uso ext3fs sem jornalização de dados, apenas metadados.
Mas isso não se torna perigoso (queda de luz, etc)?
O elefante lembra...
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7344 gTalk:
Olá,
Você tem a coluna oid ativa na sua tabela?
SELECT oid,* FROM tabela WHERE atributo='registro';
ou
SELECT ctid,* FROM tabela WHERE atributo='registro';
Espero ter ajudado.
[]s
2008/11/20 Andre Vargas [EMAIL PROTECTED]:
Olá!
Não dá para resolver com limit e offset?
Abraços
André
Sebastian SWC escreveu:
2008/11/20 Marlon David de Souza [EMAIL PROTECTED]:
corta
Mas, no caso, a que usa o SATA 3x mais rpida!
Como assim? os SAS de 15k que tenho aqui NUNCA sero mais lentos,
mesmo com uma controladora tosca...
Justamente porque o problema no
2008/11/20 Marlon David de Souza [EMAIL PROTECTED]:
corte
Justamente porque o problema não está no acesso aos dados e sim de
processamento.
Que mal pergunte, esse RH é 64 bits? já cogitou a idéia de colocar um
debian no lugar dele?
--
Sebastian SWC
http://sebastianswc.com
2008/11/20 Marlon David de Souza [EMAIL PROTECTED]:
Justamente porque o problema não está no acesso aos dados e sim de
processamento.
Qual desses[1] processadores é o seu?
PS: Para selecionar o seu, filtre 2 cores e 2mb de cache size...
[1]
Sebastian SWC escreveu:
2008/11/20 Marlon David de Souza [EMAIL PROTECTED]:
corte
Justamente porque o problema no est no acesso aos dados e sim de
processamento.
Que mal pergunte, esse RH 64 bits? j cogitou a idia de colocar um
debian no lugar dele?
Sim, de
2008/11/20 Marlon David de Souza [EMAIL PROTECTED]:
corte
Sim, é de 64bits e o Postgres foi compilado nele.
E quanto ao debian? é viavel?
--
Sebastian SWC
http://sebastianswc.com
http://www.postgresql.org.br/
___
pgbr-geral mailing list
Sebastian SWC escreveu:
2008/11/20 Marlon David de Souza [EMAIL PROTECTED]:
Justamente porque o problema no est no acesso aos dados e sim de
processamento.
Qual desses[1] processadores o seu?
PS: Para selecionar o seu, filtre 2 cores e 2mb de cache size...
[1]
Hello all,
Steve Howe wrote:
Existe a opção de seria usar DECLARE [1] /FETCH [2] para retornar os
resultados em conjuntos menores. Há algumas APIs que fazem isso
automaticamente, dependendo é claro da linguagem de acesso utilizada.
Ainda assim o PostGreSql executaria primeiro o
Senhores(as),
Meu nome é Armando Roque Ferreira Pinto, sou analista e fã do software
livre. Já acompanho as duas listas, pgbr e postgresql, a algum tempo.
Bom vamos ao que interessa, nunca havia instalado o PG pelo
EnterpriseDB e ao fazê-lo ocorreu normalmente. Criou o usuário
postgres certinho,
Le 2008 nov. 20 à 21h26, Armando Roque a écrit :
Bom vamos ao que interessa, nunca havia instalado o PG pelo
EnterpriseDB e ao fazê-lo ocorreu normalmente. Criou o usuário
postgres certinho, tudo tranquilo até o término.
Mas quando solicitava para iniciar o processo do PG, tanto pelo
serviço
Certo senhores!
Gostaria primeiramente de agradecer a todos pelas informações
disponibilizadas.
Só gostaria de saber como faço para usar DECLARE e FETCH em uma consulta
simples, como por exemplo,
select * from tabela.
Obrigado, mais uma vez!
Fabrício Veiga
2008/11/20 Steve Howe [EMAIL
37 matches
Mail list logo
