|
|
|
| т.е. то что будет вставлено в поле пробовал MAX(`id`) select LAST_INSERT_ID() from `entries`; не то | |
|
|
|
|
|
|
|
для: Красная_шляпа
(20.12.2010 в 22:41)
| | троллим помаленьку, чтоли?
SQL-сервер обслуживает (может обслуживат ь, обязан уметь обслуживать без отказов) сразу несколько подключившихся клиентских соединений, от прикладных процессов исполняющихся параллельно.
Текущее значение счетчика автоинкремента не несет смысла, потому что в любой момент может быть изменено фактом вставки очередной строки запросом параллельного процесса.
Для данного потока запросов прикладной программы имеет смысл только уже вставленное значение - оно и возвращается в LAST_INSERT_ID()
Для административных нужд это значение извлекается DAL-оператором SHOW вместе со всем кодом таблицы, либо SELECT -запросом к псевдоБД INFORMATION_SCHEMA сервера. | |
|
|
|
|
|
|
|
для: Trianon
(20.12.2010 в 23:40)
| | вообщем я сейчас объясню зачем мне это нужно. я пишу бложик для себя. решил добавить возможность загрузки картинок. чтобы не захламлять жесткий диск, создал таблицу с атачами которая содержит всего два поля номер записи и имя загруженного файла. при редактировании всё ок. а вот добавлении файлы загрузили а запись не добавили файлы занимают место удалить нельзя. а так файлы будут привязаны к следующей записи и не потеряются. | |
|
|
|
|
|
|
|
для: Красная_шляпа
(21.12.2010 в 00:59)
| | (совсем параноиком стал, прости господи...)
Нельзя так. Так Вы рискуете влепить двум файлам один и тот же id .
Можно сколько угодно говорить о вероятностях, но это решение нечестное.
Если есть возможность сделать честно, я бы сделал именно так.
честное решение будет гарантировать невозникновение такой ситуации в принципе.
И тем греть душу. :)
Можно, конечно, плюнуть на честность, сэкономить на дополнительной таблице, и сделать как тянет.
Решать Вам. | |
|
|
|