В проекте на ASP.NET MVC, используется LINQ to SQL для ORM, база SQL 2005 Express, столкнулся со следующей проблемой (проявляется редко, закономерностей пока не выявил).
При добавлении новой записи в базу сохранение не происходит, в лог пишет "String or binary data would be truncated. The statement has been terminated.", но вводимые данные не превышают длину поля в базе! Что это может быть ещё? Самое странное что после этого даже если задаёшь другие значения (Test 123 и т.п.) сохранение не происходит. Помогает только перезапуск сервера. Кто-то сталкивался с подобным?

Суммарная длинна запроса какая? Там есть ограничения на уровне 255, 2048 и 8096 байт...

Помогает только перезапуск сервера.
------
или коммит/ролбацк начатой транзакции.

В базе поля типа nvarchar(255), на самой форме заполнения input maxlength="200", то есть туда вбить больше физически не возможно!

От кодировки таблицы анси / юникод фактическая длинна поля не зависит?

Не думаю, тем более что nvarchar это юникод, то есть ansi туда тем более влезет. Мне интересно другое, почему блокируется база и ничего туда не добавляется даже заранее правильное.

транзакция висит?

Может быть, но я не понимаю почему. И это может длиться часами.

ролбэк в кэтче есть?

Как раз щас пробую добавить его, нет не было.

то есть туда вбить больше физически не возможно!
------
Ну что же - еще раз - суммарная длинна всего запроса-пакета, всего SQL-стайтмента, отправляемого на сервер - не более 8 Кб... возможно, что Экспрессе - 4К - не смотрел... Остальное - обрезается. К размеру полей в базе и формах - никакого отношения не имеет.
В пределе - где-нибудь в глубине ОРМа вся текстовая последовательность может энкодится во что-нибудь тексто-восьмеричное с ключем и на сладкое - в уникоде - 12 байт на символ... Остальное сам сообразишь...

А кто рулит транзакциями? Если ОРМ, то тебе надо от него получать ту транзакцию, которая зависает...

Да транзакциями рулит ORM (я честно говоря, с ними никогда в плотную не общался), вот код метода модели
public void AddNewCustomer(Customer customer, Contact contact, Contact deliveryContact = null)
{
contact.ContactName = customer.Firma + " адрес";
customer.Contact = contact;
if (deliveryContact != null && !string.IsNullOrEmpty(deliveryContact.Adress))
{
deliveryContact.ContactName = customer.Firma + " адрес 2";
customer.Contact1 = deliveryContact;
}
try
{
dataContext.Customers.InsertOnSubmit(customer);
dataContext.SubmitChanges();
}
catch (Exception ex)
{
Logger.error(ex);
}
}

Вот этот момент можно по-подробнее, я почему-то всегда считал что UTF-16 кодируется 16 битами?

кодируется 16 битами?
-----
Это - да.
Вопрос в том, во что их преобразуют при передаче, учитывая, что спецсимволы, при передаче, используются для управления...
Так что - кодируют:
16-ю двоичными символами - '1111000011110000' (используется очень редко)
6-ю восьмеричными - '170707' (часто)
4-мя шестнадцатеричными - 'F0F0' (редко)
обычно еще добавляют ключик - '='
Итого - '=170707' (буквами по два байта на букву) = 14 байт на реально пересылаемый символ
14 * 200 = 2.800 байт на поле в 200 символов...
Примерно так, если брать предел возможной глупости ОРМа...

Нужно смотреть что отдает ОРМ...
Помимо энкодинга, там есть еще момент - обновляются все связанные записи.
Обычно, достаточно обновить только ключи, но гении программинга на такие мелочи
не размениваются - понятие первичного ключа для них, как и для части ДБА, есть
пустой звук - делается полная выборка зависимых записей и пишется полный апдейт
с матчингом всех полей... и начихать на возможные ошибки...
В общем - нужно врезаться между клиентом и сервером и полностью логировать
обмен - потом разбираться что там пошло не так как ожидалось...

нет такого ограничения. У меня стейтменты по несколько десятков килов глотает и не морщится. Было ограничение на размер данных в строке в MSSQL2000, как раз что-то вроде 8K, но начиная с 2005 он научился переносить превышающие этот лимит данные на другую страницу.
p.s. различий в экспрессе и в полной версии в таких вещах быть не может, движок там одинаковый. Единственное - размер базы, кол-во процессоров и объем оперативки.

включай профайлер и смотри, что конкретно идет на сервер.
upd. Правда, в express'е профайлера нет :( тогда на крайняк enterprise evaluation поставить можно, если в округе полновесного сиквела не найдется.

Было
-----
Было... пофиксили или нет - Я не смотрел - у меня обрезка всегда по
минимуму.
научился переносить
------
может быть... А разработчикам ОРМа об этом сказали?
А остальные посредники как? Всякие там ODBC, Найтив SQL и прочие?
Где-то размер страницы все еще ограничен - об этом и сообщается...
ЗЫ. Помнится разок наткнулся на фишку в Оутглюке - длина полей ТО:,
СС: и BCC: ограничена 255 буквами... остаток - обрезается без всяких
предупреждений, но можно было сделать несколько полей...
быть не может
------
Это биллина поделка - там может и не такое быть - он все еще даже
арифметику толком не освоил...

как раз что-то вроде 8K
------
Эээ... вопросик - А в T-SQL для строковых переменных они эти 8К перешагнули? Помнится в 7-ке натыкался на невозможность собрать и передать длинную строку...

посредники здесь не при чем. Я вот это вот сообщение - "String or binary data would be truncated. The statement has been terminated." - знаю очень хорошо, оно не от посредников никаких, а от самого движка.

тем не менее лично я за долгое время работы не встречал различий в движках msde/express и полных версий.

смотри в сторону nvarchar(max). Подробнее не разбирался, т.к. мне пока еще приходится поддерживать синтаксис T-SQL 2000.

от самого движка.
------
Хммм... похоже что самого движка - 0x80131904
Задал Я Гооглу поиск по этой ошибке. Первое же сообщение
http://www.dotnetspider.com/forum/18467-error-String-or-binary-data-would-be-tru...
Правда трекинг ошибки такой:

Возможно - сиквеловский - 0x80131904, возможно - посреднеческий - SqlClient.SqlException... надо писать тесты и смотреть когда падает...
А дальше народ слегка развлекается:


пока еще приходится поддерживать
-----
Аналогично... или переделывать много... но в 2005 вроде уже есть смысл слезть с T-SQL и перейти на сборки...
Садился пару раз, но так и не доучил...

сиквеловский. Как минимум лет 10 сиквеловский.

Не может быть, что модель неактуальная, т.е. не была обновлена после изменения размеров полей таблиц базы данных?