[Resolvido] Cadastrar no banco e ir para a página cadastrada

[JoaoGusmao 2]

deixa eu explicar melhor.

No meu site, tem o cadastro de produtos, e o objetivo é fazer com que o usuário seja redirecionado para a página do produto no mesmo momento que cadastra-lo. Ex: Cadastrei o produto X, que recebeu o id 58. Assim que clicar no botão de cadastrar, eu queria que fizesse o envio ao banco, e ao mesmo tempo buscasse o id que foi gerado, e redireciona-lo para uma url.php?id=58, por exemplo. Como faria isso?

[Andrey Knupp Vital 136]

Simples, você pode utilizar a função header ..

header('Location: http://pagina/do/produto.php?id='.$id);

[Henrique Barcelos 290]

Qual SGBD está utilizando?

Dependendo de qual for, varia bastante para obter o último ID inserido.

 

Se for MySQL, utilize:

$id = mysql_insert_id($conn);

onde $conn é a variável que armazena a chamada de mysql_connect()...

 

Com esse ID em mãos, é fácil redirecionar:

header('Location: url.php?id=' . $id);

[JoaoGusmao 2]

Henrique, e isso vem abaixo ou acima da consulta?

Obrigado.

[Henrique Barcelos 290]

Depois da query de inserção...

[JoaoGusmao 2]

Ok... Funcionou perfeitamente, porém, tem alguma possibilidade de isso embananar, caso haja um grande numero de consultas de diferentes PCs ao mesmo tempo? Por exemplo: 50 pessoas no mesmo segundo enviaram um produto. Tem a chance uma pessoa receber o id do outro??

Obrigado

[Andrey Knupp Vital 136]

NÃO, MySQL utiliza Thread, separa todos os processos, e isso sempre vai pegar o último INSERIDO, e como você só redireciona se inserir, não vai ter problemas.

[JoaoGusmao 2]

Então, utilizando Mysql eu nunca terei problemas do tipo de juntar duas consultas de usuarios diferentes?

[Andrey Knupp Vital 136]

Never .. pode ficar na boa quanto a isso.

 

mysql> use app;
Database changed
mysql> create table aTest ( id integer ) ;
Query OK, 0 rows affected (0.04 sec)

mysql> insert into aTest values ( 1 ) ; insert into aTest values ( 2 ) ;
Query OK, 1 row affected (0.01 sec)

Query OK, 1 row affected (0.00 sec)

mysql> select * from aTest;
+------+
| id   |
+------+
|    1 |
|    2 |
+------+
2 rows in set (0.00 sec)

mysql> alter table aTest change column id id integer primary key auto_increment;
Query OK, 2 rows affected (0.06 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> select * from aTest;
+----+
| id |
+----+
|  1 |
|  2 |
+----+
2 rows in set (0.00 sec)

mysql> insert into aTest values ( null ) ; insert into aTest values ( null ) ;
Query OK, 1 row affected (0.00 sec)

Query OK, 1 row affected (0.00 sec)

mysql> select * from aTest;
+----+
| id |
+----+
|  1 |
|  2 |
|  3 |
|  4 |
+----+
4 rows in set (0.00 sec)

mysql>

[JoaoGusmao 2]

Ok. brigadão ae pela ajuda pessoal.

Abraços

[Henrique Barcelos 290]

Só explicando um pouco melhor...

 

Thread é uma 'linha de execução' de uma determinada tarefa. Elas podem estar ligadas a um mesmo programa ou a programas diferentes.

 

Por que os servidores Web utilizam threads?

Porque seu uso permite a execução de várias tarefas em simultâneo. Imagine que existam 10 tabelas em seu banco de dados. São feitas 10 requisições simultâneas ao servidor, cada uma envolvendo uma tabela diferente.

 

Se o servidor tivesse acesso sequencial, sem utilizar threads, seria muito mais demorado atender as 10 requisições, pois cada uma teria que esperar sua antecessora terminar.

 

Entretanto, isso não faz o menor sentido, uma vez que elas vão se utilizar de dados distintos, é possível e desejável que se execute essas 10 requisições com o maior paralelismo possível.

 

Então, toda vez que o servidor recebe uma requisição, ele duplica uma thread "modelo" para um certo tipo de requisição e dispacha aquela requisição para a thread criada. Chegou outra requisição? Duplica de novo e despacha... E assim por diante.

 

Claro que threads em execução utilizam memória. Se o servidor tiver uma configuração ruim, não vai ser capaz de atender muitos acessos simultâneos e aí o servidor cai.

 

A utilização de threads para acesso ao banco de dados gera um problema: e se duas threads precisarem escrever simultaneamente dados em uma mesma tabela?

Isso gera a chamada "race condition", ou "condição de corrida". No estudo de Sistemas Operacionais em cursos da área, como Eng. da Computação, Ciência da Computação, Análise de Sistemas, etc., aprendemos como lidar com a "race condition" através de métodos para sincronismo e isolamento de dados compartilhados.

 

Sem me ater muito a detalhes técnicos, basicamente o que se faz é impedir que duas threads modifiquem um mesmo dado ao mesmo tempo. Normalmente, a primeira thread precisa solicitar permissão do SGBD para alterar aqueles dados obtém uma "trava" sobre eles. Todas as outras threads que tentarem pedir tal permissão vão ser bloqueadas até que a primeira libere a "trava". Esse tempo de espera não deve ser infinito, se não temos uma condição chamada "starvation", ou "morrer de 'fome'".

 

O SGBD se encarrega de garantir todas essas condições que eu citei acima, de forma invisível ao programador, então não é necessário se preocupar com isso, esse tipo de problema não é esperado que aconteça. Não posso dizer que NUNCA acontece, mas que é extremante raro, é. Eu nunca tive problemas do tipo.

[Andrey Knupp Vital 136]

Vote Up, explicação bacana .. parabéns !