ДубоХирург, если вопрос не про журнал дежурств, то в таблицу с врачами. Можно два поля: начало и конец рабочих часов. Если просят сделать детализацию, сделай одно JSON поле (поклонники нормализации, идите в жопу).

Недавно наткнулся на клёвую презентацию про хранение древовидных структур типа комментариев на хабре в реляционных СУБД. Автор рассказывает про 4 способа хранения:

  - adjacency list
  - path enumeration
  - nested sets
  - closure tables

Форум на этом сайте использует первый метод, adjacency list с модификацией.

Интересно, чем руководствовались М$, когда придумали, что GROUP BY обязан включать ВСЕ поля, которые есть в SELEСТ?

Мне нужна группировка по одному единственному полю, но так можно только в MySQL, который не используется. В случае с МС нужная мне группировка тупо не работает. Стоит добавить JOIN, становится ещё веселее: количество полей увеличивается, но результат тот же, группировки нет

Витаминыч, скинь структуру таблиц, и запрос.
Если я не забью на это через 10мин, то может помогу)

web_demon, там без вариантов) Это мысли вслух были.

Уже когда в MS SQL Server пишешь GROUP BY и только одно поле, подсвечивает как ошибку. Полез гуглить, нашел статью для MySQL, где пример работал, у меня так же было примерно. И там сноска была, что у мягких это иначе работает. Открыл пример для мс - и точно, там все что в SELECT надо прописывать.

Если интересно, то тупой пример

Грубо говоря, без группировки идет большая выборка (допустим, 1000 строк), ее нужно сгруппировать по номеру заказа. Например, если смотреть отдельно таблицу с заказами по номеру заказа, то получается, к примеру, 100 строк. В отчетности (простой файл, который генерируется в другой программе и к базе никакого отношения не имеет) содержатся те же 100 строк. Т.е., у меня всё корректно.

Если я пропишу все поля, как этого требуют МС, на выходе имею те же 1000 строк, а ожидается, что будет 100.

Пришлось отказаться от группировки и городить JOIN и доп проверки на поля в WHERE. Тогда получается желаемый результат Жалко потраченного времени только.

В каких случаях insert в ms access может записывать данные со смещением столбцов, когда я в commandText четко прописал названия и значения? Значения передаю через Parameters.AddValue

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

Витаминыч, первый неявный параметр забыл может быть, например, id? Или передаваемых параметрах проблема.

Ксакеп, скорее в самом файле бд. Потому что изгачально было всё под sql (sqlconnection и т.д), поменял на OleDb. Команды правильно всё передают. Про неявное поле не понял.

Ставлю везде текстовый - пишет со смещением (айди в дату, дату в фамилию и т.д.).
Предположим ты хотел вызвать f(id, date, family). Но по твоему сообщению ясно, что первый параметр подставляется автоматически, то есть вызывается f( , id, date, family), где — это какая-то штука, которую сам драйвер проставил, как значение поля id.

Цитата Ксакеп:

---

Предположим ты хотел вызвать f(id, date, family). Но по твоему сообщению ясно, что первый параметр подставляется автоматически, то есть вызывается f( , id, date, family), где — это какая-тожесть 🤔