pg_dump x restore = dados alterados (conteúdo) - conteúdo dos registros alterados

Só uma pergunta: Por acaso alguma de suas tabelas tem como "chave primária" um campo  "auto imcremento"?

  Olá Jair, SIM tenhos varias tabelas com (campo SERIAL e sendo chave primária), inclusive a tabela principal que ocorre este erro tem: segue a estrutura da tabela:   [code] CREATE TABLE heados
(
  id serial NOT NULL,
  data timestamp with time zone,
  usuario integer NOT NULL,
  descontopercent real,
  descontoreal real,
  cliente integer NOT NULL,
  obs text,
  loja integer NOT NULL,
  dataemissao timestamp with time zone,
  usuarioemissao integer,
  emitido character(3),
  dataprova timestamp with time zone,
  datapreventrega timestamp with time zone NOT NULL,
  dataentrega timestamp with time zone,
  turno integer,
  vendedor integer,
  equipto integer,
  acabamento character varying(100),
  dtultimopagto timestamp with time zone,
  CONSTRAINT "idHeados" PRIMARY KEY (id),
  CONSTRAINT "ExtCliente" FOREIGN KEY (cliente)
      REFERENCES clientes (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT "ExtEmrpesa" FOREIGN KEY (loja)
      REFERENCES empresas (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT "ExtUsu" FOREIGN KEY (usuario)
      REFERENCES usuarios (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT "ExtusuEmitiu" FOREIGN KEY (usuarioemissao)
      REFERENCES usuarios (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT extequiphead FOREIGN KEY (equipto)
      REFERENCES equipamentos (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT ntxvendheados FOREIGN KEY (vendedor)
      REFERENCES funcionarios (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH (
  OIDS=FALSE
);
ALTER TABLE heados OWNER TO postgres; -- Index: "fki_ExtCliente" -- DROP INDEX "fki_ExtCliente"; CREATE INDEX "fki_ExtCliente"
  ON heados
  USING btree
  (cliente); -- Index: "fki_ExtEmrpesa" -- DROP INDEX "fki_ExtEmrpesa"; CREATE INDEX "fki_ExtEmrpesa"
  ON heados
  USING btree
  (loja); -- Index: "fki_ExtUsu" -- DROP INDEX "fki_ExtUsu"; CREATE INDEX "fki_ExtUsu"
  ON heados
  USING btree
  (usuario); -- Index: "fki_ExtusuEmitiu" -- DROP INDEX "fki_ExtusuEmitiu"; CREATE INDEX "fki_ExtusuEmitiu"
  ON heados
  USING btree
  (usuarioemissao); -- Index: fki_extequiphead -- DROP INDEX fki_extequiphead; CREATE INDEX fki_extequiphead
  ON heados
  USING btree
  (equipto); -- Index: fki_ntxvendheados -- DROP INDEX fki_ntxvendheados; CREATE INDEX fki_ntxvendheados
  ON heados
  USING btree
  (vendedor);
[code]   é bronca? Obg deste já! at+  

Bem a muito tempo aprendi que este tipo de campo se torna um "grande problema" quando retornado via backup, devido a "re-ordenação dos registros". Independetemente de qual seja o banco ele reiniciava a numeração, no MEU caso quando o mesmo se torna chave, e integridade referencial para outras tabelas uma verdadeira "zorra". Em 1980 deixei de usar este tipo como chave para ordenar os ID sendo reestabelecidos com outros indicadores novos. assim meu cadastro de pessoas que ora COMO exemplo nome "José", codigo '001' foi parar No código "025" fazendo com que os relacionados se tornassem inconsistentes.

E o que você sugere? Vou testar então antes do backup retirar os índices de chave primaria da tabela pra v que dá.

para resolver o problema, fiz um programinha em delphi para copiar todos os dados do banco antigo para o novo assim as datas vinheram corretamente. obrigado a todos!!!

    Como eu mudo o STATUS??? at+