А как узнать то какой ID у записи то
? | Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Базы данных под .NET > SqlCommand INSERT и INTO.... |
| Автор: Pankon 11.7.2006, 17:41 |
| Создаю запись с помощью SqlConnection, SqlCommand, SQL = "INSERT INTO...." А как узнать то какой ID у записи то ? |
| Автор: Дрон 11.7.2006, 17:49 | ||
Легко 
Ну и дальше вызывай ExecuteScalar() для твоего SqlCommand. |
| Автор: Ignat 11.7.2006, 17:51 |
| Дрон, а это для какой БД? |
| Автор: DemoCode 11.7.2006, 17:53 | ||
| Какая БД? Можно так:
|
| Автор: Ignat 11.7.2006, 17:57 | ||
Так нельзя. Не факт, что максимальный ИД будет последним. |
| Автор: Pankon 11.7.2006, 18:01 |
| Дрон, спасибо за подсказку.. Прочитал про ExecuteScalar. Осталось не понятным SELECT SCOPE_IDENTITY(). Это для чего?(Что это?) |
| Автор: DemoCode 11.7.2006, 18:01 | ||
Чаще всего записи добавляются с ID равным NULL, поэтому максимальный ID будет последним. Но если известно, что в приложении записи добавляются с ID отличным от NULL, тогда да нельзя, а если нет - то этот способо будет универсальным для любой БД. |
| Автор: Дрон 11.7.2006, 18:09 | ||||
Пользуемся поиском http://forum.vingrad.ru/index.php?showtopic=96271 А в двух словах именно этим запросом мы и получаем последний сгенерированный ID-шник ExecuteScalar нужен только для того, чтобы иметь возможность вернуть его тебе. Обычно ведь INSERT выполняется методом ExecuteNonQuery. Можно, конечно, ещё возвращать через output параметр и часто так и приходится делать, но в простом случае сойдёт и ExecuteScalar.
Поскльку вопрос про SqlCommand -- то и сервер будет MS SQL Server |
| Автор: Softaz 13.7.2006, 07:59 | ||||
Если применяешь MSSQL лучше в качестве ID-шника брать тип UNIQUEIDENTIFIER. Имхо удобней. А там и хранимку написать не проблема.
|
| Автор: Дрон 13.7.2006, 08:46 |
| Softaz, да ну?!?! Где ты такое нашёл? Во-первых, если это будет Primary Key, то при каждом инсерте будет переколбашиваться вся таблица, т.к. новый гуид не обязательно больше предыдущего. Во-вторых, guid занимает больше места в памяти и его сравнение сложнее, следовательно join с такой таблицей будет работать медленее. В-третьих, зачем изобретать велосипед, если есть нормальные identity поля и нормальная функция SCOPE_IDENTITY()? |
| Автор: Softaz 13.7.2006, 14:10 | ||||||||
Обходится быстро и легко.
Индекс строится по ключевому полю, т.е. по Guid, а он длиннее. Следовательно, ДПС будет больше работать. Память здесь ни при чем.
Ага. Только заметно это будет где-то с миллиона записей. А если идет выборка из 20 таблиц с 10 млрд. строк из пары БД. Бедный int (загнул, конечно, но смысл ясен)
Он изобретен M$, значит, оным не является. Все же уникальность в 2^64 неплохая. И в DataSet можно спокойно его записать, не боясь, что на сервере уже есть такой и возникнет исключение. И синхронизация с репликацией проще. |
| Автор: Дрон 13.7.2006, 14:51 | ||
С этим согласен. Ну, и естественно 32-битного int на долго тоже не хватит Но использование гуида для обычных таблиц -- это, на мой взгляд, редкостное извращение. |
| Автор: Softaz 13.7.2006, 15:13 | ||
Да. Для хранения настроек программы типа "последние файлы" - это очень редкостное извращение  |
| Автор: Pankon 14.7.2006, 14:03 |
| Всем спасибо. |
| Автор: starostin 4.11.2011, 16:44 |
| а как быть если субд firebird? |
| Автор: CYBERDREAM 5.11.2011, 12:50 |
| Приветствую starostin, Судя поhttp://www.firebirdfaq.org/faq243/ если юзать тригеры для генерации ключей, то можно воспользоваться оператором returning. Вообще насколько я понимаю, немного муторно с ключами в FireBird. С этой СУБД не работал, так что надо тебе попробовать. Так же встречал решение, что генерируют сначала ключ, и его уже пихают в таблицу и возвращают. Знатоки надеюсь поправят. Можешь http://firebirdsql.su/doku.php?id=returningпочитать, может поможет |
