DataSet i SqlCe - teoretycznie nie zapisuje do bazy

Bawię się z problemem już dłuższą chwilkę i nie daję rady. Czytałem tutoriale i wydaje mi się, że robię prawidłowo. Chodzi o to, że dane nie zapisują mi się do pliku bazy (*.sdf), a chyba powinny i.... sprawa jest na tyle dziwna, że póki nie dam podglądu z Visuala tej bazy to rekordy istnieją. Ale... jak dam w Visualu 'Preview Data' to tak jakby czyściło mi bazę do zera. Zostaje domyślny rekord admin, admin, który dodałem za pośrednictwem kreatora w VS. Czyli, póki nie dam podglądu, wszystkie rekordy, które dodałem kodem istnieją. Sprawdzałem i w kodzie da się je odczytać. Ale gdy daję ten podgląd to "czyści" mi wszystko i nie ma nic i znów mogę dodać nowy rekord. Kod mam taki:

XMServerDataSet usersDataSet;

usersDataSet = new XMServerDataSet();
XMServerDataSetTableAdapters.UsersTableAdapter ad = new XMServerDataSetTableAdapters.UsersTableAdapter();
ad.Fill(usersDataSet.Users); // póki nie dam podglądu w VS, DS zapełnia się danymi
usersDataSet.Users.AddUsersRow("test1", "test2");
ad.Update(usersDataSet);

Co z tym fantem zrobić? Chciałbym mieć podgląd rekordów w Visualu. A może coś źle robię? Dodam, że to moje pierwsze zmagania z ADO.NET za pośrednictwem Visuala, a nie samego kodu.

Jesteś pewien, że baza nie jest kasowana przy każdym uruchomieniu programu?

Tak jak wspomniałem, z kodu wywołanie ad.Fill(usersDataSet.Users); powoduje prawidłowe zapełnienie DataSet-a. Ma on dodany rekord. Czyli Update działa... ale wszystko się pieprzy jak robię 'Preview Data' w Visualu, tzn. tabela albo i cała baza zostaje wyczyszczona.

1. Rozumiem, że dane chcesz trzymać w pliku *.sdf, który jest dodany do solucji? Jakie on ma właściwości?
2. To, że coś jest w DataSecie nie znaczy chyba, że od razu trafia do bazy.
3. Czemu w XXI wieku używasz DataSetów? ;P

Copy if newer i jako Content

Wiem, ale skoro potem Fill działa bo zapełnia dataseta w drugim uruchomieniu programu to znaczy, że w bazie się zapisuje.

A co do DataSets.. Na początku bawiłem się bez nich bazami w samym kodzie, tj. komendy itd. Ale postanowiłem się nauczyć obsługiwać to z poziomu VS. To jak nie DS to czego użyć do baz danych aby było łatwo i po ludzku?

Jak chcesz sobie łatwo klikać w VS, to Entity Framework.

Zgadzam się z przedmówcą:

somekind napisał(a):

Jak chcesz sobie łatwo klikać w VS, to Entity Framework.

Czyli większe i poważniejsze projekty wykorzystują EntityF tak? Właśnie wczoraj próbowałem coś zrobić z EF, ale ciężej szło niż z tymi DataSetami. A jak to w praktyce z tym zapisywaniem, jaka może być tego przyczyna? Tak jakby VS zamiast podglądu to mi czyścił bazę :|

W DatabaseExplorer masz inną ścieżkę do pliku bazy danych (cudów nie ma). Prawdopodobnie w DE masz ścieżkę do bazy na root, a korzystasz z bazy w Bin\Debug (Release).
Jeśli masz ustawioną opcję CopyIfNewer to znaczy, że do podkatalogu 'Bin\Debug' (Release) nigdy ci się nie przekopiuje, bo TAM JEST NOWSZA wersja - zostały jakieś rekordy dodane / zmienione. Usuń na chwilę z projektu plik bazy danych (zmień nazwę) poza VS. Sprobuj odpalić program... Działa? Sprobuj odpalić bazę w DE... Działa?

pozdrawiaMM

Jeżeli z EntityFramework nie wyszło to wyjdzie na pewno z Simple Data, po pracy z NHibernate stwierdzam, że od tego frameworka winien zacząć programista, który chce zacząć tworzyć spójne aplikacje bazodanowe. Nie jest jakiś super trudny, o to też każdemu chodzi, w prosty sposób pozwala wykonywanie procedur składowanych co jest dla mnie bardzo istotne, nie chciałem wszystkie wbijać w kod c#.

xeo545x39 napisał(a):

Czyli większe i poważniejsze projekty wykorzystują EntityF tak?

No niektórzy masochiści tak robią, ci sprytniejsi korzystają z NHibernate.
EF jest dobry do małych i średnich projektów, o ile nie ma specyficznych wymagań, których EF nie jest w stanie spełnić.

Właśnie wczoraj próbowałem coś zrobić z EF, ale ciężej szło niż z tymi DataSetami.

EF jest obiektowe. Tworzysz obiekt, dodajesz go do kolekcji, wołasz SubmitChanges i dane się zapisują. Jak chcesz pobrać obiekt, to wybierasz przez LINQ obiekt z danej kolekcji. Wiersz mapuje się do obiektu, tabela do kolekcji obiektów, a do tego masz kontekst, który wszystkimi obiektami zarządza.

W DataSetach operujesz na jakichś zbiorach rekordów, które nie są w ogóle obiektowe, są jedynie prostym zmapowaniem 1:1 tabeli z bazy. Prostym, ale bardzo złożonym od strony kodu - masz DataSet, DataTable, TableAdapter, i jeszcze dodatkowe klasy pomocnicze. Nic dziwnego, że jest to zacofana technologia, stosowana tylko w starych projektach, i starych tutorialach. W czasach ORM, używanie DataSetów nie ma żadnego wytłumaczenia.