Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

C# - Atkualizacja bazy SQL dzięki datagridview oraz buttona

Myrasz 10 Oct 2014 21:54 1227 13
  • #1
    Myrasz
    Level 20  
    Witam,
    Tworzę aplikację do raportowania zamówień i zaciąłem się w jednym momencie - już opisuję.
    W bazie SQL zostało stworzonych 5 tabel - każda odpowiada za jedną firmę. W Form1 utworzyłem TabControl z 5 zakładkami, w każdej z nich po jednym DataGridView. Dodatkowo do każdej ustawiłem button je aktualizujący. Jeśli wprowadzę zmiany w tabeli - DataGridView jest edytowalny, mogę dodawać/usuwać wiersze, edytować komórki - potwierdzam zmiany buttonem. Niestety działa to tylko w przypadku pierwszego DataGridView. Nie wiem jak przełożyć to na działanie kolejnych. Jeśli ktoś mógłby mnie naprowadzić, będę bardzo wdzięczny. Poniżej odrobina kodu.

    Code: csharp
    Log in, to see the code
  • #2
    mickpr
    Level 39  
    Myrasz wrote:
    Poniżej odrobina kodu.
    Zaiście odrobina - prawie nic nie mówiąca.
    Z opisu wynika, że błąd leży w logice aplikacji. Nigdzie nie masz otwartych naraz 5 zakładek, więc "po ki diabeł" tworzysz 5 tabel, datagrid-ów, i pięć razy identyczny w sumie kod.
    Chyba... że to są całkowicie inne (strukturalnie) firmy, inne pola w Datagrid-ach itd..

    Jeśli nie - to sugerował bym skonstruowanie uniwersalnej klasy, której obiekty będą powielone na tych 5-ciu zakładkach.
    Każde wystąpienie obiektu tej klasy byłoby tworzone przy otwarciu danej zakładki i niszczone przy zamknięciu.
    Po prostu podejdź do tego obiektowo, w końcu C# to język obiektowy.
    A w twoim przypadku wygląda to na to, że jedyne obiekty jakie stosujesz wiążą się z "formularzami".

    Teraz trochę o bazie.
    Ciężko mi krytykować coś, czego nie widzę, ale po drugim twoim zdaniu w kieszeni otworzył mi się nóż.
    Aplikację bazodanową zaczął bym od stworzenia koncepcji obiektów, tabel, klas i powiązanych z nimi formularzy, a potem już tylko 10 % roboty - czyli "kodowanie".
    Ty zaś zacząłeś od kodowania, a teraz koncepcyjnie chcesz się dostroić z formularzami i zakładkami do pomysłu, którego nie masz.

    Moja rada (bez sarkazmu i wyższości, bo nie uważam się za żadnego guru programistycznego) zacznij pisanie aplikacji jeszcze raz.
    To co obecnie stworzyłeś zostanie w twojej głowie jako pomysły - do wykorzystania, ale kod wyrzuć.
  • #3
    Myrasz
    Level 20  
    Dziękuję za odpowiedź. Może powinienem napisać to na początku - C# z powodów osobistych nie zajmuję się od przeszło 3lat i wiele pozapominałem - można mnie więc brać za amatora w tej dziedzinie. Dopiero od 2 tygodni staram sobie powoli przypominać co nieco. Na początek chciałbym stworzyć powyższą - prostą - aplikację do pracy, aby usprawnić mi i kolegom nasze obowiązki związane z raportowaniem "wyżej".

    Napisałeś o strukturze firm - jedna z nich różni się od pozostałych czterech tylko jedną kolumną, ale można ją i tam dorzucić - poprostu nie byłaby wypełniana. Sugerujesz, więc aby stworzyć bazę o jednej tabeli, która byłaby wczytywana do 5 zakładek/datagridów - tylko jak ugryźć problem wyświetlania w danej zakładce, informacji tylko o jednej firmie? Chodzi o to, że raport musi być przygotowywany co 24h. Przez ten czas mogę wypełniać informację o wszystkich firmach, a mogę tylko o 3 lub 4 - nie wszystkie są aktywne jednakowo. Dlatego stworzyłem 5 zakładek - chciałem, aby to wyglądało przejrzyście dla innych - ja mogę zrozumieć co wyświetla, bo tylko ja wprowadzam do niej dane - pozostali je pobierają i obracają nimi dalej, już do swoich raportów.

    Jakie rozwiązanie sugerujesz jeśli mogę spytać?
  • #4
    mickpr
    Level 39  
    Myrasz wrote:
    tylko jak ugryźć problem wyświetlania w danej zakładce, informacji tylko o jednej firmie?
    Klauzula "WHERE" w SQL wystarczy...
    Myrasz wrote:
    Przez ten czas mogę wypełniać informację o wszystkich firmach, a mogę tylko o 3 lub 4 - nie wszystkie są aktywne jednakowo.
    To akurat nie ma znaczenia.
    Myrasz wrote:
    Dlatego stworzyłem 5 zakładek - chciałem, aby to wyglądało przejrzyście dla innych
    I tak może zostać - jeśli uważasz, że tak będzie lepiej. Ja bym raczej sugerował rozwiązanie "wybieram firmę" np. z ComboBOX'a, a reszta formularza zostaje taka sama. Przecież na raz 5 osób nie siedzi przy jednej aplikacji, prawda?
    Problemem jest to, że chcesz 5 razy pisać prawie taki sam kod, co jest IMHO marnotrawstwem czasu i pieniędzy i kłóci się z ideą programowania.
    Takie programowanie posądzać można by o metodę "CTRL+C/CTRL+V", a to obraza dla każdego programisty. Mam takiego znajomego, który właśnie tak "pisze programy" - wydaje mu się, że "pisze".

    Myrasz wrote:
    Jakie rozwiązanie sugerujesz jeśli mogę spytać?

    Zacznijmy od danych, które wprowadzasz. Czy mógłbyś opisać jakie pola (mniej więcej, jeśli to nie tajemnica) chcesz umieścić przy danej firmie? Najlepiej na początku w formie tabelki Excel'a, gdzie każdy wiersz jest jedną z firm.

    Druga sprawa - jakie raporty byłyby przygotowywane - co w nich ma się znajdować (poza tymi danymi)? Jak mają wyglądać?

    Trzecia sprawa - czy tak prosta baza musi leżeć na SQL-u (nie wiem, może musi - więc się pytam)?
    Nie wystarczy prosta baza plikowa (np. w formacie bazy Access'a - MDB)?
  • #5
    Myrasz
    Level 20  
    Quote:
    Ja bym raczej sugerował rozwiązanie "wybieram firmę" np. z ComboBOX'a, a reszta formularza zostaje taka sama

    To by było bardzo dobre rozwiązanie. Czyli jeden gridboxview wyświetlający dane, w zależności od tego co zostanie wybrane z comboboxa.

    Quote:
    Czy mógłbyś opisać jakie pola (mniej więcej, jeśli to nie tajemnica) chcesz umieścić przy danej firmie? Najlepiej na początku w formie tabelki Excel'a, gdzie każdy wiersz jest jedną z firm.


    Oczywiście:
    C# - Atkualizacja bazy SQL dzięki datagridview oraz buttona

    Quote:
    Druga sprawa - jakie raporty byłyby przygotowywane - co w nich ma się znajdować (poza tymi danymi)? Jak mają wyglądać?


    Planowałem jeszcze zrobić export do pliku (.xlsx i/lub pdf). Tylko czy wykorzystując rozwiązanie z comboboxem, będę miał możliwośc exportu wszystkiego, czy tylko to co w danym momencie jest załadowane do tabeli?

    Quote:
    Trzecia sprawa - czy tak prosta baza musi leżeć na SQL-u (nie wiem, może musi - więc się pytam)?
    Nie wystarczy prosta baza plikowa (np. w formacie bazy Access'a - MDB)?


    Nie musi, wybrałem pierwsze lepsze rozwiązanie, gdyż chciałem sprawdzić czy w ogóle zadziała. Plik accesowy również może być. Mogę go umieścić na dysku sieciowym, do którego zainteresowani mieliby dostęp, a za pomocą aplikacji, wyświetlaliby zawartość.
  • #6
    mickpr
    Level 39  
    Myrasz wrote:
    To by było bardzo dobre rozwiązanie. Czyli jeden gridboxview wyświetlający dane, w zależności od tego co zostanie wybrane z comboboxa.
    Dokładnie.
    Myrasz wrote:
    Planowałem jeszcze zrobić export do pliku (.xlsx i/lub pdf).
    A nie lepiej opcja "podgląd/wydruk" raportu? Doinstalowany PDF Creator i masz jednocześnie "za darmo" możliwość generowania PDF.
    Myrasz wrote:
    Tylko czy wykorzystując rozwiązanie z comboboxem, będę miał możliwośc exportu wszystkiego, czy tylko to co w danym momencie jest załadowane do tabeli?
    To zależy jak skonstruujesz bazę.
    Z tego co widzę, to bardziej przypomina to bazę Firma+Zamówienia, niż sama baza firm.
    W tym przypadku wypadało by zadać jeszcze pytania:
    - czy asortyment zamówień jest stały czy zmienia się?
    - czy zamówienia powinny być rejestrowane, czy też ten program ma służyć wyłącznie jako "wklepywaczka do wydruku"
    - czy pozycje zamówień będą wprowadzane, czy raczej zwykły opis - bez szczegółów?

    Jeśli zamówienia trzeba byłoby rejestrować wraz z pozycjami - sugeruję co najmniej 3 tabele.
    1. Tabela firm
    2. Tabela zamówień
    3. Tabela pozycji zamówień

    Myrasz wrote:
    Nie musi, wybrałem pierwsze lepsze rozwiązanie, gdyż chciałem sprawdzić czy w ogóle zadziała. Plik accesowy również może być. Mogę go umieścić na dysku sieciowym, do którego zainteresowani mieliby dostęp, a za pomocą aplikacji, wyświetlaliby zawartość.
    Jeżeli baza miała by być dostępna z wielu stanowisk jednocześnie - sugerował bym pozostawienie danych na serwerze SQL, zaś interfejs najlepiej zrobić Webowy. Wbrew pozorom to prostsze - niż napisanie pełnej aplikacji sieciowej.

    Oczywiście można zrobić to na zwykłym MDB, kwestia gustu. Rzekłbym - najprościej taką aplikację spłodzić w Access-ie, tyle że pozostaje kwestia "licencji na Access'a" dla użytkowników.
    Access załatwia ci największe problemy:
    - bazy z dostępem SQL,
    - formularzy + całkiem składny Visual Basic for Application do tego,
    - banalnie tworzonych raportów (czego się nie da porównać do Visual Studio C#).
  • #7
    Myrasz
    Level 20  
    Quote:
    A nie lepiej opcja "podgląd/wydruk" raportu? Doinstalowany PDF Creator i masz jednocześnie "za darmo" możliwość generowania PDF.

    Również dobre rozwiązanie tylko niestety nie wiem, czy dam sobie radę z PDF Creatorem - rozumiem, że google prawde mi powie? :)

    Quote:
    Z tego co widzę, to bardziej przypomina to bazę Firma+Zamówienia, niż sama baza firm.
    W tym przypadku wypadało by zadać jeszcze pytania:
    - czy asortyment zamówień jest stały czy zmienia się?
    - czy zamówienia powinny być rejestrowane, czy też ten program ma służyć wyłącznie jako "wklepywaczka do wydruku"
    - czy pozycje zamówień będą wprowadzane, czy raczej zwykły opis - bez szczegółów?

    Niestety narazie ma to służyć jako "wklepywaczka". Ma za zadanie "kontroli" obsługi klientów (firm). Zdarzają się rozbieżności - stąd wprowadzenie takiego rozwiązania, które zaproponowałem. Może szczegółowiej to wytłumaczę, bo może to nie być jasne:

    - do mnie spływają zamówienia, w tabeli odpowiadają za to kolumny (fax e-mail, standard, express - w zależności od podtrzeb klienta - w kolejności jest to: skan, oryginał, dostawa oryginału/skanu w "x" godzin);
    - realizacji podejmują się pracownicy magazynowi, którzy do rozliczania ich, wypełniają swoje raporty na kartkach papieru A4...
    - ich kierownicy wprowadzają dane z tych raportów do tabeli rozliczeń.
    I tutaj często bywa, że raporty pracowników magazynowych nie pokrywają się z rzeczywistością (wymyślają inne czynności lub zawyżają ilości). Chodzi o to, że ja - mając informacje o ilościach i rodzajach z pierwszej ręki - wypełniam tabelę zamówień, a następnie kierownicy magazynowi porównują ją ze swoim rozliczeniami.

    Quote:
    Jeżeli baza miała by być dostępna z wielu stanowisk jednocześnie - sugerował bym pozostawienie danych na serwerze SQL, zaś interfejs najlepiej zrobić Webowy.

    Niestety nigdy nie miałem do czynienia z interfejsem webowym, jestem w tym zielony.

    Quote:
    Oczywiście można zrobić to na zwykłym MDB, kwestia gustu. Rzekłbym - najprościej taką aplikację spłodzić w Access-ie, tyle że pozostaje kwestia "licencji na Access'a" dla użytkowników.
    Access załatwia ci największe problemy:
    - bazy z dostępem SQL,
    - formularzy + całkiem składny Visual Basic for Application do tego,
    - banalnie tworzonych raportów (czego się nie da porównać do Visual Studio C#).

    Prawda, ale chciałem jednak pozostac przy C#, gdyż chciałbym rozwijać swoje umiejętności w tym kierunku. Do tego, "wydaje mi się", że w C# można stworzyć interfejs bardziej intuicyjny niż w accesie. Dodatkowym problemem, może być ilość licencji, taka jak napisałeś - nie wszyscy posiadają pełną licencję - głównie jest to ReadOnly.
  • #8
    mickpr
    Level 39  
    Myrasz wrote:
    Również dobre rozwiązanie tylko niestety nie wiem, czy dam sobie radę z PDF Creatorem - rozumiem, że google prawde mi powie?
    http://www.pdfforge.org/pdfcreator
    To taki program, który instaluje ci w systemie drukarkę o nazwie PDF Creator.
    Wszelkie wydruki na tą drukarkę nie wychodzą fizycznie na papier, tylko powodują utworzenie pliku AcrobatReader'a w formacie PDF.

    Myrasz wrote:
    Może szczegółowiej to wytłumaczę, bo może to nie być jasne:

    - do mnie spływają zamówienia, w tabeli odpowiadają za to kolumny (fax e-mail, standard, express - w zależności od podtrzeb klienta - w kolejności jest to: skan, oryginał, dostawa oryginału/skanu w "x" godzin);
    - realizacji podejmują się pracownicy magazynowi, którzy do rozliczania ich, wypełniają swoje raporty na kartkach papieru A4...
    - ich kierownicy wprowadzają dane z tych raportów do tabeli rozliczeń.
    I tutaj często bywa, że raporty pracowników magazynowych nie pokrywają się z rzeczywistością (wymyślają inne czynności lub zawyżają ilości). Chodzi o to, że ja - mając informacje o ilościach i rodzajach z pierwszej ręki - wypełniam tabelę zamówień, a następnie kierownicy magazynowi porównują ją ze swoim rozliczeniami.
    Czyli masz swoją "bazę zamówień", które musisz podpisać pod zadane firmy i zrobić wydruk dla kierowników magazynów. Z tego co pisałeś - wydruk ma dotyczyć jednego dnia (24h).
    Dobrze by było, abyś w swoim programie mógł wprowadzać, edytować i usuwać:
    - firmy,
    - zamówienia z szczególnym podziałem na "typ" (dobrze rozumuję)
    Rozumiem, ze szczegóły zamówienia (pozycje) cię na razie przynajmniej nie interesują, tak?
    Zrób więc jeden formularz do wprowadzania/edycji firm.
    Drugi formularz do wprowadzania/edycji zamówień z ustalaniem:
    - firmy (Combobox)
    - dnia zamówienia (kontrolka kalendarza)
    - datagrid -> zamówienia (+ przyciski dodaj, usuń, zmień)
    - pola tekstowe do wprowadzania zamówienia do datagrid'a (edycję datagrida bezpośrednio zostaw w spokoju)
    - przycisk zamknij, podgląd wydruku i wydruk (jeśli wybierzesz drukarkę "PDF Creator", efektem będzie nie wydruk, a plik PDF.

    Do tego musisz stworzyć raport (jeśli nie robiłeś tego w C#, to się trochę nad tym pomęczysz - dlatego sugerowałem Access'a, bo to 10 razy łatwiejsza metoda).
  • #9
    Defice
    Level 25  
    Hmm... Zbyt wiele do tematu nie wniosę, bo kolega mickpr chyba już wszystko opowiedział :) więc zwrócę uwagę na inne rozwiązanie generowania raportów. Mianowicie, chodzi mi o iTextSharp.

    http://sourceforge.net/projects/itextsharp/

    A tu mały tutorial:

    http://www.codeproject.com/Articles/277065/Creating-PDF-documents-with-iTextSharp

    Możliwości niemal nieograniczone, do tego całkiem łatwo się z nim współpracuję :)
  • #10
    Myrasz
    Level 20  
    Trochę mnie nie było - dzięki za odpowiedzi. Jeszcze mam pytanie, bo nie jestem pewien - baza w formacie .mdf, umieszczona na dysku sieciowym, do którego mają dostęp użytkownicy aplikacji, będzie odczytywana/nadpisywana bez problemu? Nie jest wymagany format .accdb?
  • #11
    mickpr
    Level 39  
    Myrasz wrote:
    baza w formacie .mdf
    MDF to nie format pliku, tylko rozszerzenie jego nazwy. Zapewne chodzi ci o bazę w formacie Microsoft SQL Serwer?
    Myrasz wrote:
    umieszczona na dysku sieciowym, do którego mają dostęp użytkownicy aplikacji, będzie odczytywana/nadpisywana bez problemu?
    Dostępu do bazy SQL Server nie robi się w ten sposób. Są od tego określone protokoły i sposoby (TCP, Named pipes, itd..) . Zagadnienie wielodostępu i sieciowych baz danych nie jest takei proste, jak by się na pierwszy rzut oka mogło zdawać.
    Myrasz wrote:
    Nie jest wymagany format .accdb?
    ACCDB to format bazy danych z Access 2007, to zupełnie coś innego.
  • #12
    Myrasz
    Level 20  
    Quote:
    Zapewne chodzi ci o bazę w formacie Microsoft SQL Serwer?

    Dokładnie. Chodzi mi o to jakie źródło danych byłoby najlepsze(najwydajniejsze) do współpracy aplikacji umieszczonej na kilku (do 5) stacjach roboczych?
  • Helpful post
    #13
    mickpr
    Level 39  
    Bazę zostaw na SQL. Dostęp zrób przez WWW (np. Webmatrix, gdzie możesz pisać w C#)?
    Będziesz miał "wielodostęp" załatwiony.
    Takie podejście "załatwia" wiele problemów, z którymi byś się zetknął w przypadku pisania aplikacji sieciowych.
  • #14
    Myrasz
    Level 20  
    Rozwiązany - zamknięto