У меня есть DbContext, он выдаёт грид. Я получаю View нужной мне таблицы

и уже peopleView является источником данных для DataGrid.
Пользователь что-то редактирует в этих строках, и как только строка оказывается отредактированной, у меня выполняется


Т.е. я не контролирую то, что ввёл пользователь. DBContext сразу себе берёт всё введённое и сохраняет.

Проблема выявляется с датой. СУБД у меня - SQLite. Пользователь вводит дату в одном формате, а сохраняться она должна в другом. Куда и как можно вписать прослойку, чтобы я мог полностью контролировать, что конкретно запишется в БД и в каком формате?

Я поясню:
пользователь пишет: 29 января. (вернее, он это может откуда-то скопировать и вставить строку в мой грид, либо использовать контрол, который выдаст ему дату в таком формате и пр.). Ему не нужен год, т.к всегда считается, что это текущий.
Значит, Он пишет 29.01, а в БД должна поступить инфа 29.01.2018.

Получается, что он пишет верную дату, а как её на лету скорректировать, чтобы в БД она записалась как '20180129' - не понятно.

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

Roman Mejtesесли текстовое поле связано со свойством типа DateTime, то при вводе некорректной она не будет передана в источник. Как по мне, лучше использовать контрол который ограничивает ввод даты по шаблону, так как с этими датами гемороя не оберешься 01/11/2012, это 11 января или 1 ноября?
сверху в заголовке указано "2018" без возможности её изменения - в базу запрещено вносить любые даты за пределами этого года. Соответственно, пользователь работает только с месяцем и числом, без года. Поэтому дата "11 марта" - дата корректная. И если она не запишется в поле базы данных ("потому что не указан год") - это будет неверным поведением.

Это ж SQLite. Каждый файл посвящён отдельному году. Объединения годов в одном файле не будет по разным причинам, в т.ч. потому что SQLite не выдержит большого объёма данных и потому что пользователь хочет разные года сохранять в разные файлы - ему это удобно.

С точки зрения пользователя:
Он создаёт новый файл, указывает "мероприятия за 2018 год". При создании в окне "визарда" выбирает "2018" -его не интересует 2017-й, 2019-й. В колонке "дата" его интересует только месяц-день и "вымораживает" постоянное повторение "2018", поскольку "и так ясно, о каком годе идёт речь, другого не дано". Пользователя вообще не волнуют предыдущие года, он их вообще удаляет, поэтому проблема стояла не в том, что "несколько лет не умещается в один файл". А вообще в другом:

Пользователь хочет вводить в ячейку "11 января". Но эта строка напрямую улетает в БД, что неверно. В самой "БД" тип указан date и записаться "11 января" должно в формате "20180111". Вопрос был в том, как реализовать прослойку, ибо DataGrid использует таблицу из DbContext в качестве источника и всё записанное в ячейках DataGrid сразу отправляется в DbContext.

Я не придумал ничего лучше, чем создать свой компонент, отображаемый в ячейке.

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

Petro123До свидос!
ну "досвидос", так "досвидос". Мне кажется, тебе показалось, что вопрос я задаю лично тебе и лично от тебя жду ответов. А ведь всё просто - если ты не хочешь отвечать или рассуждать на какую-то тему, можешь просто игнорировать. Лично я так всегда и делаю.

Решения я прочитал и принял к сведению, поэтому и пишу, что
хорошо я согласенпроблема сто яла

P.s. как всегда, благодарен пользователям Сон Веры Павловны и Roman Mejtes за ответы и наводящие вопросы.

Petro123,

так "досвидос" же. Разве нет?

skyANAхорошо я согласен,

мне кажется, что Вам будет полезно почитать http://www.sqlite.org/datatype3.html
указать-то Вы DATE можете, только на деле это совсем не DATE
да, это я понимаю. Ту страничку читал.
Я могу в поле "date" вписать всё, что угодно. Разница в том, что плагины нормально с этим работать не будут (TryParse не работает) - и результат будет таким, как на скриншоте. Да и хотелось бы просто дату хранить как дату. Чтобы можно было вычислять разницу и пр. без дополнительных последующих преобразований.

Petro123,

мне помнится, ты "о всё" говорил на предыдущей странице или что-то типа того.

Roman Mejtes,

Да, в итоге я в общем-то так в итоге и сделал - оформил свой контрол. Это действительно лучшее решение.

Petro123"Я могу в поле "date" вписать всё, что угодно"
С технической точки зрения - могу, данные будут успешно записаны.
Вот только это неправильно, для нормальной работы необходимо писать в строгом формате, не в том, в каком удобно пользователю. В связи с чем и создан пост.
SQLite не создан для хранения больших массивов данных. Для этого существуют клиент-серверные СУБД. Твой КЭП.
И это. Хорош флудить. Правда.
Ушёл, гордо хлопнув дверью раз:
Petro123До свидос!
Ушёл, гордо хлопнув дверью два
Petro123А игнор у вас или неигнор - мне абсолютно пофигу.
Тема то закрыта).
Продолжил флуд
Petro123не флуди.
продолжил ёрзать на стуле
Petro123Так что пиши ещё))
Посмотри в пример, как ведут общение нормальные адекватные взрослые люди - Roman Mejtes, skyANA, Сон Веры Павловны. Бери с них пример.

Модератора прошу тему закрыть. Вопрос решён.

Petro123SQLite слабая база.
ну-ну. Теперь у нас SQLite - база данных. Так мог сказать только человек, который слабо разбирается в предметной области.
Petro123250 млн.записей.
в excel тоже можно записать 250 млн. записей - по миллиону на каждую страницу и создать 250 страниц. И посмотри на позеленевшего пользователя, который будет пытаться работать с этим файлом на своём локальном компьютере.

И на тебя посмотрю, как ты заговоришь, когда тебе на офисном ноутбуке придётся выполнять запросы к БД под управлением SQLite объёмом хотя бы несколько миллионов записей.

В прочем, чего я тут очевидные вещи объясняю.

Petro123Да ОНО в контексте форума база данных. Даже более - СУБД. Расшифровать буквы?
Нет. SQLite - не база данных. B я очень надеюсь, ты сам для себя расшифруешь СУБД, а также выучишь мат.часть, исследовав разницу между БД и СУБД.

да никто на неё не гонит. Я её выбрал, т.к. пользователю удобно работать с файлами, а не подключаться к серверу и данных не так много (и активность работы с ними не такая большаяя), чтобы была необходимость использования клиент-серверной архитектуры.

Вопрос-то вообще в другом был. Причём тут вообще болтовня о выборе СУБД?

Слушай, а ты не из тех, кто монитор называет компьютером, а системный блок процессором?
Во-первых, я не писал "SQLite слабая база". Такую дурь мог выкурить написать только ты.
При работе под SQLite с большим объёмом данных у пользователя клиентское приложение будет зависать и тормозить, задача работы с большими объёмами данных должна быть возложена на сервер. Я не завидую пользователям, которым придётся работать с программками, которые напишешь ты. "SQLite может обеспечить работу с базой в 250 млн записей!", - аргументировал Петя заказчику, а то, что ноуты не способны адекватно работать с таким объёмом данных до глянцевого мозга Пети не дошло и никогда не дойдёт.

Петя засрёт весь форум, но не признает своей некомпетентности.

Что и требовалось доказать.