wtorek, 8 czerwca 2010

ObjectDataSource: OldValuesParameterFormatString oraz ConflictDetection [PL]

Ostatnio wykorzystywałem DataSet jako źródło danych typu ObjectDataSource dla kontrolki GridView. W tle za DataSet'em była baza danych oraz były skonfigurowane metody Select, Insert i Delete. Wyświetlanie danych przebiegało bezproblemowo, niestety nie działało usuwanie i edycja elementów. Powodem były kwerendy, które przy usuwaniu (delete) lub edycji (update) wykorzystywały wszystkie pola(kolumny) tabeli. Niestety domyślnie dodane źródło typu ObjectDataSource nie chciało przekazywać wszystkich parametrów i następował wyjątek.
Dlaczego? Zobaczmy co mówi MSDN:
"The value of the OldValuesParameterFormatString property is applied to primary keys only, such as those that are identified with the DataKeyNames property of a data-bound control, or in delete and update scenarios where the ConflictDetection property is set to the CompareAllValues value, and the set of original values are passed to the corresponding data method."
Czyli w standardowo tylko klucze główne są uwzględniane podczas update i delete. Rozwiązaniem jest ustawienie ConflictDetection="CompareAllValues". W wyniku tego przesyłane są wszystkie parametry. Ostatecznie mamy:
   <asp:ObjectDataSource ID="ObjectDataSource_MainDataSet" runat="server" DeleteMethod="Delete"  InsertMethod="Insert" OldValuesParameterFormatString="Original_{0}" 
    ConflictDetection="CompareAllValues" 
    SelectMethod="GetData" TypeName="DataBaseInterface.SomeDataTableAdapter" UpdateMethod="Update">
I już działa!
Promuj

3 komentarze:

  1. A teraz proponuję zmienić coś w schemacie bazy danych i uruchomić aplikację, która wykorzystuje ObjectDataSource jako źródło danych. Raczej nie ma co liczyć na to, że otrzymam jakiś zrozumiały komunikat błędu. Ciężko mi znaleźć uzasadnienie by używać "technologii" ObjectDataSource w swojej pracy. Po doświadczeniach z ObjectDataSource i innymi tego typu wynalazkami (DataSety) powiedziałem: nigdy więcej. Pozdr.

    OdpowiedzUsuń
  2. Jeżeli chodzi o reagowanie na błędy, to rozwiązania są i postaram się do tego tematu wkrótce wrócić, a do uzasadnienia wykorzystania takich "wynalazków", to chyba jakieś jest. Wydaje mi się, że jest to najprostszy i najszybszy sposób na przygotowanie aplikacji, która sporo prezentuje danych z bazy danych (lub innego źródła). Jeżeli znasz jakiś inny prostszy przykład to pokaż. ;)

    Pozdrawiam!

    OdpowiedzUsuń
  3. Zgadzam się, że jakieś uzasadnienie jest (ktoś może sobie używać tych obiektów i osiągnie zadowalający efekt), natomiast w mojej pracy tego typu kontrolki się nie sprawdziły. Okazało się na przykład, że nie potrafię zmienić CommandTimeOut dla zapytania i domyślnie wykonuje się ono tylko 30 sekund, co dla bardziej skomplikowanych zapytań jest zbyt małą wartością. Programista niejako zwabiony prostotą tego typu rozwiązania implementuje je, wszystko działa do pewnego momentu, ale gdy potrzeba przeprowadzić jakieś zmiany (np. zmiana schematu bazy danych - szukaj sobie wtedy po całym projekcie co gdzie jest użyte, albo zmieniać w DataSetach wartość wspomnianego parametru CommandTimeOut - oczywiście da się to zrobić albo tworząc klasę częściową dla każdego TableAdaptera - problem się pojawia jeśli tych klas miałbym utworzyć 200, albo zastosować rozwiązanie bazujące na refleksji - co w jakimś stopniu spowalnia działanie aplikacji). Możliwe, że w tonie mojej wypowiedzi jest jakiś zawód, rozczarowanie :), może niech napiszą w MSDN-ie: używać ObjectDataSource tylko do zastosowań hobbystycznych oraz na konferencjach i pokazach, gdzie w 1 minutę można całą napisać aplikację. Zamiast tworzyć pseudowarstwę (to chyba będzie jakiś kontroler, który ładnie nazywa się biznesowym) z użyciem ObjectDataSource nie łatwiej by było zwyczajnie wywołać w kodzie wymaganą funkcję? Że parametry się automatycznie dodają? Jakiś plus jest. A co z paginacją danych - przecież domyślny model obsługi stron dla GridView to było jakieś nieporozumienie - przykłady z MSDNa pokazywały, że i tak całe źródło danych musiało zostać ściągnięte do kontrolki gdzie potem wybierano tylko właściwy podzbiór danych. Dobrze że w końcu dodali do MSSQLa coś jak LIMIT dla MySQLa. Moim zdaniem albo nie potrafię z tego korzystać dla bardziej zaawansowanych rzeczy, albo z tego nie da się korzystać :), albo z tego da się korzystać, ale trzeba ciągle coś ustawiać i nadpisywać klasy, tak że liczba tych tips and tricks jest większa, niż by to napisać na nowo. Pozdr.

    OdpowiedzUsuń

Posty powiązane / Related posts