Есть база данных электронной проходной на FireBird. Клиента пишу на Delphi 2005. Для доступа к базе использую InterBase. Сетка DbgridEh.
Данные тянутся через Ibquery и имеют вид:
--------------------------------------------------------
id   |     FIO    |   Date         | Time    | Type_Pass |
-------------------------------------------------------------
1    |  Иванов |01.09.2014 | 07:30  | 1                |
2    |  Иванов |01.09.2014 | 16:30  | 2                |
3    |  Иванов |02.09.2014 | 07:29  | 1                |
4    |  Иванов |02.09.2014 | 16:32  | 2                |
-----------------------------------------------------
Type_pass это событие проходной (1-вход, 2 - выход)
Нужно что бы пользовательская таблица имела читабельный вид:
------------------------------------------------------------
id2  |    FIO      |   Date         |  Vhod  | Vuhod  |
-------------------------------------------------------------
1     | Иванов  | 01.09.2014 | 07:30  | 16:30  |
2     | Иванов  | 02.09.2014 | 07:29  | 16:32  |
---------------------------------------------------------

 Пока на ум приходит:
1. Создать в БД дополнительную таблицу (как во втором варианте)
2. С помощью нескольких запросов забивать ее данными из первой таблицы
3. Показывать вторую таблицу пользователю
4. Если данные пользователь изменил, то проверять на соответствие с первой таблицей и апдейтить или инсертить первую.
5. Почистить вторую таблицу
6. см п2.
Этакий вариант времянки.

Может кто пнет меня на другую идею лучше/проще (нужное подчеркнуть)? Может как нибудь средствами делфи такое провернуть? Вообщем, я зациклился и не могу внятное что-то придумать   
 
P.S. FireBird только осваиваю (Сильно не пинайте).

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

Добавлено через 3 минуты и 25 секунд
вторую таблицу можно формировать с помощью вложенных запросов, вычисляемых полей или с помощью хранимых процедур
тут дульфи не при чём
вопрос нужно было задавать в теме про firebird или в sql запросах http://forum.vingrad.ru/forum/forum-491.html

Добавлено через 4 минуты и 43 секунды
в первой таблице вместо FIO должно быть поле ID_USER и ссылаться на справочник пользователей

А почему именно будет вот такой вид
id2  |    FIO      |   Date         |  Vhod  | Vuhod  |
-------------------------------------------------------------
1     | Иванов  | 01.09.2014 | 07:30  | 16:30  |
2     | Иванов  | 02.09.2014 | 07:29  | 16:32  |
а не вот такой
id2  |    FIO      |   Date         |  Vhod  | Vuhod  |
-------------------------------------------------------------
1     | Иванов  | 01.09.2014 | 07:30  | 16:32  |
2     | Иванов  | 02.09.2014 | 07:29  | 16:30  |
Как это определяется?

И что будет если удалить одну строку в исходных данных?
--------------------------------------------------------
id   |     FIO    |   Date         | Time    | Type_Pass |
-------------------------------------------------------------
1    |  Иванов |01.09.2014 | 07:30  | 1                |
2    |  Иванов |01.09.2014 | 16:30  | 2                |
4    |  Иванов |02.09.2014 | 16:32  | 2                |
-----------------------------------------------------
Может надо изменить структуру хранения в таблице (кстати как оно хранится, а то ваш query не известно как выбирает данные и откуда).
Почему бы не хранить в одной строке дату начала и дату окончания, при записи времени окончания просто апдейтить строку с date_close is null и id_user = наш юзверь?

)) Нельзя войти 2 раза подряд, не выходя

Этот ответ добавлен с нового Винграда - http://vingrad.com

нет, к сожалению не позволяет

 
Буду признателен, если перенесете. Просто думал, может в делфе можно как нибудь с помощью сторонних гридов поизвращатся)


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


Привязкой к дате


Данные не должны удаляться. Человек утром прошел на работу, отбил пропуск - время прихода попало в базу. Вечером ушел, отбил пропуск - время ухода тоже в базе. На основе этих данных контролируется выработка рабочего времени. Смысл весь в том что бы просто можно было подправить время прихода/ухода с работы.


База входит в готовый софт ЭП. Что-то менять в структуре нельзя.
Вот привожу две таблицы из базы из которых собственно и будет происходить выборка.
Таблица Staff (ключ Id_staff):

Таблица Tabel_Intermediadate (ключ ID_TB_IN ):

Связь Staff_id - id_staff
Мой запрос на выборку был в ibquery (изначально не хотел писать хранимую процедуру на сервере):

Получал:

Нужно было это привести к виду второй таблицы из первого моего поста.
Сделанный вывод: хоть и не хотелось что бы обработка данных лежала на сервере (дабы не иметь проблем с фирмой сопровождающей ПО проходной), но по ответу
Akella, понял что придется.

напиши модератору этого раздела

Если есть возможность, делай всё по максимуму на сервере   

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

Остался как я понимаю только вариант локально перелопачивать данные, полученные запросом из БД.

Пока что промелькнула мысль сделать DbGridEh скрытым, а пользователю выгружать данные в обычный grid, так как ему нужно, с помощью цикла. Если что то он изменит, то изменить это и в DbgridEh и алилуя. 

Какие то извращенные у меня мысли   

Это сообщение отредактировал(а) valentos - 18.9.2014, 15:35

При таком подходе, DbGridEh можно вообще удалить. Он ни к хранению, ни к изменению данных не имеет никакого отношения.

Можно попробовать как то вложенными, агрегатными запросами это решить, не знаю. Можно конечно и лопатить на клиенте.

Правильно, поэтому время начала сеанса и время окончания сеанса правильнее хранить в одной строке. Insert при входе и Update при выходе и пофигу хоть день, хоть сутки, хоть трое суток человек на работе провел. Разница дат вернет отработанное время и никаких проблем с выборками.  Но раз нельзя править БД, то зачем обсуждать это.

С этого обычно всё и начинается   

Имхо самый лучший вариант как раз ХП на сервере.

хранимые процедуры и вычисляемы поля - это левое? 

Добавлено через 4 минуты и 34 секунды


А если человек выходит на обед?
А если по служебной необходимости выходит и входит.

Не сегодня, так завтра понадобится добавить ещё один контроллер. Непример посещение како-го режимного кабинета или цеха. Опять вход-выход.

Я бы сделал одно поле "Дата-Время" и там уже обозначал бы тип: вход/выход, а также номер контроллера, ID пользователя, ну и другие данные каки-то.

Он это время и не работает, курит, обедает и т.д.



Да хоть пятдесят контроллеров апдейтим строку с максимальным временем и все, добавить еще поля номера контроллеров не составит труда. Причем можно также войти в один, выйти в другой (два входа/выхода в цеху).
Зашли в цех с 10:30
Дошли до режимного объекта вошли в 10:50
Вышли из режимного в 10:45 следующего дня, обновили строку с макимальным временем входа и пустым временем выхода.
Вышли из цеха, обновили оставшуюся строку 
(индекс по чуваку + времени захода на таблицу вешаем)

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

P.S. варианты реализации еще зависят от конкретных задач, так что оба варианта пригодны. Что-то нас в оффтоп понесло

Добавлено через 47 секунд

Пусть контроллер перепрыгивает