Программисты, хелпМИ!
6 сообщений
#17 лет назад
Ситуация такая - при обновлении страницы данные опять повторно записываюся в базу. =( Как быть был на других форумах все говорят что разбей форму и скрипт на отдельные страницы =(, а этого ненадо =)<html>
<head>
<title>1</title>
</head><body>
<?php
$host="localhost";
$mn="root";
$mp="root";
$db="reg_user";
if ($_POST == "Submit"){
$error=true;
if($_POST==""){
echo "введите свое Имя<br/>";
$error=false;
}else{
$name=$_POST;
}
If($_POST==""){
echo "Введите имя пользователя<br/>";
$error=false;
}else{
$uname=$_POST;
}
if($_POST==""){
echo "ведите пароль<br/>";
$error=false;
}elseif(strlen($_POST)<4){
echo "короткий пароль<br/>";
exit;
}else{
$password=$_POST;
}
if($error==true){
$conn=mysql_connect($host,$mn,$mp);
$db=mysql_select_db($db,$conn);
$sql="INSERT INTO users"."(user_name,user_login,user_password) VALUES ('$name','$uname','$password')";
$rs=mysql_query($sql,$conn);
mysql_close($conn);
}
}
?>
<body>
</body>
</html>
6 сообщений
#17 лет назад
Немного непонил ответ =), если возможно можете обьяснить? Unset ($_POST)
6 сообщений
#17 лет назад
Все понял =) unset Функция уничтожает переданную в качестве аргумента переменную
276 сообщений
#17 лет назад
Бред. Пользователь нажмет F5. И у тебя еще запись. Защита от дурака на этот случай после вставки:
header("Location:.....");
exit;
661 сообщение
#17 лет назад
По поводу UNSET -- бред полный.Либо скрипт внесения изменений отделить от скрипта генерации формы(завершить его редиректом, напр через header или script), либо разместить код вставки в БД ДО вывода любой информации в скрипте(т.е. в самом верху, В данном случае) и завершить редиректом(header, script)
1895 сообщений
#17 лет назад
На поле user_name в СУБД поставить нужно атрибут Unique, что будет гарантировать уникальность логинов как и положено бить! Все остальное от лукавого.
276 сообщений
#17 лет назад
Цитата ("MMM_Corp"):На поле user_name в СУБД поставить нужно атрибут Unique, что будет гарантировать уникальность логинов как и положено бить! Все остальное от лукавого.
В данном конкретном случае да. Но возможны случаи когда не возможно использовать уникальность или индекс. Сейчас не помню на вскидку, но сталкивался. Поэтому все же редирект не помешает....
Как я уже сказал я всегда его ставлю при вставке, часто при обновлении и удалении. Просто взял как правило. Код не усложняет, но однажды может сработать в качестве защиты "от дурака"
ЗЫ О, кстати, вставка сообщения на форуме....
1895 сообщений
#17 лет назад
Бивает... я с БД так намучался что мало не показалось, напр. некоторие нештатные ситуации:1. узнать значение autoincrement до вставки, при том что лочить табл. нельзя, и нивкоем случае нельзя резервировать запись, поскольку БД сильно груженная и пробелы не допустимие, (пришлось лезсть в недры транзакций мастдая и лочить запись а не табл.) поскольку много людей пашут на БД
2. подсчитать к-во удалённых записей при delete
3. танци с бубном при необходимости вложенных транзакций когда такой механизм не держит СУБД (напр. MSSQL 2000)
4. ADO + MySQL 4 - асинхронние запроси, жесть так и не поборол, скрипт выполняется больше времени отвала конекта (обычно 3 мин.)
так что ничему не удивляюсь и локти искусал на БД)))
731 сообщение
#17 лет назад
Повторную запись можной обойти разными путями: уникальным значением в Hidden, проверкой в бд (есть ли такая запись) и другими.
276 сообщений
#17 лет назад
Цитата ("MMM_Corp"):
узнать значение autoincrement до вставки, при том что лочить табл. нельзя, и нивкоем случае нельзя резервировать запись, поскольку БД сильно груженная и пробелы не допустимие, (пришлось лезсть в недры транзакций мастдая и лочить запись а не табл.) поскольку много людей пашут на БД
Интересно. Под управлением какой СУБД? Может не стоило использовать автоинкремент?
Менял, что то системное?
1895 сообщений
#17 лет назад
MSSQL 2000, ситуация:есть громадная и очень груженная БД, есть тьма юзеров которые используют БД, есть около 20 серверов которые также работают по разним каналам связи с БД, если покороче то есть куча складок, на каждом свои сервера и общение у них типа "я тебе прислал такой товар откуда то" и т.п., тоесть центрального сервера как такового нету, проблема:
нажал кнопку, вилезло окно, в котором сразу должно бить записан номер накладной (он конечно должен бить уникальним), номер надо видеть сразу, создал накладную, заполнил и только тогда в асинхронном режиме она заносится по серверам куда это нужно, система древняя била и приходилось боротся вот с такими вот требованиями, приходилось понижать уровень транзакции до предела записи (минималный уровень изоляции), таким образом у нас могло сутками висеть незалоченная таблица, а накладную можно било заполнять хоть неделю, напр. здоровая накладная на 100 позиций, конец рабочего дня, отправить её нельзя, поскольку она не заполненная до конца, а домой охота, вот и оставляют компи включенними, но при этом ежедневно нужно одчитиватся какаие накладние проходили а какие нет, одно дело когда идет учёт по електронним видам связи а другое когда фура приезжает на склад, а охраник не пускает потому что у него такой накладной по бумагам нету, вот и пляски)
вот где мозговим штурмом решали данную проблему: ссылка
вложенные транзакции:
опять таки из песни "нагруженние сервера", напр. мне надо отправить 1 накладную на 5 серверов, и если хоть на 1 сервере информация не обработается составить в БД отправителя нужную пометку, работа асинхронная, тоесть чел. нажал кнопку и оно пошло по каналам, а чел. спокойно дальше работает, а в конце робочего дня может проверить что обработалось а что нет, мне сложно вспомнить все ньанси данной необходимости но фишка била в том что канали узкие, инфи много и нужно контролировать гарантирован ость доставки информации, поскольку сервера били не в кластере и даже диалапние, то приходилось решать такие вот достаоогчно сложние моменти иногда даже месяцами пока все не будет оточено до мелочей, поскольку любой промах это потеря целестности бехгалтери, пробели в товаропоставках и пр., приплюсуйте к этому большое предприятие, большие нагрузки на сервера, узкие каналы, сроки на вчера, руки новичков студентов которые учились работая с такими системами и получите тону удовольствия)
или вот более простой и понятний пример:
напр. надо мне сделать записи в акскадную аблицу, есть хранимка для записи в мастер-табл. и есть хранимка для записи в каскадную-табл. обе конечно под транзакциями, написал хранимку которая записивает этии данние, тоже под транзакцией, ну в ней конечно 2 предидущие, напр. тот же 2000 MSSQL не даст использовать вложение транзакции, а мне надо гарантировано записать в мастер и в каскад, но если чтото не срослось то откать все изменения, думаю так будет более понятней
вот в таком вот месеве я проработал почти 3 года)
626 сообщений
#17 лет назад
Autoincrement - это костыль. Надо использовать последовательности и будет вам счастье.
276 сообщений
#17 лет назад
Цитата ("MMM_Corp"):MSSQL 2000, ситуация:
есть громадная и очень груженная БД, есть тьма юзеров которые используют БД, есть около 20 серверов которые также работают по разним каналам связи с БД, если покороче то есть куча складок, на каждом свои сервера и общение у них типа "я тебе прислал такой товар откуда то" и т.п., тоесть центрального сервера как такового нету, проблема:
нажал кнопку, вилезло окно, в котором сразу должно бить записан номер накладной (он конечно должен бить уникальним), номер надо видеть сразу, создал накладную, заполнил и только тогда в асинхронном режиме она заносится по серверам куда это нужно, система древняя била и приходилось боротся вот с такими вот требованиями, приходилось понижать уровень транзакции до предела записи (минималный уровень изоляции), таким образом у нас могло сутками висеть незалоченная таблица, а накладную можно било заполнять хоть неделю, напр. здоровая накладная на 100 позиций, конец рабочего дня, отправить её нельзя, поскольку она не заполненная до конца, а домой охота, вот и оставляют компи включенними, но при этом ежедневно нужно одчитиватся какаие накладние проходили а какие нет, одно дело когда идет учёт по електронним видам связи а другое когда фура приезжает на склад, а охраник не пускает потому что у него такой накладной по бумагам нету, вот и пляски)
Ну, принципиально для подобного интербейзный генератор подходит. Я запрашивал его очередное значение, и потом уже вставлял вместе с этим Id....
Больше даже интересует как дыры избегать (впрочем на sql.ru еще не глядел, щас туда пойду). Ведь (как я понимаю) может быть и такая ситуация : накладная висела, а потом работник сказал а ну ее нафиг. (ну или тупо комп клиента сдох за эту неделю) А id уже "забит" под нее.... И следующие десятка 2....
Хм. Про такой вид распределенности я не задумывался..... У меня для этого репликации (но в моем случае репликации достаточнов одну сторону с последующим копированием базы (да и то не во сех случаях) Хотя интересно.