none
Couldn't Perform the edit because another user change the record RRS feed

  • Pergunta

  • Alguém sabe se fica algum vestígio de uma tabela que é dropada de um banco? Para facilitar caso ela seja recriada por exemplo, e quando digo vestígio é nas entranhas do banco mesmo.

    Estou passando por aquele famoso problema do 'Couldn't Perform the edit because another user change de record' em uma conexão do SQL com o BDE/delphi, e se crio uma nova tabela com outro nome, mas com a mesma estrutura e com os dados da tabela q tem o campo que apresenta o erro, que no caso é um FLOAT, a tabela nova não apresenta o erro.

    Seguindo esse processo, se excluo a tabela que apresentava o erro, e recrio ela com mesmo nome pegando a estrutura da tabela nova que havia criado e repassando os dados também dessa tabela, o erro volta a acontecer.

    Ou seja, o problema só acontece quando crio a tabela com o nome  em que o erro foi apresentado a primeira vez, a única suspeita que me restou foi a de que o banco guarda alguma informação sobre a tabela que foi dropada, e quando é recriada, ele edita seus dados de alguma forma, o que faz apresentar o erro.

    quinta-feira, 10 de setembro de 2015 20:29

Todas as Respostas

  • Aparentemente o problema é semelhante ao descrito no link:

    http://forum.devmedia.com.br/viewtopic.php?t=86446

    http://www.delphigroups.info/2/53/242197.html

    Tente utilizar NUMERIC ao invés de FLOAT.


    sexta-feira, 11 de setembro de 2015 02:37
  • Não posso usar NUMERIC, e as alterações necessárias no Delphi eu já fiz. O problema é banco mesmo, inclusive se eu criar a tabela nova com outro nome, não acontece o erro, mas se eu renomear essa tabela com SP_RENAME, colocando o nome da tabela antiga, acontece o erro. É um beco completamente sem saída.
    segunda-feira, 14 de setembro de 2015 11:47
  • Acredito que seja problema na BDE mesmo.

    Poste como você está definindo as ProviderFlags de cada campo da tabela problemática.

    Sobre fragmentos de dados persistentes em banco SQL Server: as páginas de dados de uma tabela dropada permanecem gravadas até que sejam reutilizadas(sobrescritas), mas para isto precisam estar indicadas como já backupeadas nos mapas internos de backup(BCM e DCM). Caso o recovery model estiver configurado como SIMPLE, as páginas podem ser sobrescritas independente dos valores dos mapas de backup.
    Pelos testes que efetuei o processo Ghost Cleanup não limpa automaticamente dados de tabelas dropadas mesmo quando já backupeadas.
    O SQL Server não reutiliza dados já gravados, mesmo que você crie uma tabela com o mesmo nome, mesma estrutura e mesmos dados, pois altera várias estruturas internas e necessita manter a consistência dos dados.
    segunda-feira, 14 de setembro de 2015 19:55
  • Olá!

       Tente executar este comando, e veja se há algum objeto referenciando esta tabela:

    select * from sys.all_objects where Name like '%SuaTabela%'

    Parece que há alguma trigger sendo disparada. Mas dê uma verificada neste resultado.

    Bom trabalho!


    • Editado Rodrigo CdS segunda-feira, 14 de setembro de 2015 20:39
    segunda-feira, 14 de setembro de 2015 20:39