Создаю запись с помощью SqlConnection, SqlCommand, SQL = "INSERT INTO...."
А как узнать то какой ID у записи то    ? 

Легко 


Ну и дальше вызывай ExecuteScalar() для твоего SqlCommand. 

Дрон, а это для какой БД? 

Какая БД?

Можно так:
 

Так нельзя. Не факт, что максимальный ИД будет последним. 

Дрон, спасибо за подсказку..

Прочитал про ExecuteScalar.

Осталось не понятным SELECT SCOPE_IDENTITY(). Это для чего?(Что это?) 

Чаще всего записи добавляются с ID равным NULL, поэтому максимальный ID будет последним.
Но если известно, что в приложении записи добавляются с ID отличным от NULL, тогда да нельзя, а если нет - то этот способо будет универсальным для любой БД. 

Пользуемся поиском 
http://forum.vingrad.ru/index.php?showtopic=96271
А в двух словах именно этим запросом мы и получаем последний сгенерированный ID-шник 
ExecuteScalar нужен только для того, чтобы иметь возможность вернуть его тебе. Обычно ведь INSERT выполняется методом ExecuteNonQuery.
Можно, конечно, ещё возвращать через output параметр и часто так и приходится делать, но в простом случае сойдёт и ExecuteScalar.


Поскльку вопрос про SqlCommand -- то и сервер будет MS SQL Server 
  

Это сообщение отредактировал(а) Дрон - 11.7.2006, 18:17

Если применяешь MSSQL лучше в качестве ID-шника брать тип UNIQUEIDENTIFIER. Имхо удобней.
А там и хранимку написать не проблема.
 

Softaz, да ну?!?! Где ты такое нашёл?

Во-первых, если это будет Primary Key, то при каждом инсерте будет переколбашиваться вся таблица, т.к. новый гуид не обязательно больше предыдущего.
Во-вторых, guid занимает больше места в памяти и его сравнение сложнее, следовательно join с такой таблицей будет работать медленее.
В-третьих, зачем изобретать велосипед, если есть нормальные identity поля и нормальная функция SCOPE_IDENTITY()?
  

Это сообщение отредактировал(а) Дрон - 13.7.2006, 08:47

Обходится быстро и легко.


Индекс строится по ключевому полю, т.е. по Guid, а он длиннее. Следовательно, ДПС будет больше работать. Память здесь ни при чем.


Ага. Только заметно это будет где-то с миллиона записей. А если идет выборка из 20 таблиц с 10 млрд. строк из пары БД. Бедный int  (загнул, конечно, но смысл ясен)


Он изобретен M$, значит, оным не является. Все же уникальность в 2^64 неплохая. И в DataSet можно спокойно его записать, не боясь, что на сервере уже есть такой и возникнет исключение.
И синхронизация с репликацией проще.
 

С этим согласен. Ну, и естественно 32-битного int на долго тоже не хватит 
Но использование гуида для обычных таблиц -- это, на мой взгляд, редкостное извращение.
 

Да. Для хранения настроек программы типа "последние файлы" - это очень редкостное извращение   

Всем спасибо. 

а как быть если субд firebird?