Cadastro De Membros

[[ GuTo ]]

Fala Galera!

Antes de mais nada informo que fiz uma busca aki no fórum e não encontrei nada parecido

Todos vocês conhecem o campo de autonumeração do ACESS né.

Então, sabem que a contagem dele não foi feita pra fazer um numero de 1 até digamos 5000 (5 mil) sem ter nenhuma "brecha", ou seja, sem por exemplo no meio contagem faltar o número 3000, por exemplo. Isso também quer dizer que não vai ter exatamente os 5mil registros, mas sim os 4999 registros, se apenas estiver faltando um.

Pois então, no site que tenho é comum a cada 5 registros eu ter de excluir um registro, dae fica esta falha no BD, essa "brecha".

Então, como eu poderia resolver isso?

No caso para poder fazer uma contagem correta, sequencial, ex.:

1,2,3,4,5,6,7,8,9,10...

Não quero deixar falhas, ex.:

1,2,3,8,9,18,19...

Alguém saberia fazer pra consertar isso? Só sei q na tabela eu ia ter de ter o campo do tipo Número , e não AutoNumeração!

Aguardo respostas...

[Victor]

' date='May 5 2004, 10:51 AM'] Pois é... o BRINKSTER é q dá problema...em casa funciona tranqüilo...

na libihost funcionava direitinho...

Aff.. por isso q to pensando em comecar a pagar um servidor...

Aqui também ta dando uns errinhos!!!

[mariofdf]

Pessoal boiei legal...

Não estou encontrando aonde o guto postou a função...

Ou ele não postou?

[[ GuTo ]]

Pessoal boiei legal...

Não estou encontrando aonde o guto postou a função...

Ou ele não postou?

Ae mario

Eu voltei com este meu antigo tópico porque queria ajudar à todo mundo pegar a lógica da coisa e criar uma função igual a esta minha...

Se você ler todo tópico já vai aprender... Eu disse, comentei, e falei muito já sobre a função... é só transparece-la em código asp..

Se tu quiser começar a fazer a função e vir aki postando como anda indo e dizendo alguma dúvida, eu vou te dando as dicas e td mais... é facinhu brother.

Ah... se alguém me ver online aki no fórum, principalmente na madrugada, pede por PM pra mim o URL do sisteminha QUE ESTÁ NO MEU PC, q dae dá pra ver sem aqueles erros q acontece no brinkster, valeu.

O 'desafio' ainda está de pé...

keria ver se alguém mais consegue fazer...

obs.: eu não vou postar a funcao q eu fiz enqto ninguém conseguir fazer uma com sucesso e eu ver, valeu... quero ensinar, ajudar, não dar nada de mão beijada.

[Victor]

Tipo, eu criei um usuario la, quando fui deletar deu isso:

Microsoft JET Database Engine error '80004005'

Could not delete from specified tables.

/chatcanoas/id/delete.asp, line 27

Dá uma olhada la, e depois fala o que estava errado la!!!!

falou brother !!!

[]'s

Victor

[[ GuTo ]]

É O SERVIDOR DO BRINKSTER QUE ESTÁ ERRO, JÁ DISSE...

Quem entrar na net pela madrugada, como eu, pode pegar meu icq/MSN ou mandar uma MP aki pelo fórum pedindo pra ver este sistema q eu passo a URL pra ver o que tá aki no meu pc, não tem erro..

Antes quando estava na libihost.net não dava erro algum...

É isso...

E quanto a função, nem você Victor vai tentar realizar?

[Victor]

' date='May 6 2004, 04:38 AM'] É O SERVIDOR DO BRINKSTER QUE ESTÁ ERRO, JÁ DISSE...

Quem entrar na net pela madrugada, como eu, pode pegar meu icq/MSN ou mandar uma MP aki pelo fórum pedindo pra ver este sistema q eu passo a URL pra ver o que tá aki no meu pc, não tem erro..

Antes quando estava na libihost.net não dava erro algum...

É isso...

E quanto a função, nem você Victor vai tentar realizar?

Essa que você falou para ir juntandos os numeros diferentes?? Tipo tem o 123, eu escluo o 2 e o numero 3 vai para 2... É isso?? Se for vou ver se arrumo tempo para fazer!!!

Fuii

[]'s

Victor

[Lucky]

Alô pessoal, como nosso amigo disse acima, muita gente boa anda sumida deste Fórum... (até eu heim..)

Gostei do desafio embora parte de um pressuposto totalmente errado:

NUNCA se muda o ID, melhor, não interessa o ID, esta é uma informação interna do próprio banco, é a "chave única" que permite que cada registro seja único, portanto ela não foi feita para ser exatamente "sequencial" mas apenas para "nunca ser repetida"... (ID vem de "identificador")

Primeiro: quando tu apaga um registro no banco, na verdade o banco não o "apaga" de verdade, apenas marca ele como "apagado" e o registro continua ali, quietinho, inteirinho, usando exatamente o mesmo espaço no hd... (é possível até recuperá-lo)...

O banco não o apaga por causa do "desempenho", afinal apagar pra quê? (para abrir brechas físicas dentro do arquivo do banco no hd e deixar ele fragmentado?) Assim, basta marcá-lo como apagado... Este registro somente será excluído com a compactação do banco, que criará uma nova cópia do banco pegando somente os registros não apagados.... é por isso que um banco "compactado" geralmente é menor que seu original antes da compactação, isso não tem a ver com a compactação dos dados em si mas sim com a eliminação dos dados "mortos"...

Como usamos o ID como "chave de indexação", a senha que identifica aquele registro especificamente, ela jamais pode ser mudada para aquele registro ou de que adiantaria guardar IDs? A função deles é que registros em tabelas diferentes podem ser RELACIONADOS pelos seus IDs, assim o cliente 01 da tabela [clientes] tem seus dados de cobrança na tabela [endereços] relacionados a ele pelo seu ID: 01. Se tu mudar o ID dele, não teria o menor sentido estar usando bancos de dados RELACIONAIS como os que usamos...

Na verdade, se a função do ID não é importante (digamos que tu está mostrando uma lista de músicas, numerada, como a que aparece no playlist do winamp) e tu queira reordenar esta lista quando exclui um registro (uma música) daí tu apenas inicializa um contador em zero e soma um para cada item mostrado na tela... nada de gravações no banco, gravar prá que se tu não vai usar este campo mesmo, nem pode usar pra nada pois pra cada alteração no banco ele mudaria...

Repetindo, se tu quer a lista numerada, esqueça o banco, numere apenas ao mostrar os dados na tela via "response.write contador+1" em asp...

Se tu quer reordenar o banco, crie uma nova tabela (com uma autonumeração zerada) e copie os dados da tabela antiga (nem todos os bancos permitem fazer isso on-the-fly). Embora na verdade isso é loucura - imagina uma tabela com dez mil registros que deve ser copiada cada vez que um registro é apagado - mas é infinitamente melhor que alterar o tal "ID" de cada um destes registros individualmente...

Na verdade, por questão de desempenho o ACCESS não vai alterar o registro original gravado mas vai fazer uma nova cópia dele, já alterado, e marcar (no seu índice interno) a antiga original como "apagada"... sacou? agora imagina como ficaria o tamanho deste banco em poucos dias de operação?

Desculpem a moral, mas talves ajude a vocês descobrirem que nem sempre uma idéia brilhante é a mais adequada...

Um abraço

Lucky

[dark0]

Olá Lucky!

Parabéns pelos comentários.. Falou tudo!

Algumas coisas que você falou, eu concordo!

Mas ola só.. A idéia de um script.. Não seria para mudar os IDS toda vez que um fosse apagado.. E sim.. por ex: Tem 10 registros. O proximo a cadastrar é o 11. Mas você apagou o 3. então, o proximo registro passaria a ser o 3. Isso pra "tapar" aquela brecha que ficou.

Esse era o tema do nosso 2º desafio!

Vide:

http://scriptbrasil.com.br/forum/index.php?showtopic=23983

você pode simplesmente deixar como está sim.. pois, creio que dificilmente o usuário terá acesso à essa numeração que estamos criando, ou tampouco saberá que existe um campo ID.

Não acha?

Mas eu, e acho que talvez mais gente.. gostem de ter seu banco de dados um pouco organizado. Por isso o uso dessa função aí!

Acho que era isso.

Até mais,

dark

[Illidan]

Primeiro: quando tu apaga um registro no banco, na verdade o banco não o "apaga" de verdade, apenas marca ele como "apagado" e o registro continua ali, quietinho, inteirinho, usando exatamente o mesmo espaço no hd... (é possível até recuperá-lo)...

O banco não o apaga por causa do "desempenho", afinal apagar pra quê? (para abrir brechas físicas dentro do arquivo do banco no hd e deixar ele fragmentado?) Assim, basta marcá-lo como apagado... Este registro somente será excluído com a compactação do banco, que criará uma nova cópia do banco pegando somente os registros não apagados.... é por isso que um banco "compactado" geralmente é menor que seu original antes da compactação, isso não tem a ver com a compactação dos dados em si mas sim com a eliminação dos dados "mortos"...

Lucky,

Gostei muito da sua explicação! Não sabia que o db trabalhava assim... então, se você recuperar os registros a partir de um arquivo compactado, sobrariam essas "brechas físicas" no HD, certo?

Pelo o que eu entendi, sim... neste caso, um sistema que reorganizasse os ids seria muito útil... você não acha?

Falou! Um abraço!

[Lucky]

Esse é justamente o xis da questão: o db não vai mexer nunca mais nos dados que já estão gravados, ele apenas vai marcá-los (como inválidos) e gravar a versão mais nova no fim do arquivo (atualizando seu índice interno com a posição deste novo registro). Não interessa se o registro é o 1 ou o 3 ou o 20.000, se ele for alterado, o seu original será invalidado e uma nova cópia será anexada ao final do arquivo do db. O banco não pode sobrescrever um registro porque, fisicamente, ele está entre outros dois e seria impossível que o registro alterado coubesse novamente naquele lugar (fisicamente), digamos que tu escreva um nome a mais num campo de um registro e tente gravá-lo no local original, daí todos os registros após o que foi alterado teriam que ser "empurrados" para que a alteração coubesse ali... (não é assim que funciona...)

O que eu queria alertar é que, embora pra nós possa parecer interessante "organizar os dados" como propoem o desafio, pro banco, internamente, esta operação é extremamente penosa, um verdadeiro suicídio...

Quando tu diz "recuperar os registros em um db compactado" lembro que uma vez que tu compacte o db, todos os registros válidos são copiados para um novo db e o antigo apagado. Somente os dados válidos, os deletados desaparecem pra sempre, não podem mais ser recuperados...

Faça um teste: faça uma cópia de um banco e veja o tamanho do arquivo, depois entre nele e apague alguns (muitos) registros, saia do banco e veja o tamanho novamente...? e tente fazer isso (ver o tamanho) antes e depois de rodar seus scripts de atualização do ID...

Por outro lado, para manter os IDs como propôem o desafio, eu até diria diferente: criaria uma nova tabela só com números e relacionaria ela com os ID originais da tabela inicial, nesta tabela teria uma lista numerada em ordem e para cada número desta lista, um ID correspondente na tabela inicial, onde estão os dados verdadeiros, assim, para cada novo registro, eu gravo o registro normalmente na tabela inicial e associo o seu ID, qualquer que seja, ao primeiro numero válido na ordem da segunda tabela... desta forma tu poderia aplicar a tua rotina numa tabela que só tem dois campos numéricos: O ID do registro na "tabela quente" e o seu "numero adequado"... (É mais o menos isso que o banco faz internamente, quando atualiza seus indices internos com a posição do registro recém incluído) Isso é bem melhor que movimentar uma tabela inteira de dados...

Embora fosse o que o desafio propôem: achar o numero da falha...

Mas o que seria util neste caso é isso:

na hora de DELETAR UM RECORD

-pega o numero do record deletado

-pega o ultimo record da tabela

-atualiza este (o último) com o numero do deletado

Isso vai fazer com que cada vez que um record seja deletado,

imediatamente, o ultimo record da tabela "assume" o seu

número, ficando a tabela sem furos JAMAIS....

Se tu for cadastrar um novo record, ele automaticamente

vai pegar o ultimo número...sacou?

Isso que eu proponho tem a ver com a parte mais importante da

programação, que é a ANÁLISE do sistema... Pra voces

entenderem melhor, não existe faculdade de programação,

programação é uma função técnica, não é um curso superior,

mas existem faculdades de Análise de Sistemas...

Quem bola um sistema não é um programador, é um Analista,

o programador apenas traduz a lógica que o analista

criou para uma linguagem qualquer... é um mero tradutor e

absolutamente, não pode mudar nada dentro da lógica que

lhe foi passada... é como um empreiteiro que constrói uma obra

seguindo as instruções do arquiteto que a bolou... sacaram?

Por isso, quando queremos desenvolver algo novo (daí o termo

"desenvolvedor" que muita gente usa ao invés de programador)

temos que pensar com lógica e não com comandos de linguagem.

O maior erro é começar a desenvolver uma "solução" (problemas

a serem resolvidos, como o desafio proposto precisão de "soluções")

baseados no conhecimento da linguagem de programação que será usada.

isto faz com que ao invés de enxergarmos uma solução dentro da lógica

fiquemos brigando com as limitações da linguagem... Como as linguagens

são feitas para implementar a lógica, se tu só trabalhar nela (na lógica,

no fluxograma do que deve acontecer) depois de ela pronta, cairá como

uma luva na programação...

Chega Lucky... fica escrevendo livros aqui... cara chato...

Um abraço a todos

você resolveu o desafio deixando o código em aberto Lucky... tsc tsc..

Tava dando a resposta para alguns já... o trabalho para eles ficaria menor..

Por isso o editei, beleza...

Editado Junho 3, 2004 por [ GuTo ]

[[ GuTo ]]

quanto a sua idéia de deletar um record é uma boa.

Porém, o último registro já assumir o valor do deletado, ficaria ruim.

Ex.: Este id que foi excluido é da tabela MEMBROS... quando ele foi deletado, no meu sistema, ele deleta todos os dados de todas as tabelas referentes aquele ID.

Logo, se o ultimo registro assumir o valor do ID deletado, eu teria de também dar um update nos ID relacionados a este ultimo ID. O q ficaria ruim, seria muito mais transtorno.

Por isso, somente ocupar a vaga quando um novo registro for incluido.

[Lucky]

Lamento aí Guto mas tu tá doidão... Se tu não atualizar o sistema CADA VEZ que apagar um registro, o que vai acontecer é que se tu apagar um registro, a tua bendita numeração vai ficar com um BURACO, e se tu apagar DOIS registros, mesmo que tu cadastre um cara novo e utilize o ID do primeiro buraco, ainda vai sobrar um buraco... se for para deixar estes buracos eu não entendo o porquê de querer usar esta rotina... esta coisa toda só tem fundamento se tu manter SEMPRE a tua base sem BURACOS né?

[[ GuTo ]]

Desculpe Lucky, mas não estou doidão...

Essa função é pra deixar o bd sem buracos, mas sei que ela poderá ter inúmeros buracos, porém sempre tera menos que qlqr outro site.

[[ GuTo ]]

Olhem só uma coisa que estive pensando.

Imaginem uma tabela de um banco de dados com MUITOS registros?

Nosso loop para descobrir aonde está a brecha, irá demorar muito, pelo que vejo.

Imagine uma tabela com mais de 1.000 registros, já fica "embaçado", como vocês dizem

Então, surgiu-me umas idéias, porém, preciso saber se tem como eu fazer uma delas. Imagino que sim, mas aí vão elas:

1º.:

- Ao apagar um registro, eu poderia gravar este ID num arquivo .txt, que teria o nome desta tabela da qual o registro foi excluído.

- Ao incluir um novo registro nesta tabela, antes verificamos o arquivo txt. Pegamos todo o conteúdo do arquivo txt e pegamos o menor número(Brecha/buraco/ID). Com isso, inserimos o novo registro com este id q pegamos do arquivo txt.

2º.:

- Vejamos um horário de menos trânsito no site, digamos, ali pelas 5h da madrugada.

- Bloqueamos o acesso ao BD.

- Façamos uma verificação em cada tabela que nos interesse no site, e vamos salvando as brechas nos arquivos .txt, com os nomes das respectivas tabelas.

- Liberamos o acesso ao BD.

- Pronto!

- Quando alguém for incluir um registro numa tabela, é pego o ID do arquivo de texto, assindo preenchendo o buraco, deixando tudo perfeitinho!

Tratamento de erros:

- Caso o arquivo de texto esteja vazio, é porque não existe brechas.

Daí como poderíamos dizer qual seria o novo ID de registro?

Enfim, ao que ando percebendo, é bom deixar tudo como auto-numeração / auto-increment e pronto! Sem dores de cabeça, o foda é que vai existir "brechas" no bd. Claro, isso não atrapalha nada o site, só que eu queria que ficasse "bonitinho" o sistema, hehe.

Talvez possamos usar aquela função que eu falei durante o tópico todo, mas apenas para uma tabela pequena, que não contenha muitos dados.

Acho que é isso pessoal!

Com o tempo e experiência, percemos e prevemos futuros problemas.

Agora lá vou eu dar uma reorganizada no site todo.

Abraços!

[Guest Guest]

Tipo, eu criei um usuario la, quando fui deletar deu isso:

Microsoft JET Database Engine error '80004005'

Could not delete from specified tables.

/chatcanoas/id/delete.asp, line 27

Dá uma olhada la, e depois fala o que estava errado la!!!!

falou brother !!!

[]'s

Victor