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

Ну вот) а в базе может быть отрицательным

Поэтому и ошибка

Ну ладно. Поменяю на int.

Как пример, в Телеграмме идентификаторы чатов имеют отрицательное значение, а юзеров положительное =) (или наоборот, сразу не скажу, уже не помню так)

Как пример, в Телеграмме идентификаторы чатов имеют отрицательное значение, а юзеров положительное =) (или наоборот, сразу не скажу, уже не помню так)

А где ты увидел исходники телеграмма? Он же не опенсорс вроде.

https://github.com/telegramdesktop/tdesktop

api ботов

и это тоже

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

Не, мы еще до такого не доросли. У нас ручная оптимизация

Теперь такая бодяга: String or binary data would be truncated.

Берем вьюхи в БД, догрузку коллекций в EF, разделенные таблицы и все становится прекрасно

Ну у нас как-то так примерно

Теперь такая бодяга: String or binary data would be truncated.

Размерность строк

Размерность строк

В смысле?

У тебя какая в базе размер строки?

Я там проставил nchar(100) везде

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

Этого должно хватать

а вставить пытаешься больше

Ну видимо засовываешь больше

Зачем nchar?

Нет. Там нету ни одного поля у которого длина была бы больше 100 символов

Нет. Там нету ни одного поля у которого длина была бы больше 100 символов

А база говорит есть

Зачем nchar?

А почему нет? Или что там юзать для строк? Он сам подставил его.

А почему нет? Или что там юзать для строк? Он сам подставил его.

Nvarchar

Ну у нас как-то так примерно

Правильно написаные вьюхи на стороне БД дают очень хороший прирост в скорости работы, правда только на чтение

Nvarchar

А чем они отличаются?

http://stackoverflow.com/a/15553059/1487968

Нет, заменил, ошибка не пропала: String or binary data would be truncated.

Так тебе нужно еще размер поменять

и модель обновить

не 100 а больше поставить

У меня нет там строк больше 100 символов. Инфа 100%. Файл перед глазами откуда они парсятся. А модель я обновил после смены типа.

а есть больше 50?

А нет, пардон есть больше 100 ? Мне казалось коротки строчки, а оказывается длинные))) померил через notepad++

happy end

Ах этот сложный мир программирования

Правильно написаные вьюхи на стороне БД дают очень хороший прирост в скорости работы, правда только на чтение

Эт да. Вообще оптимизация перфоманса на БД увлекательнейшая вещь. У нас вот нет ДБАшников, поэтому приходится самим ковырятся

а вообще не жадничайте на длину строк в бд

Да чтоб тебя... Переполнение SqlDateTime. Должно находиться в пределах от 1/1/1753 12:00:00 AM и 12/31/9999 11:59:59 PM.

Всегда найдется строка длиннее чем ты думал

а почему у тебя ошибки то на русском, то на английском?

Хз)

Так выводит

давй уже бота запили, чтоб он ошибки билда сюда вываливал ?

Потом тебя возьмут на работу, дадут точно похожий таск и тебе станет внезапно не лень переводить все это? Ты считаешь, что кто-то серьезно захочет видеть у себя такой код? Если ты не умеешь писать красивый код, никому не нужны твои алгоритмы. И вангую, кстати, что данные тебе эти надо нормализовать, а не пихать все в одну таблицу.

sql сервер английский, а фрейм русский видимо

с Этими русскими названиями сразу косячок виден

Потом тебя возьмут на работу, дадут точно похожий таск и тебе станет внезапно не лень переводить все это? Ты считаешь, что кто-то серьезно захочет видеть у себя такой код? Если ты не умеешь писать красивый код, никому не нужны твои алгоритмы. И вангую, кстати, что данные тебе эти надо нормализовать, а не пихать все в одну таблицу.

я хз что там за задание, но как в вариант в компании, которая работает с 1с это считается нормой

БИК uint хотя он с 0 может начинатся

везде потом придется добавлять 0 до нужной длины

Так же как ИНН

ууу

string нужон

потом такая жопа будет с поиском по данным, если не привести это сразу в нормальный вид

и КПП тоже 0 может начинаться

я хз что там за задание, но как в вариант в компании, которая работает с 1с это считается нормой

1с никогда не видел, но плательщик12345 глаза режет.

ну я согласен, но для 1с это норма. Там ещё и язык запросов переведён

1с никогда не видел, но плательщик12345 глаза режет.

Там это не разные плательщики как кажется. Это разные данные одного и того же плательщика. Типа адреса, телефона и т.п. Просто не именованные, а нумерованные.

типа ЛЕВОЕ СОЕДИНЕНИЕ и прочее

Соединение какое-то левое

По идее для такой фигни наверное как раз и удобнее было бы юзать носкл

Так что мне делать с "Переполнение SqlDateTime. Должно находиться в пределах от 1/1/1753 12:00:00 AM и 12/31/9999 11:59:59 PM." ? У меня нету дат меньше 1753 года...

Потом тебя возьмут на работу, дадут точно похожий таск и тебе станет внезапно не лень переводить все это? Ты считаешь, что кто-то серьезно захочет видеть у себя такой код? Если ты не умеешь писать красивый код, никому не нужны твои алгоритмы. И вангую, кстати, что данные тебе эти надо нормализовать, а не пихать все в одну таблицу.

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

Так что мне делать с "Переполнение SqlDateTime. Должно находиться в пределах от 1/1/1753 12:00:00 AM и 12/31/9999 11:59:59 PM." ? У меня нету дат меньше 1753 года...

покажи как вставляешь

ERROR: S client not available

есть подозрение что какую-то дату ты просто не задал

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

ну это не нормализация, это аутизм

И если нужно поправить значение, то можно по незнанию поправить еще штук 100 счетов, лол. И какие адовые джойны это создает - надо себе представлять

ну это не нормализация, это аутизм

Знаю, зато экономия места в БД

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

epic

Про производительность молчу вообще

Знаю, зато экономия места в БД

сомневаюсь что новая таблица с айди+значение занимает меньше, чем просто +1 столбец

сомневаюсь что новая таблица с айди+значение занимает меньше, чем просто +1 столбец

Та да, там экономия на спичках в целом и целый воз других проблем

а можешь саму строку с подставленными значениями показать?

а можешь саму строку с подставленными значениями показать?

Так значения же даппер подставляет сам

Я только названия полей вставляю

Типа values (@Prop1, @Prop2)

Смотри значения все которые вставляешь

Нулевая дата скорее всего где-то есть

Там все даты от 2010 года идут

Возможно надо в SQL сделать даты NOT NULL?

В C# же не могут быть они нулевыми

valuetype

В C# же не могут быть они нулевыми

Сильное заявление. Nullable запретили?

Сильное заявление. Nullable запретили?

Но я то не пользуюсь тут Nullable. Зачем?

В C# же не могут быть они нулевыми

DateTime? date = null;

Структура DateTime не может принимать null, т.к. является value type. Но можно её обернуть вот так: Nullable<DateTime> или DateTime?

Я знаю

Только надо ли?

Хз

Только надо ли?

Мы то откуда знаем что тебе надо =)

Мы то откуда знаем что тебе надо =)

Мне надо чтоб ошибок не было))

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

чем больше работаю с такими случаями, тем больше убеждаюсь, что ненормализованные таблицы работают быстрее

чем больше работаю с такими случаями, тем больше убеждаюсь, что ненормализованные таблицы работают быстрее

Естествнно! Джойн - это дороговатая операция

In надо делать