none
external lists, есть webpart connection, удаление selected элемента главного списка - ошибка!? Не selected - ОК... RRS feed

  • Вопрос

  • Здравствуйте.
    В SPF2010 в SPD сделал 2-а external list из View SQL.
    Стандартные, сгенеренные вебпарт для каждого списка связываю "отправить данные для фильтра".
    В главном списке создаю элемент, в детальном списке ничего отфильтрованного нет и не м.б.
    В главном списке тут же при удалении selected элемента выпадат в ошибку.
    Если НЕ selected - все норм.

    Ошибка
    Exception information: 
    Exception type: ObjectNotFoundException 
    Exception message: В FindSpecific (операции чтения в элементе) возвращено неопределенное (null) значение. 

    Request information: 
    Request URL: .../pages/goods_dop.aspx?View={097A7A0B-084F-4A36-9868-6D491B12CE2B}&SelectedID=­__bg800023009300&InitialTabId=RibbonAn unhandled exception has occurred.EListItem&VisibilityContext=WSSTabPersist­ence 

    Т.е. после удаления элемента остается и не очищается SelectedID?

    Почему, подскажите пжл!!!

    Все вебпарты стандартные, все сгенерено, что-то можно сделать настройками и no code??

    Спасибо!
    8 февраля 2013 г. 16:12

Ответы

Все ответы

  • Это (проверил) именно с внешними списками...

    FindSpecific - т.е. чтение элемента из sql view отдельно не определял...

    может стоит задаться вопросом?

    )))

    8 февраля 2013 г. 16:54
  • В общем, без выписывания своей вебпарт для external списка и отработки события - ничего не сделать.

    Извне вопрос решается ровно так, как и просит шарик - делаем stored proc для Specific Finder-а, возвращающую что-то, чего разумеется нет в подчиненной таблице, возвращать надо именно полный набор, с каким-то левым id, связанным в connection  на подчиненную вебпарт. Возвращать в любом случае, т.к. удалены из главной м.б. и все элемены. Так плохо, но этот фантомный набор нигде не виден.

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

    9 февраля 2013 г. 8:44
  • Что-то из вашего описания не понятно, что вы пытаетесь сделать. Какая бизнес-задача? Что не так со Specific Finder?

    Dmitry

    Twitter Lightning Tools LogoLightning Tools Check out our SharePoint tools and web parts | Lightning Tools Blog | Мой Блог

    11 февраля 2013 г. 11:20
    Отвечающий
  • Здравствуйте.

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

    В главном списке, в ect, specific finder определялся запросом к sql view, т.е. bdcm генерила просто select ... where

    Далее, если выбирал 1 элемент главного списка, связанный фильтруется ок, но вот удаление этого selected элемента главного приводило к ошибке, которую я показал.

    Если определить specificfinder отдельно, на основе sp, то все нормально, но только, если в случае параметра, который not exists в таблице/вью sql?  формируется все равно некий набор данных, с отсутствующим id для связи, который и летит в связанную вебпарт и она ничего не показывает.

    Т.е. так получилось визуально корректно.

    Почему в случае удаления, при условии связи 2-х вебпарт все равно отрабатывает после удаления spcefic finder - вот собссно, вопрос.

    Как решить это нормально? - до сих пор ответа нет...

    11 февраля 2013 г. 11:32
  • А как у вас Deleter то реализован? Не совсем понятно как у View вы удаляете элемент. Вообще, если есть доступ к серверу БД и есть возможность написать хранимые процедуры, то на них предпочтительнее делать ECT, так как больше свободы.

    Dmitry

    Twitter Lightning Tools LogoLightning Tools Check out our SharePoint tools and web parts | Lightning Tools Blog | Мой Блог

    11 февраля 2013 г. 12:11
    Отвечающий
  • В sql view, которые просто подмножество селекта таблицы, удаляется нормально.  В простых все можно, там есть некоторые нюансы с ect, но в целом, если не запарно все отслеживать, sql код можно сократить. Но лучше, конечно, да - единообразно, все на хранимые, согласен. 

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

    К слову, после вылета той ошибки из вью все равно удалялось.

    Но, как оно будет с ним/без него проверял (c/без deleter) - ситуация не менялась. Удаление выделенного - и ошибка.

    11 февраля 2013 г. 12:20
  • Жаль, что у вас еще SPF, иначе можно было бы использовать Business Data List Web Part + Business Related Data List Web Part. Поэтому попробуйте перевести все на работу с хранимыми процедурами.

    Dmitry

    Twitter Lightning Tools LogoLightning Tools Check out our SharePoint tools and web parts | Lightning Tools Blog | Мой Блог

    • Помечено в качестве ответа Roman Zhukov 19 февраля 2013 г. 7:44
    11 февраля 2013 г. 12:44
    Отвечающий
  • Кстати SPF ставит подножки в неожиданных местах )), там, где согласно описанию, читаешь и д.б. норм. в foundation этого просто нет или чего-то нет )), так что spf - это дополнительные грабли!

    По сути вопроса - да, ок ))

    11 февраля 2013 г. 13:04
  • Вот вам табличка Compare SharePoint Editions, чтобы сразу видеть, где будут лежать грабли :-)

    Dmitry

    Twitter Lightning Tools LogoLightning Tools Check out our SharePoint tools and web parts | Lightning Tools Blog | Мой Блог

    11 февраля 2013 г. 14:12
    Отвечающий