И снова проблемы в нашей БД. Куда же без них...
Суть ее в том, что имеется таблица в DataSet, в которой хотелось производить поиск (читай фильтрацию при помощи DataTable.Select() ).
В целевой таблице много полей и, как полагается, часть из них необязательная. Когда источник заполнился при помощи Fill() и пристыковался к DataGridView, все отображается без траблов. А вот когда налагаем фильтр на данную таблицу и отображаем его в DataGridView вылезает ошибка следующего содержания (см. картинку).


Как исправить данное недоразумение? Что делать со строками, я сообразил - надо заменить свойство DBNull Action с Throw Exception на Empty. А вот что творить с логическими и целочисленными полями пока я ума не приложу.
попутно задам еще один вопрос, чтобы не создавать потом новую тему. Представим ситуацию, что хочется производить полнотекстовый поиск методом LIKE сразу по нескольким полям таблицы. Как надо составить строку-параметр Expression метода DataTable.Select() ?
Как при наличии нескольких поисков делать пересечение (логический AND), объединение (логический OR) нескольких полнотектовых критериев?
Заранее спасибо.

Насчет данной проблемы не подскажу, но могу подсказать как работать с фильтром через DataView:

MasterOfCode, спасибо за быстрый ответ.
Попробую, воплотить твои мысли.
Только вопрос по твоему коду

По полю [FieldName] осуществляется полнотектовый поиск, ищущий вхождения данной в фразы в поле, а вот по полю [OtherFieldName] осуществляется жесткий поиск по значению (не полнотекстовый) или я что-то не так понял?

Unlocker,  все правильно понял. Это я так для примера привел, используй свои имена и параметры

MasterOfCode, свои данные я вставлю - это не проблема.
меня интересует возможность объединить в одном запросе (фильтре) нескольких полнотекстовых поисков. Или если нельзя напрямую сделать этого, то, например, найти пересечение двух или более результирующих полнотекстовые поиски множеств.

Я сейчас пользуюсь таким поиском, может неказистый, но работает 
Посмотрите, может что-то подойдет.



Это сообщение отредактировал(а) okaton - 11.12.2008, 22:14

Не совсем понял алгоритм твоего поиска. Какая цель перебора по всем полям всех записей?
Реальная бизнес-логика требует совпадения лишь в определенных полях. Имеет смысл организовывать полнотекстовые поиски по полям, возвращая массивы записей для поиска по каждому полю, а для результирующего представления делать пересечение или объединение полученных массивов.
Идея твоя неплоха, но мне кажется, что в реальном приложении простой перебор всех ячеек не принесет желаемого и однозначного результата.

  видимо в этой теме я лишний, программирование - хобби, а о бизнес проектах я "только" в книжках читал. Звиняйте если что  

Это сообщение отредактировал(а) okaton - 11.12.2008, 23:18

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


Источник Википедия.

PS: если слово ни о чем тебе не говорит, найди его смысловое толкование - может, оно не такое страшное, как покажется сперва.     

Это сообщение отредактировал(а) Unlocker - 11.12.2008, 23:54

  Я не горячусь, я плачу. Ты меня неправильно понял, в моих словах не было переносного смысла. 

Про логику своего кода могу сказать следующее: на объекте стоят в/м комплектами они разные (в смысле комплекты, да к тому же категорированные). Допустим мышка в аварийном состоянии, здесь все просто ищем серийник мышки по (так сказать) базе. А теперь другой вариант у нас есть номер "чего-то" и нужно провести профилактику, я не знаю что искать и тем более, где. И тут спасает поиск по всем объектам, самое плохое что номеров у спец. изделий может быть несколько и некоторые из них почему-то (!) пересекаются.  Других вариантов поиска я не вижу.

А по поводу твоей задачи. Повторюсь программирование - хобби. В силу своих ограниченных знаний   

ИМХО: Так в чем проблема воспользоваться кодом выше, ограничить поиск ширины и глубины для необходимого поля, вместо подсвечиваемой ячейки поставить "накопитель" массива или коллекции и полученный результат вывести в удобоваримом виде (можно даже в отдельной форме наверняка) согласно relation; в крайнем случае новый datatable и relation. 
Все дело в быстроте подсчета, может быть фильтрами и быстрее (у меня так и не получилось ими воспользоваться), но в их основе же лежит нечто похожее, если это не низкоуровневое программирование (что имеет смысл). 

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

Это сообщение отредактировал(а) okaton - 12.12.2008, 01:04

Теперь все понятно.  
у меня кодинг тоже был хобби до определенного момента, пока не начал приносить доход)))
Может и правда, стоит организовать несколько отдельных поисков, запихнуть их переменную таблицу, где по необходимости поработать методом DataTable.Merge()?
В общем, вопрос нетривиальный и требует большого объема экспериментов.

PS. 
Только остается вопрос, как работать с выборкой. Если мы подменим переменной таблицей фильтрованную таблицу из DataSet, то как работать с этой выборкой, как сохранить изменения в БД?
Вопросов пока больше, чем ответов. Надо конопатить всю доступную литературу по ADO.NET 2.0

Это сообщение отредактировал(а) Unlocker - 12.12.2008, 01:15

Можно использовать уникальные идентификаторы и через них сохранять

Это сообщение отредактировал(а) okaton - 12.12.2008, 14:07