> Например,  если есть поле ДатаВремя создания записи - найти
> свой ИД по нему


Не получится.

> Не получится.

У меня получалось.  Но без изящества.

> У меня получалось.


Это просто повезло. На равенство DateTime сверять - глупо, надо на больше-равно - меньше-равно. А так - высока вероятность того, что кто-то ещё кроме тебя успеет это захватить.
В общем, не получится так.

d := now(); ... insert ... select или look
безо всяких больше либо...
строго равно! до долей секунды
и все получается.

> и все получается.


Тебе просто повезло.
1. Ты ещё, похоже, не натыкался на проблему с синхронизацией времени в сети.
2. Ты ещё, похоже, не натыкался на проблему с переходом на зимнее время.

Для подобных дурных подходов есть аппробированое решение - поиск сравнение по всем полям, реализовано в DB.VCL если не применять особых методов, условие не использовать никаких идентифицирующих полей, главное удалить ПК если он есть.

Подход так себе, через голову.О чем сразу было сказано.
Но работает.
И везение не при чем. Пришлось морщить лоб.
В том случае еще имелось поле Autor, поэтому захватить чужую запись с таким же временем (буде повезет) проблематично.

> и все получается.

Везет.

> Ega23 ©   (30.07.08 10:44) [24]

3. и не понимает устройства типа TDateTime
4. и не понимает принципов работы с плавающей запятой
5. и не понимает принципов работы SQL серверов, где (Fld = Value) <> Value

>Нат
Искать по времени свой ID это глупости
1. Быстрее будет уже (Select Max(ID) from mytable).
2. поле датавремя точность до милисекунд, а знаешь сколько транзакций может пройти в одну милисекунду?
3. и зачем изобретать что-то если есть стандартные средства определения ID.

Я здесь.
Скажите ты, иначе это грубость, профессор.

Я чего не понимаю, стараюсь учиться.

> 1. Быстрее будет уже (Select Max(ID) from mytable).


Да нельзя так делать, ёлы-палы!!!
Ну где гарантия того, что это - именно твоя вставка, а не соседнего клиента, который выполнял вставку сразу за тобой??

Ega23 ©   (30.07.08 11:30) [31]

Конечно нельзя, но если уж выбирать по дате или (Select Max(ID) from mytable), то лучше последнее.

Может и глупость, что было-то было... и работало.
Как заметил Ega23,  (Select Max(ID) from mytable) еще менее надежный вариант.
Хотя он гораздо изящнее варианта с датой. Там нужно изголяться в силу

> устройства типа TDateTime

К слову, он был заменен на ... что Вы думаете?
id:=ExecSQL ('Select max([id])+1 FROM [SomeTable]')
TDataSet. Insert(id)
если ошибка - то заново.
И кажется, на так и жило.

Просто был задан вопрос

> Интересует все, кроме метода Select max([id]) FROM [SomeTable].

Нат   (30.07.08 11:47) [33]
Так это уже вы автоинкримент выдумываете, а вопрос был как определить значение автоинкремента после вставки.

Тогда уж давай будем последовательным:

> пределить значение автоинкремента после вставки

Совсем чуть-чуть отклонились.

Ega23
IsNull(max([id])+1, 1) это лучше, но имелось в виду другое.
Принципиальное отличие - вставка не запросом, а DataSet.Insert ...
Т.е. определяем ДО вставки, вставляем и остаемся на нужной записи.
И никаких поисков уже не надо.

> Т.е. определяем ДО вставки, вставляем и остаемся на нужной
> записи.


Я понял, что имелось ввиду. Но один фиг, это всё надо одним скриптом делать.
Я Max+1 выберу, а вставку данных в грид ещё не закончу.
В это время Max+1 выберет Вася Пупкин (а значение - то же самое, я ещё данные не закомиттил), быстрее меня забьёт данные, сделает коммит, и я получу insert error.

Точно. Тогда и все на повтор.

> TDataSet. Insert(id)если ошибка - то заново.

А просто запросом - вообще без гарантии от Васи. Залеты были чаще, чем с датой.
Сложно придумать лучше, чем:

> да, это все меняет... тогда надо select @@Identity

Разве что прямо на серверной стороне... ну там свои штуки.

есть @@Identity, чего еще заморачиваться?