Есть DataTable, у которой два поля (StartTime и StopTime) имеют формат System.DateTime. Прекрасно отображаются в DataGridView. Нужно сделать ещё одно поле, которое бы отображало разницу между этими двумя полями. Я так понимаю, что поле должно быть System.TimeSpan, но как в него записывать значения? Очень бы хотелось это делать автоматически, через Expression 
Пробовал при создании поля записывать так:

Если StopTime пустое, то ошибок нет (какие могут быть ошибки?), а вот если нужно посчитать разницу, то дает ошибку:

Как быть?
P.S. Пишу пока что на VB.Net 

Привет!
Ух не силён я в VB.

Попробуй так, это стандартный способ. Это на C# но на VB  по аналогии, обекты ведь одинаковые.

В твоем случае видимо тип Time  или как он там называеться, и StopTime - StartTime видимо.И он для каждой строки по идее должен прогнать.

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

Попробовал тоже вылетает оно.
Почитал сдесь
 http://www.sql.ru/forum/actualthread.aspx?tid=662554

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

предлагаю такой подход - отображение времени - это функция клиента.
конкретнее - хранить метку времени в БД , как длинное целое (тот же UTC) и уже собственно работать именно с ним. 
покажу на примере:



бесспорно это не оптимальный вариант. писал на скорую руку. но тем не менее он подчеркивает мою мысль.

mrbrooks, ты прав. Всё получилось. 
А как, вернее, когда правильно форматировать выводимые значения? Я делаю это в CellFormating. Может есть другой метод?

 данное событие собственно для этого и создано.

К сожалению DataColumn.Expression имеет очень ограниченный список поддерживаемых функций, к тому же сделать для него extensible метод проблематично. 
Как вариант - выполнять расчет в обработчиках событий DataTable.ColumnChanged, DataTable.RowChanged. Это позволит не извращать формат хранения данных в БД под данный кусочек логики.

А почему извращать? Всё наоборот, очень логично. Храним число, делаем с ним, что нужно, а когда нужно его показать, то форматируем.

Дело в том, что потом придется выполнять преобразование данных при каждом обращении к ним, как в SQL запросах так и в логике.
Для того и выделены различные типы данных, чтоб было удобно ими пользоваться разработчику.  В данном случае хранение даты в формате числа является решением одной локальной проблемы(что есть хак в чистом виде), влекущей за собой глобальные последствия   

При чем здесь SQL? Данные пересчитывает клиент при отображении/записи. Этим приемом пользуются в частности производители промышленных девайсов. К примеру если брать устройства по архиву данных - в них время хранится всегда как длинное целое в UTC.


Чем богаты, тому и рады.

к примеру:
вместо 


прийдется писать



или



также очевидно что CAST добавляет лишней работы серверу БД, что для выборок на больших обьемах данных, будет давать "прирост" во времени выполнения запроса


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

Это сообщение отредактировал(а) advantiss1 - 17.12.2009, 15:14