Я действительно могу пролить некоторый дополнительный свет на это, потому что я провел последний час, размышляя, почему мой запрос SELECT LAST_INSERT_ID()
работал на одном сервере MySQL, а не на другом.Один сервер работает под управлением MySQL 5.5.11 (производство), а другой 5.5.31 (локальное устройство).
До версий 5.1.67, 5.5.29 и 5.6.9 (в каждом соответствующем выпуске) LAST_INSERT_ID()
используется для возврата целого числа со знаком.
Теперь LAST_INSERT_ID()
возвращает BIGINT
без знака, что означало, что этот код, который работал на моем сервере 5.5.31:
var id = cn.Query<ulong>("SELECT LAST_INSERT_ID();").First();
...но не работает, если выполняется на более старом сервере 5.5.11.
Это задокументировано здесь:
http://dev.mysql.com/doc/refman/5.5/en/information-functions.html#function_last-insert-id
Значение имеет тип BIGINT UNSIGNED
начиная с MySQL 5.5.29, BIGINT
(подписанный) до этого.
Моим первоначальным решением было приведение результата LAST_INSERT_ID()
к беззнаковому BIGINT
, чтобы сделать код переносимым между обоимиэти версии сервера, но (сюрприз, сюрприз) команда MySQL добавила контрольно-пропускной пункт.
Вы не можете привести LAST_INSERT_ID()
напрямую к беззнаковому (или даже подписанному) BIGINT
, используя CAST()
функция , потому что она не поддерживается.Единственные целочисленные типы, которые вы можете разыграть, это SIGNED INTEGER
и UNSIGNED INTEGER
.Это неприятно, потому что если по какой-то причине вам действительно нужно автоматически увеличивать BIGINT
id, который увеличивается после 4294967295
, то целое число без знака не будет достаточно большим типом для приведения.