Bom esta funcioando e desta vez o culpado não foi o libreoffice. Pode parecer extranho utilizar o libreofficebase com o posrgresql, mas foi a minha opção para garantir a segurança do banco de dados, uma vez que o banco hsqldb incorporado ao libreoffice base tem apresentado problemas neste quisito. Estou fazendo testes com o libreoffice base com banco externo no postgresql.
Apenas complementando a informação, toda ves que abrir o calc com os dados csv voce obrigatoriamente tem que usar o salvar como para editar as preferencias da gravação ou vai dar erro na hora de importar com o comando copy Em 1 de setembro de 2011 18:07, Guimarães Faria Corcete DUTRA, Leandro < lean...@dutras.org> escreveu: > 2011/9/1 rogerio dandrea <rolemo...@gmail.com>: > > 2011/9/1 rogerio dandrea <rolemo...@gmail.com>: > > > >>É inserção ou atualização? > > > > É inserção de nova linha via comando copy > > Me pegaste, agora. Jurava que era atualização. > > > >> Veja que esse erro se deve ao uso de chave artificial. Se o modelo > >> mantivesse apenas a chave natural, todo o processo seria muito mais > >> rápido, tanto em termos de E/S quanto de resolução de problemas. > > > > Segundo o relacionamento foi criado via > > libreoffice base (talves este seja o problema...rs > > Mas foi o LibreOffice que definiu as chaves? > > > > Vou ler mais a respeito sobre chaves > > artificiais e naturais ( não tenho ideia do que voce esta falando, me > > recomenda algum artigo?) > > O ideal era leres o Date antes de mexeres em bases de dados, mas > tentarei um resuminho. > > Chave natural é um conjunto de dados preexistentes (atributos) que > identifica uma tupla. No teu caso, talvez, se eu não tiver entendido > errado, o atributo nome da raça, que imagino deva existir, seria > perfeito. Com ela, garante‐se a consistência da base de dados no > aspecto unicidade. Mesmo que a chave primária seja artificial, pelo > menos uma chave natural, que pode ser simples ou composta, deve ser > declarada, para evitar inconsistência de dados. > > Chave artificial é um código qualquer definido artificialmente, dentro > do aplicativo, e que não deveria aparecer para o usuário, para > substituir uma chave natural como chave primária. O mais comum é que > seja um número inteiro seqüencial. Geralmente, o uso generalizado de > chaves artificiais é prejudicial tanto para desempenho quanto para > clareza e consistência do modelo, devendo restringir‐se a casos onde a > limitação do ferramental (SQL, linguagem de programação) torne > inconveniente o uso de uma chave natural como chave primária. > > > -- > Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org > +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm > sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
