🚀 go-pugleaf

W dniu niedziela, 12 maja 2019 15:25:51 UTC+2 użytkownik lordbz napisał:
> Witam 
> 
> 
> Piszę pewną aplikację i wymyśliłem sobie żeby ograniczyć liczbę formatek itp.
> Aplikacja (poza tym co robi) ma możliwość dodawania użytkownika do bazy oraz edycji już istniejącego użytkownika. 
> Tyle tytułem wstępu.
> 
> Na formie dałem PageControl i dwie zakładki, oraz dwa przyciski (pobrane jednak z ramki). Jeden to "Zapisz" drugi "Koniec".
> 
> Na TabSheet1 są kontrolki dodające użytkownika a na TabSheet2 wyświetlane są dane użytkownika z wcześniejszej formatki gotowe do edycji.
> 
> Całość chciałem zrobić tak, żeby był jeden klawisz "Zapisz" (z ramki), który by obsługiwał obie sytuacje.
> Napisałem więc procedurę , która Insertuje do bazy nowego użytkownika, oraz osobną , która updatuje już istniejącego w bazie i teraz pod klawszem "Zapisz":
> 
> 
> procedure TFrm1.Btn1ZapiszClick(Sender: TObject);
> begin
> 
> if PageControl1.ActivePageIndex = 0 then
> DodajUzytkownika //wywołuję procedurę dodawania
> else
> EdytujUztkownika
> end;
> 
> taki pomysł - wydaje mi się , że ok ale.... jakoś czuję że to mało eleganckie, można prościej.
> 
> Może jakoaś opinia (tylko bez krzyków bo zamknę się w sobie i znowu kasa na terapeutę pójdzie :-)  )
> 
> pozdrawiam
> 
> Przemek

Ale po co dwa formularze na takie same dane?

Paweł

W dniu niedziela, 12 maja 2019 15:25:51 UTC+2 użytkownik lordbz napisał:

> Piszę pewną aplikację i wymyśliłem sobie żeby ograniczyć liczbę formatek itp.

<CIACH>

> taki pomysł - wydaje mi się , że ok ale.... jakoś czuję że to mało eleganckie, można prościej.
> 
> Może jakoaś opinia (tylko bez krzyków bo zamknę się w sobie i znowu kasa na terapeutę pójdzie :-)  )

Albo coś źle opisałeś, albo ja coś źle zrozumiałem. Ale po co Ci dwie osobne zakładki do dodawania i edycji tych samych danych? Przecież wystarczy jedna + np. flaga w jakim trybie pracuje formatka.

Choćby taki potworek:

class function pokazForme(aID: integer = -1): boolean;
begin
  if aID=-1 then
    (czyscimy edity, lub robimy na data Insert - zależy od sposobu)
  else 
    (wczytujemy do editów dane z rekordu aID lub robimy na data Edit);

  wyswietlamy forme
  i przy zamykaniu w zaleznosci od trybu dzialania
  albo zapisujemy nowy rekordy, albo uaktualniamy, albo robimy po prostu Post :)

end;

pozdrawiam,
Przemek O.

W dniu 13.05.2019 o 13:08, immo pisze:
> W dniu niedziela, 12 maja 2019 15:25:51 UTC+2 użytkownik lordbz napisał:
> 
>> Piszę pewną aplikację i wymyśliłem sobie żeby ograniczyć liczbę formatek itp.
> 
> <CIACH>
> 
>> taki pomysł - wydaje mi się , że ok ale.... jakoś czuję że to mało eleganckie, można prościej.
>>
>> Może jakoaś opinia (tylko bez krzyków bo zamknę się w sobie i znowu kasa na terapeutę pójdzie :-)  )
> 
> Albo coś źle opisałeś, albo ja coś źle zrozumiałem. Ale po co Ci dwie osobne zakładki do dodawania i edycji tych samych danych? Przecież wystarczy jedna + np. flaga w jakim trybie pracuje formatka.
> 
> Choćby taki potworek:
> 
> class function pokazForme(aID: integer = -1): boolean;
> begin
>    if aID=-1 then
>      (czyscimy edity, lub robimy na data Insert - zależy od sposobu)
>    else
>      (wczytujemy do editów dane z rekordu aID lub robimy na data Edit);
> 
>    wyswietlamy forme
>    i przy zamykaniu w zaleznosci od trybu dzialania
>    albo zapisujemy nowy rekordy, albo uaktualniamy, albo robimy po prostu Post :)
> 
> end;

Albo coś takiego:
  if TDataSet.State = dsEdit/dsInsert then...

Pozdrawiam
Piotr

W dniu poniedziałek, 13 maja 2019 13:45:06 UTC+2 użytkownik Kviat napisał:
> W dniu 13.05.2019 o 13:08, immo pisze:
> > W dniu niedziela, 12 maja 2019 15:25:51 UTC+2 użytkownik lordbz napisał:
> > 
> >> Piszę pewną aplikację i wymyśliłem sobie żeby ograniczyć liczbę formatek itp.
> > 
> > <CIACH>
> > 
> >> taki pomysł - wydaje mi się , że ok ale.... jakoś czuję że to mało eleganckie, można prościej.
> >>
> >> Może jakoaś opinia (tylko bez krzyków bo zamknę się w sobie i znowu kasa na terapeutę pójdzie :-)  )
> > 
> > Albo coś źle opisałeś, albo ja coś źle zrozumiałem. Ale po co Ci dwie osobne zakładki do dodawania i edycji tych samych danych? Przecież wystarczy jedna + np. flaga w jakim trybie pracuje formatka.
> > 
> > Choćby taki potworek:
> > 
> > class function pokazForme(aID: integer = -1): boolean;
> > begin
> >    if aID=-1 then
> >      (czyscimy edity, lub robimy na data Insert - zależy od sposobu)
> >    else
> >      (wczytujemy do editów dane z rekordu aID lub robimy na data Edit);
> > 
> >    wyswietlamy forme
> >    i przy zamykaniu w zaleznosci od trybu dzialania
> >    albo zapisujemy nowy rekordy, albo uaktualniamy, albo robimy po prostu Post :)
> > 
> > end;
> 
> Albo coś takiego:
>   if TDataSet.State = dsEdit/dsInsert then...
> 
> Pozdrawiam
> Piotr

Moim zdaniem lepiej zbindować dane do zwykłych kontrolek niż trzymać otwartą transakcję.
I nie jest potrzebna żadna flaga. Wystarczy przycisk "Aktualizuj dane" który dla większej elegancji może być disabled dopóki nie zmienimy zawartości w którejś z kontrolek.

Przyzwyczajony jestem do aplikacji webowych które są bezstanowe.

Paweł

W dniu niedziela, 12 maja 2019 15:25:51 UTC+2 użytkownik lordbz napisał:
> Witam 
> 
> 
> Piszę pewną aplikację i wymyśliłem sobie żeby ograniczyć liczbę formatek itp.
> Aplikacja (poza tym co robi) ma możliwość dodawania użytkownika do bazy oraz edycji już istniejącego użytkownika. 
> Tyle tytułem wstępu.
> 
> Na formie dałem PageControl i dwie zakładki, oraz dwa przyciski (pobrane jednak z ramki). Jeden to "Zapisz" drugi "Koniec".
> 
> Na TabSheet1 są kontrolki dodające użytkownika a na TabSheet2 wyświetlane są dane użytkownika z wcześniejszej formatki gotowe do edycji.
> 
> Całość chciałem zrobić tak, żeby był jeden klawisz "Zapisz" (z ramki), który by obsługiwał obie sytuacje.
> Napisałem więc procedurę , która Insertuje do bazy nowego użytkownika, oraz osobną , która updatuje już istniejącego w bazie i teraz pod klawszem "Zapisz":
> 
> 
> procedure TFrm1.Btn1ZapiszClick(Sender: TObject);
> begin
> 
> if PageControl1.ActivePageIndex = 0 then
> DodajUzytkownika //wywołuję procedurę dodawania
> else
> EdytujUztkownika
> end;
> 
> taki pomysł - wydaje mi się , że ok ale.... jakoś czuję że to mało eleganckie, można prościej.
> 
> Może jakoaś opinia (tylko bez krzyków bo zamknę się w sobie i znowu kasa na terapeutę pójdzie :-)  )
> 
> pozdrawiam
> 
> Przemek

Pewnie źle opisałem. Jeszcze raz - hhciałem ujednolicić interface dla użytkownika programu. Stąd pomysł.
Jest tak: na formatce jest siatka z danymi np. klientów (iksiński igerkowski itp.) W prawej części formatki są klawisze Wyszkaj, Dodaj nowego, Edytuj itp.. Teraz --> gdy wybierze "Dodaj nowego" otwiera się okno (nowa forma ) o nazwie "Dadaj/Edytuj" z aktywną zakładką "Dodaj" i są pola gotowe do wypełnienia nowymi danymi. A gdy zaznaczę kogoś na siatce i kliknę "Edytuj" to otwiera się okno "Dodaj/Edytuj" (tak to samo co przedtem okno) ale z aktywną zakładką "Edytuj".

No nie chcę przecież edytować tyle co założonego klienta bo i po co :-).

Może dam kodzik jak to wygląda.
Procedura dla dodawania nowego: (tu zajęcia)

procedure TFrmDodajEdytujZaj.ZakladkaDodajZajecia;
var
  generator: Integer;
  historia: string;
begin
  try
    with DtMdl.IBQtemp, SQL do          //dodanie nowego zajecia
    begin
      Close;
      Clear;
      Add('INSERT INTO Zajecia (Nazwa_zajecia, Opis)');
      Add('VALUES (:Nazwa_zajecia, :Opis)');
      ParamByName('Nazwa_zajecia').AsString := Trim(EdtNazwaZaj.Text);
      ParamByName('Opis').AsString := Trim(EdtOpisZaj.Text);
      ExecSQL;
      DtMdl.ibtransTemp.Commit;
    end;
    with DtMdl.IBQtemp, SQL do                    //po dodaniu w oknie wczesniejszym ustawiamy się na nowym
    begin
      Clear;
      Add('SELECT gen_id (gen_zajecia_id, 0) FROM rdb$database ');
      Open;
      generator := FieldByName('gen_id').AsInteger;
    end;


    with DtMdl.IBQZajecia, SQL do
    begin
      Close;
      Clear;
      Add('SELECT Id_zajecia, Nazwa_zajecia, Opis, Data_utworzenia, Aktywny, Usun FROM Zajecia');
      Add('WHERE Usun =:usun order by Nazwa_zajecia');
      ParamByName('Usun').AsInteger := 0;
      Open;
    end;
    DtMdl.IBQZajecia.Locate('id_zajecia', generator, [loCaseInsensitive, loPartialKey]);           //ustawienie fokusu na nowym zajeciu
    Close;
  except
    DtMdl.ibtransTemp.Rollback;
    ShowMessage('Błąd nie udało się dodać nowego Zajęcia ');
  end;
end;


Następna procedura dla edycji już istniejącego tylko że UPDATE - kod prawie taki sam.

i teraz całość jest wywoływana pod klawiszem :

procedure TFrmDodajEdytujZaj.RmkZajrzBitBZapiszClick(Sender: TObject);
begin
  if RzPgCtrl1.ActivePageIndex = 0 then
  begin
    ZakladkaDodajZajecia
  end
  else
   ZakladkaEdytujZajecia

czyli w zależności od tego która zakładka Pagecontrlo jest aktywna to ta procedura się wywołuje. 

Taki tam pomysł...

>Pewnie źle opisałem. Jeszcze raz - hhciałem ujednolicić interface ...

/ciach/

>No nie chcę przecież edytować tyle co założonego klienta bo i po co :-).

"hhciałem" - np po to. Literówki każdemu się zdarzają.

Moja rada jest taka: zrób jak uważasz i zobacz co z tego wyszło.
Wyciągnij wnioski i doskonal swój warsztat w ten sposób.
Powodzenia.

Paweł

Witam Panownie,
A ja mam pytanie do Was jako znawców tematów o coś podobnego. Tzn. dotyczyć będzie to właśnie dodawania i/lub edycji rekordów w bazie.
Załóżmy że mam bazę o nazwie TELEFONY a'la książka telefoniczna i kolumny NazwiskoImie, NrTel, Inne
Na formatce mam oba pola i teraz moje pytanie - jak dodajecie rekordy do bazy? Osobiście używam takiej konstrukcji:
1. Ustawiam bazę w tryb wstawiania TELEFONY.Insert
2. Wypełniam pola tekstowe formatki np. Edit1.Text, Edit2.Text
3. Przypisuję dodatkowe dane do bazy:
   TELEFONY.FieldByName('Inne').AsInteger := 1;  // Pole podane dla przykładu
4. Kończę operację poleceniem TELEFONY.Post (lub pod przyciskiem Anuluj TELEFONY.Cancel)

Ale wiem, że można do tego użyć poleceń SQLa, jak to kolega przedstawił czyli np.
  Close; 
  Clear; 
  Add('INSERT INTO TELEFONY (NazwiskoImie, NrTel, Inne)'); 
  Add('VALUES (:NazwiskoImie, :NrTel, :Inne)'); 
  ParamByName('NazwiskoImie').AsString := Edit1.Text;
  ParamByName('NrTel').AsString := Edit2.Text;
  ParamByName('Inne').AsInteger := 1;
  ExecSQL;

No i mije pytanie - którego rozwiązania powinienem się trzymać - pierwszego czy drugiego? Bo efekt końcowy jest identycznie taki sam.
Z góry dziękuję za (p)odpowiedzi.

--
Pancio

W dniu wtorek, 14 maja 2019 14:14:15 UTC+2 użytkownik Pancio napisał:
> Witam Panownie,
> A ja mam pytanie do Was jako znawców tematów o coś podobnego. Tzn. dotyczyć będzie to właśnie dodawania i/lub edycji rekordów w bazie.
> Załóżmy że mam bazę o nazwie TELEFONY a'la książka telefoniczna i kolumny NazwiskoImie, NrTel, Inne
> Na formatce mam oba pola i teraz moje pytanie - jak dodajecie rekordy do bazy? Osobiście używam takiej konstrukcji:
> 1. Ustawiam bazę w tryb wstawiania TELEFONY.Insert
> 2. Wypełniam pola tekstowe formatki np. Edit1.Text, Edit2.Text
> 3. Przypisuję dodatkowe dane do bazy:
>    TELEFONY.FieldByName('Inne').AsInteger := 1;  // Pole podane dla przykładu
> 4. Kończę operację poleceniem TELEFONY.Post (lub pod przyciskiem Anuluj TELEFONY.Cancel)
> 
> Ale wiem, że można do tego użyć poleceń SQLa, jak to kolega przedstawił czyli np.
>   Close; 
>   Clear; 
>   Add('INSERT INTO TELEFONY (NazwiskoImie, NrTel, Inne)'); 
>   Add('VALUES (:NazwiskoImie, :NrTel, :Inne)'); 
>   ParamByName('NazwiskoImie').AsString := Edit1.Text;
>   ParamByName('NrTel').AsString := Edit2.Text;
>   ParamByName('Inne').AsInteger := 1;
>   ExecSQL;
> 
> No i mije pytanie - którego rozwiązania powinienem się trzymać - pierwszego czy drugiego? Bo efekt końcowy jest identycznie taki sam.
> Z góry dziękuję za (p)odpowiedzi.
> 
> --
> Pancio

Drugiego.

Paweł

W dniu 14.05.2019 o 14:14, Pancio pisze:
> Witam Panownie,
> A ja mam pytanie do Was jako znawców tematów o coś podobnego. Tzn. dotyczyć będzie to właśnie dodawania i/lub edycji rekordów w bazie.
> Załóżmy że mam bazę o nazwie TELEFONY a'la książka telefoniczna i kolumny NazwiskoImie, NrTel, Inne
> Na formatce mam oba pola i teraz moje pytanie - jak dodajecie rekordy do bazy? Osobiście używam takiej konstrukcji:
> 1. Ustawiam bazę w tryb wstawiania TELEFONY.Insert
> 2. Wypełniam pola tekstowe formatki np. Edit1.Text, Edit2.Text
> 3. Przypisuję dodatkowe dane do bazy:
>     TELEFONY.FieldByName('Inne').AsInteger := 1;  // Pole podane dla przykładu
> 4. Kończę operację poleceniem TELEFONY.Post (lub pod przyciskiem Anuluj TELEFONY.Cancel)
> 
> Ale wiem, że można do tego użyć poleceń SQLa, jak to kolega przedstawił czyli np.
>    Close;
>    Clear;
>    Add('INSERT INTO TELEFONY (NazwiskoImie, NrTel, Inne)');
>    Add('VALUES (:NazwiskoImie, :NrTel, :Inne)');
>    ParamByName('NazwiskoImie').AsString := Edit1.Text;
>    ParamByName('NrTel').AsString := Edit2.Text;
>    ParamByName('Inne').AsInteger := 1;
>    ExecSQL;
> 
> No i mije pytanie - którego rozwiązania powinienem się trzymać - pierwszego czy drugiego? Bo efekt końcowy jest identycznie taki sam.
> Z góry dziękuję za (p)odpowiedzi.
> 
> --

Odpisze w Twoim poście ale jest to odp dla ciebie i dla autora wątku. 
Panowie dlaczego nie korzystacie z kontrolek DB i to co one dają? Czyli 
możliwość zrobienia niemal wszystkiego automatycznie wystarczy 
Datasource podpięcie odpowiedniego DataSeta (obojętne czy to będzie zeos 
czy to będzie AnyDAC czy inne cudo - każdy z tych który podepniecie 
wygeneruje za was podstawowe zapytanie INSERT bez grama pisania 
jakiegokolwiek zapytania

Wasz jedyny kod który was obchodzi to

procedure OnClickButton(Sender: TObject)
begin
   DataSet.post - tylko tyle - by dodać cokolwiek do bazy
end;

Zaraz ktoś napisze a to trzymana transakcja itd.

Ja na to... podstawowym punktem wyjściowym by sobie z takimi kłopotami 
radzić jest "CecheUpdate"

Doczytać jak ta funkcja działa w poszczególnych produktach tj zeos, 
anydac itp. i unikniecie takich problemów jak teraz

Można oczywiście się bawić w małych projektach w pisanie INSERT ręcznie 
itp ale jest to w mojej opinii strata czasu.

Oczywiście ja tu mówię o absolutnych podstawach nie wspominając o tym że 
są inne rozwiązania które oferują jeszcze znacznie więcej ponadto co ja 
tu opisałem

Pozdrawiam
J-23

> Wasz jedyny kod który was obchodzi to
> 
> procedure OnClickButton(Sender: TObject)
> begin
>    DataSet.post - tylko tyle - by dodać cokolwiek do bazy
> end;
> 
> Zaraz ktoś napisze a to trzymana transakcja itd.
> 
> Ja na to... podstawowym punktem wyjściowym by sobie z takimi kłopotami 
> radzić jest "CecheUpdate"
> 
> Doczytać jak ta funkcja działa w poszczególnych produktach tj zeos, 
> anydac itp. i unikniecie takich problemów jak teraz
> 

I właśnie po to są grupy dyskusyjne. Ty pokazujesz gdzie szukać ja dziękuję i wiem już czego nie wiem i idę się dowiedzieć :-)
pozdrawiam
dziękując wszystkim

Przemek

W dniu środa, 15 maja 2019 00:36:35 UTC+2 użytkownik J-23 napisał:
> W dniu 14.05.2019 o 14:14, Pancio pisze:
> > Witam Panownie,
> > A ja mam pytanie do Was jako znawców tematów o coś podobnego. Tzn. dotyczyć będzie to właśnie dodawania i/lub edycji rekordów w bazie.
> > Załóżmy że mam bazę o nazwie TELEFONY a'la książka telefoniczna i kolumny NazwiskoImie, NrTel, Inne
> > Na formatce mam oba pola i teraz moje pytanie - jak dodajecie rekordy do bazy? Osobiście używam takiej konstrukcji:
> > 1. Ustawiam bazę w tryb wstawiania TELEFONY.Insert
> > 2. Wypełniam pola tekstowe formatki np. Edit1.Text, Edit2.Text
> > 3. Przypisuję dodatkowe dane do bazy:
> >     TELEFONY.FieldByName('Inne').AsInteger := 1;  // Pole podane dla przykładu
> > 4. Kończę operację poleceniem TELEFONY.Post (lub pod przyciskiem Anuluj TELEFONY.Cancel)
> > 
> > Ale wiem, że można do tego użyć poleceń SQLa, jak to kolega przedstawił czyli np.
> >    Close;
> >    Clear;
> >    Add('INSERT INTO TELEFONY (NazwiskoImie, NrTel, Inne)');
> >    Add('VALUES (:NazwiskoImie, :NrTel, :Inne)');
> >    ParamByName('NazwiskoImie').AsString := Edit1.Text;
> >    ParamByName('NrTel').AsString := Edit2.Text;
> >    ParamByName('Inne').AsInteger := 1;
> >    ExecSQL;
> > 
> > No i mije pytanie - którego rozwiązania powinienem się trzymać - pierwszego czy drugiego? Bo efekt końcowy jest identycznie taki sam.
> > Z góry dziękuję za (p)odpowiedzi.
> > 
> > --
> 
> Odpisze w Twoim poście ale jest to odp dla ciebie i dla autora wątku. 
> Panowie dlaczego nie korzystacie z kontrolek DB i to co one dają? Czyli 
> możliwość zrobienia niemal wszystkiego automatycznie wystarczy 
> Datasource podpięcie odpowiedniego DataSeta (obojętne czy to będzie zeos 
> czy to będzie AnyDAC czy inne cudo - każdy z tych który podepniecie 
> wygeneruje za was podstawowe zapytanie INSERT bez grama pisania 
> jakiegokolwiek zapytania
> 
> Wasz jedyny kod który was obchodzi to
> 
> procedure OnClickButton(Sender: TObject)
> begin
>    DataSet.post - tylko tyle - by dodać cokolwiek do bazy
> end;
> 
> Zaraz ktoś napisze a to trzymana transakcja itd.
> 
> Ja na to... podstawowym punktem wyjściowym by sobie z takimi kłopotami 
> radzić jest "CecheUpdate"
> 
> Doczytać jak ta funkcja działa w poszczególnych produktach tj zeos, 
> anydac itp. i unikniecie takich problemów jak teraz
> 
> Można oczywiście się bawić w małych projektach w pisanie INSERT ręcznie 
> itp ale jest to w mojej opinii strata czasu.
> 
> Oczywiście ja tu mówię o absolutnych podstawach nie wspominając o tym że 
> są inne rozwiązania które oferują jeszcze znacznie więcej ponadto co ja 
> tu opisałem
> 
> Pozdrawiam
> J-23

Kiedyś dotknąłem tych kontrolek ale szybko się z tego wycofałem. Doszedłem do wniosku że to tylko do prostych zastosowań. Niby końcowa procka jest prosta (jak napisałeś) ale żeby taka była musisz najpierw trochę podrutować. U mnie przeważnie zapytania sql są tworzone dynamicznie i są często bardzo złożone (niedawno walczyłem z takim które ma około tysiąca słów). Interesują mnie: sql i tablica parametrów. Po co miałbym to wciskać do kontrolki dbaware?

Paweł

> U mnie przeważnie zapytania sql są tworzone dynamicznie (..)
> 
> Paweł

Może jakiś mały konkretny przykład ....
poproszę ?

Przemek

W dniu środa, 15 maja 2019 10:27:14 UTC+2 użytkownik lordbz napisał:
> > U mnie przeważnie zapytania sql są tworzone dynamicznie (..)
> > 
> > Paweł
> 
> Może jakiś mały konkretny przykład ....
> poproszę ?
> 
> Przemek

Na przykład klucz wyszukiwawczy. User klika check-boxy że chce to czy tamto dodać do warunku. Aplikacja buduje na tej podstawie zapytanie sql.
Przy okazji jest tworzona tablica parametrów. Uwaga dla początkujących: nie należy danych wstawiać bezpośrednio do sql ze względu na możliwość powstania błędnego sql-a czy złośliwego kodu (sql injection).

Paweł

W dniu środa, 15 maja 2019 10:27:14 UTC+2 użytkownik lordbz napisał:
> > U mnie przeważnie zapytania sql są tworzone dynamicznie (..)
> > 
> > Paweł
> 
> Może jakiś mały konkretny przykład ....
> poproszę ?
> 
> Przemek

No dobra, kawałek kodu (piszę z głowy):

var par: array of variant;
sql: string;
where: string;
i: integer;
begin
  sql:='select * from tabelka ';
  where:='';
  if cbDat.Checked then begin
    setLength(par, high(par)+2);
    par[high(par)]:=eDat.Value;
    where:=' where dat>:dat ';
  end; 
  if cbMat.Checked then begin
    setLength(par, high(par)+2);
    par[high(par)]:=eMat.Value;
    if where='' then where:=' where mat=:mat '
    else where:=where+' and mat=:mat ';
  end; 
  if cbPat.Checked then begin
    setLength(par, high(par)+2);
    par[high(par)]:=ePat.Value;
    if where='' then where:=' where pat containing :pat '
    else where:=where+' and pat containing :pat ';
  end; 
  sql:=sql+where;
  
  query.sql:=sql;
  query.prepare; //inicjacja parametrów (ale nie ich typów!)
  
  for i:=0 to high(par) do
  begin
    query.params[i].value=par[i];  
  end;  
  
  //tu: ew. transakcja...
  query.open; //dla select
end;


Paweł

W dniu 15.05.2019 o 13:04, zpksoft pisze:
> W dniu środa, 15 maja 2019 10:27:14 UTC+2 użytkownik lordbz napisał:
>>> U mnie przeważnie zapytania sql są tworzone dynamicznie (..)
>>>
>>> Paweł
>>
>> Może jakiś mały konkretny przykład ....
>> poproszę ?
>>
>> Przemek
> 
> No dobra, kawałek kodu (piszę z głowy):
> 
> var par: array of variant;
> sql: string;
> where: string;
> i: integer;
> begin
>    sql:='select * from tabelka ';
>    where:='';
>    if cbDat.Checked then begin
>      setLength(par, high(par)+2);
>      par[high(par)]:=eDat.Value;
>      where:=' where dat>:dat ';
>    end;
>    if cbMat.Checked then begin
>      setLength(par, high(par)+2);
>      par[high(par)]:=eMat.Value;
>      if where='' then where:=' where mat=:mat '
>      else where:=where+' and mat=:mat ';
>    end;
>    if cbPat.Checked then begin
>      setLength(par, high(par)+2);
>      par[high(par)]:=ePat.Value;
>      if where='' then where:=' where pat containing :pat '
>      else where:=where+' and pat containing :pat ';
>    end;
>    sql:=sql+where;
>    
>    query.sql:=sql;
>    query.prepare; //inicjacja parametrów (ale nie ich typów!)
>    
>    for i:=0 to high(par) do
>    begin
>      query.params[i].value=par[i];
>    end;
>    
>    //tu: ew. transakcja...
>    query.open; //dla select
> end;

Te kontrolki są do ułatwienia wielu rzeczy ale nie do wszystkiego - 
głównym ich zadaniem jest ułatwienie połączenia warstwy GUI z warstwą 
danych - by nie pisać kodu tam gdzie jest on zbędny.

Generowanie SQL to zupełnie inna bajka - u mnie (programuje teraz 
głownie w Javie i czasem w Lazarus) załatwiam to jedną klasą w całej 
aplikacji która w zależności od Parametrów generuje mi odpowiedni SQL i 
w takim wypadku nie korzystam z żadnych kontrolek ani zwykłych ani DB bo 
po co? Dane z kontrolek jeśli już są mi potrzebne bo np na ich podstawie 
jest generowany sql przekazuje za pomocą odpowiedniego property który 
znajduje się w klasie odpowiedzialnej za generowanie sql - po co? a no 
wszystko mam zamknięte w jednym module (obsługa wyjątków itd).

Można by to zrobić bez kodu nawet typu przekazanie do property ale 
wymagało by to napisania jeszcze jednego komponentu który kładę na formę 
i wskazuje w edytorze odpowiednie kontrolki DB. Ale to zrobię jeśli będę 
miał chwile czasu

PS a właśnie takie przykłady (choć rozumiem ze powyższy kod miał na celu 
pokazanie problemu) ale to co jest powyżej to jest metoda drutowania o 
której piszesz w tym wątku

Pozdrawiam

> Kiedyś dotknąłem tych kontrolek ale szybko się z tego wycofałem. Doszedłem do wniosku że to tylko
> do prostych zastosowań. Niby końcowa procka jest prosta (jak napisałeś) ale żeby taka była musisz
> najpierw trochę podrutować. U mnie przeważnie zapytania sql są tworzone dynamicznie i są często
> bardzo złożone (niedawno walczyłem z takim które ma około tysiąca słów). Interesują mnie: sql i
> tablica parametrów. Po co miałbym to wciskać do kontrolki dbaware?

To, co napisałeś powyżej oznacza tylko tyle, że Ty nie masz zielonego pojęcia o kontrolkach dbaware.
Trudno się dziwić, skoro jedynie dotknąłeś tych kontrolek. Dbaware to są kontrolki wizualne!

A przykłady, które podajesz dotyczą kontrolek DAC (Data Access Controls), których używa się zarówno
z kontrolkami dbaware, jak i niezależnie od nich i nie ma to nic wspólnego z automatyzacją typowych
zadań, o których pisał J-23.

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/ 

W dniu środa, 15 maja 2019 13:54:59 UTC+2 użytkownik J-23 napisał:
> W dniu 15.05.2019 o 13:04, zpksoft pisze:
> > W dniu środa, 15 maja 2019 10:27:14 UTC+2 użytkownik lordbz napisał:
> >>> U mnie przeważnie zapytania sql są tworzone dynamicznie (..)
> >>>
> >>> Paweł
> >>
> >> Może jakiś mały konkretny przykład ....
> >> poproszę ?
> >>
> >> Przemek
> > 
> > No dobra, kawałek kodu (piszę z głowy):
> > 
> > var par: array of variant;
> > sql: string;
> > where: string;
> > i: integer;
> > begin
> >    sql:='select * from tabelka ';
> >    where:='';
> >    if cbDat.Checked then begin
> >      setLength(par, high(par)+2);
> >      par[high(par)]:=eDat.Value;
> >      where:=' where dat>:dat ';
> >    end;
> >    if cbMat.Checked then begin
> >      setLength(par, high(par)+2);
> >      par[high(par)]:=eMat.Value;
> >      if where='' then where:=' where mat=:mat '
> >      else where:=where+' and mat=:mat ';
> >    end;
> >    if cbPat.Checked then begin
> >      setLength(par, high(par)+2);
> >      par[high(par)]:=ePat.Value;
> >      if where='' then where:=' where pat containing :pat '
> >      else where:=where+' and pat containing :pat ';
> >    end;
> >    sql:=sql+where;
> >    
> >    query.sql:=sql;
> >    query.prepare; //inicjacja parametrów (ale nie ich typów!)
> >    
> >    for i:=0 to high(par) do
> >    begin
> >      query.params[i].value=par[i];
> >    end;
> >    
> >    //tu: ew. transakcja...
> >    query.open; //dla select
> > end;
> 
> Te kontrolki są do ułatwienia wielu rzeczy ale nie do wszystkiego - 
> głównym ich zadaniem jest ułatwienie połączenia warstwy GUI z warstwą 
> danych - by nie pisać kodu tam gdzie jest on zbędny.
> 
> Generowanie SQL to zupełnie inna bajka - u mnie (programuje teraz 
> głownie w Javie i czasem w Lazarus) załatwiam to jedną klasą w całej 
> aplikacji która w zależności od Parametrów generuje mi odpowiedni SQL i 
> w takim wypadku nie korzystam z żadnych kontrolek ani zwykłych ani DB bo 
> po co? Dane z kontrolek jeśli już są mi potrzebne bo np na ich podstawie 
> jest generowany sql przekazuje za pomocą odpowiedniego property który 
> znajduje się w klasie odpowiedzialnej za generowanie sql - po co? a no 
> wszystko mam zamknięte w jednym module (obsługa wyjątków itd).
> 
> Można by to zrobić bez kodu nawet typu przekazanie do property ale 
> wymagało by to napisania jeszcze jednego komponentu który kładę na formę 
> i wskazuje w edytorze odpowiednie kontrolki DB. Ale to zrobię jeśli będę 
> miał chwile czasu
> 
> PS a właśnie takie przykłady (choć rozumiem ze powyższy kod miał na celu 
> pokazanie problemu) ale to co jest powyżej to jest metoda drutowania o 
> której piszesz w tym wątku
> 
> Pozdrawiam

Drutowanie inaczej pojmuję :)
Ja bym to raczej nazwał programowaniem (chyba, że to pojęcie już wyszło z użycia?)

A tak konkretniej- pytający chciał prostej ilustracji w kodzie i ją podałem.

Paweł

W dniu środa, 15 maja 2019 14:03:07 UTC+2 użytkownik Krzysztof Szyszka napisał:
> > Kiedyś dotknąłem tych kontrolek ale szybko się z tego wycofałem. Doszedłem do wniosku że to tylko
> > do prostych zastosowań. Niby końcowa procka jest prosta (jak napisałeś) ale żeby taka była musisz
> > najpierw trochę podrutować. U mnie przeważnie zapytania sql są tworzone dynamicznie i są często
> > bardzo złożone (niedawno walczyłem z takim które ma około tysiąca słów). Interesują mnie: sql i
> > tablica parametrów. Po co miałbym to wciskać do kontrolki dbaware?
> 
> To, co napisałeś powyżej oznacza tylko tyle, że Ty nie masz zielonego pojęcia o kontrolkach dbaware.
> Trudno się dziwić, skoro jedynie dotknąłeś tych kontrolek. Dbaware to są kontrolki wizualne!
> 
> A przykłady, które podajesz dotyczą kontrolek DAC (Data Access Controls), których używa się zarówno
> z kontrolkami dbaware, jak i niezależnie od nich i nie ma to nic wspólnego z automatyzacją typowych
> zadań, o których pisał J-23.
> 
> -- 
> pozdrowienia
> Krzysztof Szyszka, X-Files Software
> Developer of X-DBGrid Component
> Embarcadero Technology Partner
> http://www.x-files.pl/

To czy i jakie pojęcie mam to nie do Twojej oceny bo Twoja wiedza na temat mojej wiedzy jest żadna. 
Takie kontrolki musisz zbindować ze źródłem danych. I o to mi chodziło.
Jeżeli źródło danych ma krótkie życie i jest powiązane z danymi w sposób określany dynamicznie to tworzenie tych powiązań w kodzie to właśnie dla mnie drutowanie. Ale to już dyskusja akademicka.

Dawno temu doszedłem do wniosku, ze kontrolki dbaware są może i sprytne ale do prostych zastosowań. 

Paweł

W dniu 15-05-2019 o 09:29, zpksoft pisze:

> Kiedyś dotknąłem tych kontrolek ale szybko się z tego wycofałem. Doszedłem do wniosku że to tylko do prostych zastosowań. Niby końcowa procka jest prosta (jak napisałeś) ale żeby taka była musisz najpierw trochę podrutować. U mnie przeważnie zapytania sql są tworzone dynamicznie i są często bardzo złożone (niedawno walczyłem z takim które ma około tysiąca słów). Interesują mnie: sql i tablica parametrów. Po co miałbym to wciskać do kontrolki dbaware?
> 

Większość komponentów typu TQuery-TUpdateSQL(i podobne od firm trzecich) 
miewa specjalny "automagiczny" generator zapytań InsertSQL, UpdateSQL, 
ModifySQL, DeleteSQL czy nawet LockSQL, RefreshSQL, FetchRowSQL z 
możliwościa ręcznej modyfikacji który w wielu przypadkach jest 
wystarczający.

Michał

> To czy i jakie pojęcie mam to nie do Twojej oceny bo Twoja wiedza na temat mojej wiedzy jest
> żadna. Takie kontrolki musisz zbindować ze źródłem danych. I o to mi chodziło.
> Jeżeli źródło danych ma krótkie życie i jest powiązane z danymi w sposób określany dynamicznie to
> tworzenie tych powiązań w kodzie to właśnie dla mnie drutowanie. Ale to już dyskusja akademicka.

Ty nadal nie wiesz, co to jest kontrolka dbaware :-) Zrozum wreszcie, że dbaware oznacza kontrolkę
sterowaną przez źródło danych (property DataSource), czyli to baza danych, a konkretnie to jedna
kontrolka DAC (np. TFDQuery), która łączy się z bazą danych, steruje wszystkimi kontrolkami
wizualnymi podłączonymi do wspólnego źródła danych, a kontrolki dbaware z automatu obsługują
wszystkie zdarzenia, jakie generuje źródło danych: Insert, Delete, Edit, Post, Cancel i to bez
pisania żadnego kodu, a Ty tu wyjeżdżasz z druciarstwem i krótkim życiem źródła danych.

Jest nawet DBNavigator, który pozwala użytkownikowi tworzyć te zdarzenia wizualnie na formatce,
więc nawet nie potrzeba żadnych dodatkowych buttonów do zapisania zmian wprowadzonych przez
użytkownika do bazy danych, a jeśli źródło danych może pracować w trybie "cached updates",
to masz również do dyspozycji przyciski ApplyUpdates i CancelUpdates, ale dla Ciebie to jest
druciarstwo, bo wymaga podłączenia jednego DataSource, zamiast pisania zajebistego kodu.
Zastanów się czasem co piszesz, albo nie pisz wcale, jak czegoś nie znasz lub nie rozumiesz :-)

> Dawno temu doszedłem do wniosku, ze kontrolki dbaware są może i sprytne ale do prostych
> zastosowań.

Tak informacyjnie, mój X-DBGrid to też kontrolka dbaware, ale tylko do prostych zastosowań,
bo do pełnej funkcjonalności Excela jeszcze jej trochę brakuje ;-)

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/ 

W dniu środa, 15 maja 2019 17:23:16 UTC+2 użytkownik Krzysztof Szyszka napisał:
> > To czy i jakie pojęcie mam to nie do Twojej oceny bo Twoja wiedza na temat mojej wiedzy jest
> > żadna. Takie kontrolki musisz zbindować ze źródłem danych. I o to mi chodziło.
> > Jeżeli źródło danych ma krótkie życie i jest powiązane z danymi w sposób określany dynamicznie to
> > tworzenie tych powiązań w kodzie to właśnie dla mnie drutowanie. Ale to już dyskusja akademicka.
> 
> Ty nadal nie wiesz, co to jest kontrolka dbaware :-) Zrozum wreszcie, że dbaware oznacza kontrolkę
> sterowaną przez źródło danych (property DataSource), czyli to baza danych, a konkretnie to jedna
> kontrolka DAC (np. TFDQuery), która łączy się z bazą danych, steruje wszystkimi kontrolkami
> wizualnymi podłączonymi do wspólnego źródła danych, a kontrolki dbaware z automatu obsługują
> wszystkie zdarzenia, jakie generuje źródło danych: Insert, Delete, Edit, Post, Cancel i to bez
> pisania żadnego kodu, a Ty tu wyjeżdżasz z druciarstwem i krótkim życiem źródła danych.
> 
> Jest nawet DBNavigator, który pozwala użytkownikowi tworzyć te zdarzenia wizualnie na formatce,
> więc nawet nie potrzeba żadnych dodatkowych buttonów do zapisania zmian wprowadzonych przez
> użytkownika do bazy danych, a jeśli źródło danych może pracować w trybie "cached updates",
> to masz również do dyspozycji przyciski ApplyUpdates i CancelUpdates, ale dla Ciebie to jest
> druciarstwo, bo wymaga podłączenia jednego DataSource, zamiast pisania zajebistego kodu.
> Zastanów się czasem co piszesz, albo nie pisz wcale, jak czegoś nie znasz lub nie rozumiesz :-)
> 
> > Dawno temu doszedłem do wniosku, ze kontrolki dbaware są może i sprytne ale do prostych
> > zastosowań.
> 
> Tak informacyjnie, mój X-DBGrid to też kontrolka dbaware, ale tylko do prostych zastosowań,
> bo do pełnej funkcjonalności Excela jeszcze jej trochę brakuje ;-)
> 
> -- 
> pozdrowienia
> Krzysztof Szyszka, X-Files Software
> Developer of X-DBGrid Component
> Embarcadero Technology Partner
> http://www.x-files.pl/

Wymądrzasz się i krytykujesz.
Ale odpowiem bo widzę że Ty nie rozumiesz. Tylko w prostych przypadkach masz w gridzie widok jednej tabeli. Zwykle jest to widok różnych pól z różnych tabel. I jak tu zrobić automatyczny insert/delete? Na czym? (możesz nie odpowiadać)

Paweł

> Wymądrzasz się i krytykujesz.
> Ale odpowiem bo widzę że Ty nie rozumiesz. Tylko w prostych przypadkach masz w gridzie widok
> jednej tabeli. Zwykle jest to widok różnych pól z różnych tabel. I jak tu zrobić automatyczny
> insert/delete? Na czym? (możesz nie odpowiadać)

Na czym chcesz :-) To ty dostarczasz dane do kontrolek dbaware, a tych kontrolek możesz mieć
kilka i możesz je podłączyć do różnych źródeł danych (tabel, query), a zmiany do bazy danych
zapisujesz fizycznie w ramach jednego wspólnego ApplyUpdates (w jednej transakcji).

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/ 

On Wed, 15 May 2019 08:34:11 -0700 (PDT), zpksoft wrote:

>>> Dawno temu doszedłem do wniosku, ze kontrolki dbaware są może i sprytne ale do prostych
>>> zastosowań.
>> 
>> Tak informacyjnie, mój X-DBGrid to też kontrolka dbaware, ale tylko do prostych zastosowań,
>> bo do pełnej funkcjonalności Excela jeszcze jej trochę brakuje ;-)

> Wymądrzasz się i krytykujesz.
> Ale odpowiem bo widzę że Ty nie rozumiesz. Tylko w prostych przypadkach masz w gridzie widok jednej tabeli. Zwykle jest to widok różnych pól z różnych tabel. I jak tu zrobić automatyczny insert/delete? Na czym? (możesz nie odpowiadać)

Znowu "miszczu" brnie w odchodach po pachy i poucza innych nie mając
fioletowego pojęcia o czym mowa. I tak za każdym razem, czy to grupa o JS
czy o Delphi, wiecznie ten sam bełkot "ja wiem lepiej niż wy, ale tego nie
rozumiecie, bo tak"... żenada do kwadratu.
Zajmij się czymś innym, może koszeniem trawników, choć pewnie tam też
będziesz mieć "lepsze rozwiązania" niż kosiarki dla idiotów.

-- 
pozdrawiam
Roman Tyczka

W dniu środa, 15 maja 2019 23:24:50 UTC+2 użytkownik Roman Tyczka napisał:
> On Wed, 15 May 2019 08:34:11 -0700 (PDT), zpksoft wrote:
> 
> >>> Dawno temu doszedłem do wniosku, ze kontrolki dbaware są może i sprytne ale do prostych
> >>> zastosowań.
> >> 
> >> Tak informacyjnie, mój X-DBGrid to też kontrolka dbaware, ale tylko do prostych zastosowań,
> >> bo do pełnej funkcjonalności Excela jeszcze jej trochę brakuje ;-)
> 
> > Wymądrzasz się i krytykujesz.
> > Ale odpowiem bo widzę że Ty nie rozumiesz. Tylko w prostych przypadkach masz w gridzie widok jednej tabeli. Zwykle jest to widok różnych pól z różnych tabel. I jak tu zrobić automatyczny insert/delete? Na czym? (możesz nie odpowiadać)
> 
> Znowu "miszczu" brnie w odchodach po pachy i poucza innych nie mając
> fioletowego pojęcia o czym mowa. I tak za każdym razem, czy to grupa o JS
> czy o Delphi, wiecznie ten sam bełkot "ja wiem lepiej niż wy, ale tego nie
> rozumiecie, bo tak"... żenada do kwadratu.
> Zajmij się czymś innym, może koszeniem trawników, choć pewnie tam też
> będziesz mieć "lepsze rozwiązania" niż kosiarki dla idiotów.
> 
> -- 
> pozdrawiam
> Roman Tyczka

I znów mnie ten kundel gryzie w nogawkę

Paweł

Zaraz , chwilka.... 
W programowaniu przecież nie ma jedynej słusznej drogi. To właśnie jest fajne, że dane rozwiązanie problemu jest możliwe na różne sposoby. Można podejść tak czy siak i jak mi to napisał Paweł:

"zrób jak uważasz i zobacz co z tego wyszło. 
Wyciągnij wnioski i doskonal swój warsztat w ten sposób. "

i wg mnie to jest słuszne. Spieranie się, dyskusje po świt też są potrzebne ale przecież każdy powinien pamiętać że nikt z nas nie posiadł wiedzy ostatecznej.Zatem dyskutujmy, rozmawiajmy a nawet spierajmy się ale .... Panowie .... na poziomie :-)
Pozdrawiam wszystkich i dziękuję

Przemek

W dniu 16.05.2019 o 10:26, lordbz pisze:
> Zaraz , chwilka....
> W programowaniu przecież nie ma jedynej słusznej drogi. To właśnie jest fajne, że dane rozwiązanie problemu jest możliwe na różne sposoby. Można podejść tak czy siak i jak mi to napisał Paweł:
> 
> "zrób jak uważasz i zobacz co z tego wyszło.
> Wyciągnij wnioski i doskonal swój warsztat w ten sposób. "
> 
> i wg mnie to jest słuszne. Spieranie się, dyskusje po świt też są potrzebne ale przecież każdy powinien pamiętać że nikt z nas nie posiadł wiedzy ostatecznej.Zatem dyskutujmy, rozmawiajmy a nawet spierajmy się ale .... Panowie .... na poziomie :-)
> Pozdrawiam wszystkich i dziękuję
> 
> Przemek
> 

Tu masz racje nikt nie zna metody na wszystko jest jednak podstawowa 
zasada kod ma byc czytelny i zrozumiały tak by go można było utrzymywać 
latami. To po pierwszej.

A pisanie kodu tam gdzie on jest zbędny zajmuje czas i wprowadza chaos 
do projektu.

Pamiętaj tez o tym ze łatwiej się nauczyć złych nawyków jak tych dobrych

Niestety to co prezentował zpksoft to są te złe nawyki - dodatkowo podał 
ci przykład zupełnie oderwany od twojego pytania. Bo tam kontrolki DB 
się nie używa bo nie ma takiej potrzeby

Pozdrawiam

W dniu środa, 15 maja 2019 00:36:35 UTC+2 użytkownik J-23 napisał:
> Odpisze w Twoim poście ale jest to odp dla ciebie i dla autora wątku. 
> Panowie dlaczego nie korzystacie z kontrolek DB i to co one dają? Czyli 
> możliwość zrobienia niemal wszystkiego automatycznie wystarczy 
> Datasource podpięcie odpowiedniego DataSeta (obojętne czy to będzie zeos 
> czy to będzie AnyDAC czy inne cudo - każdy z tych który podepniecie 
> wygeneruje za was podstawowe zapytanie INSERT bez grama pisania 
> jakiegokolwiek zapytania
> 
> Wasz jedyny kod który was obchodzi to
> 
> procedure OnClickButton(Sender: TObject)
> begin
>    DataSet.post - tylko tyle - by dodać cokolwiek do bazy
> end;
> 
> Zaraz ktoś napisze a to trzymana transakcja itd.
> 
> Ja na to... podstawowym punktem wyjściowym by sobie z takimi kłopotami 
> radzić jest "CecheUpdate"
> 
> Doczytać jak ta funkcja działa w poszczególnych produktach tj zeos, 
> anydac itp. i unikniecie takich problemów jak teraz
> 
> Można oczywiście się bawić w małych projektach w pisanie INSERT ręcznie 
> itp ale jest to w mojej opinii strata czasu.
> 
> Oczywiście ja tu mówię o absolutnych podstawach nie wspominając o tym że 
> są inne rozwiązania które oferują jeszcze znacznie więcej ponadto co ja 
> tu opisałem

To jest fajne do momentu gdy klepiesz wizualnie formatki :)
Ale ogólnie zgadzam się, po to są kontrolki DB w Delphi żeby coś robić prosto i nie wymyślać na nowo koła. :)

pozdrawiam,
Przemek O.

W dniu środa, 15 maja 2019 17:34:12 UTC+2 użytkownik zpksoft napisał:
> W dniu środa, 15 maja 2019 17:23:16 UTC+2 użytkownik Krzysztof Szyszka napisał:
> > > To czy i jakie pojęcie mam to nie do Twojej oceny bo Twoja wiedza na temat mojej wiedzy jest
> > > żadna. Takie kontrolki musisz zbindować ze źródłem danych. I o to mi chodziło.
> > > Jeżeli źródło danych ma krótkie życie i jest powiązane z danymi w sposób określany dynamicznie to
> > > tworzenie tych powiązań w kodzie to właśnie dla mnie drutowanie. Ale to już dyskusja akademicka.
> > 
> > Ty nadal nie wiesz, co to jest kontrolka dbaware :-) Zrozum wreszcie, że dbaware oznacza kontrolkę
> > sterowaną przez źródło danych (property DataSource), czyli to baza danych, a konkretnie to jedna
> > kontrolka DAC (np. TFDQuery), która łączy się z bazą danych, steruje wszystkimi kontrolkami
> > wizualnymi podłączonymi do wspólnego źródła danych, a kontrolki dbaware z automatu obsługują
> > wszystkie zdarzenia, jakie generuje źródło danych: Insert, Delete, Edit, Post, Cancel i to bez
> > pisania żadnego kodu, a Ty tu wyjeżdżasz z druciarstwem i krótkim życiem źródła danych.
> > 
> > Jest nawet DBNavigator, który pozwala użytkownikowi tworzyć te zdarzenia wizualnie na formatce,
> > więc nawet nie potrzeba żadnych dodatkowych buttonów do zapisania zmian wprowadzonych przez
> > użytkownika do bazy danych, a jeśli źródło danych może pracować w trybie "cached updates",
> > to masz również do dyspozycji przyciski ApplyUpdates i CancelUpdates, ale dla Ciebie to jest
> > druciarstwo, bo wymaga podłączenia jednego DataSource, zamiast pisania zajebistego kodu.
> > Zastanów się czasem co piszesz, albo nie pisz wcale, jak czegoś nie znasz lub nie rozumiesz :-)
> > 
> > > Dawno temu doszedłem do wniosku, ze kontrolki dbaware są może i sprytne ale do prostych
> > > zastosowań.
> > 
> > Tak informacyjnie, mój X-DBGrid to też kontrolka dbaware, ale tylko do prostych zastosowań,
> > bo do pełnej funkcjonalności Excela jeszcze jej trochę brakuje ;-)
> > 
> > -- 
> > pozdrowienia
> > Krzysztof Szyszka, X-Files Software
> > Developer of X-DBGrid Component
> > Embarcadero Technology Partner
> > http://www.x-files.pl/
> 
> Wymądrzasz się i krytykujesz.
> Ale odpowiem bo widzę że Ty nie rozumiesz. Tylko w prostych przypadkach masz w gridzie widok jednej tabeli. Zwykle jest to widok różnych pól z różnych tabel. I jak tu zrobić automatyczny insert/delete? Na czym? (możesz nie odpowiadać)
> 
> Paweł

No i?

Większość sensownych komponentów dostępowych do baz ma możliwość łączenia widoku i robienia insert/update na wielu tabelach. 

Pomijam sensowność grzebania "bezpośrednio" na tabelach, chyba że nie używasz do tego żadnego serwera bazodanowego lub sprowadzasz go jedynie do roli przechowywania danych.
W większych projektach istotnym jest rozdzielenie fizycznej struktury bazy danych (tabel) od tego co możemy wyświetlić (widoki) oraz dodawać/zmieniać (procedury). Daje to nam niezależność widoku od struktury która może się zmieniać, i nie każda zmiana w strukturze pociąga od razu zmianę kodu aplikacji.

Poza tym (trochę odbiegając od wątku) takie tworzenie SQLa jak pokazałeś powyżej to jest "drutowanie" najwyższej klasy. Ogólnie - takie wymaganie (generowania SQLa wg parametrów) to norma, ale na litość opakuj to w jakiś SQL generator. Raz napisany i przetestowany pozwoli unikać błędów i problemów w przyszłości. IMHO to jeden z pierwszych elementów które trzeba ogarnąć gdy odchodzi się od klikanego programowania...

pozdrawiam,
Przemek O.

>ciach
> Poza tym (trochę odbiegając od wątku) takie tworzenie SQLa jak pokazałeś powyżej to jest "drutowanie" najwyższej klasy. Ogólnie - takie wymaganie (generowania SQLa wg parametrów) to norma, ale na litość opakuj to w jakiś SQL generator. Raz napisany i przetestowany pozwoli unikać błędów i problemów w przyszłości. IMHO to jeden z pierwszych elementów które trzeba ogarnąć gdy odchodzi się od klikanego programowania...
> 
> pozdrawiam,
> Przemek O.

Przecież to jest szkolny przykład. Nie zauważyłeś? Pytający prosił o przykład to go mu podałem.

Zresztą, nie ma nic złego w tym kodzie.

A "drutowanie" - to mnie drażni. Osobiścice lubię programować, sprawia mi to przyjemność :)

Paweł

W dniu 17.05.2019 o 23:16, zpksoft pisze:
>> ciach
>> Poza tym (trochę odbiegając od wątku) takie tworzenie SQLa jak pokazałeś powyżej to jest "drutowanie" najwyższej klasy. Ogólnie - takie wymaganie (generowania SQLa wg parametrów) to norma, ale na litość opakuj to w jakiś SQL generator. Raz napisany i przetestowany pozwoli unikać błędów i problemów w przyszłości. IMHO to jeden z pierwszych elementów które trzeba ogarnąć gdy odchodzi się od klikanego programowania...
>>
>> pozdrawiam,
>> Przemek O.
> 
> Przecież to jest szkolny przykład. Nie zauważyłeś? Pytający prosił o przykład to go mu podałem.

Jeśli nawet to jest szkolny przykład to nie oznacza to że trzeba 
wymyślać "koło na nowo" a ty to próbujesz robić. To po pierwsze

Po drugie podałeś przykład z sufitu, oderwany od wątku bo autor wątku 
zakładając wątek pytał o zupełnie inną rzecz.

> 
> Zresztą, nie ma nic złego w tym kodzie.

Jak te próbke kodu nazywasz dobrym kodem to ja nie chciałbym zobaczyć 
"większego kawałka" bo to byłby groch z kapustą pewnie

> 
> A "drutowanie" - to mnie drażni. Osobiścice lubię programować, sprawia mi to przyjemność :)

Czytałeś wypowiedź Przemka O? Jak nazwał twój kod? Niestety ale miał 
100% racji

Pozdrawiam
J-23

W dniu piątek, 17 maja 2019 23:37:41 UTC+2 użytkownik J-23 napisał:
> W dniu 17.05.2019 o 23:16, zpksoft pisze:
> >> ciach
> >> Poza tym (trochę odbiegając od wątku) takie tworzenie SQLa jak pokazałeś powyżej to jest "drutowanie" najwyższej klasy. Ogólnie - takie wymaganie (generowania SQLa wg parametrów) to norma, ale na litość opakuj to w jakiś SQL generator. Raz napisany i przetestowany pozwoli unikać błędów i problemów w przyszłości. IMHO to jeden z pierwszych elementów które trzeba ogarnąć gdy odchodzi się od klikanego programowania...
> >>
> >> pozdrawiam,
> >> Przemek O.
> > 
> > Przecież to jest szkolny przykład. Nie zauważyłeś? Pytający prosił o przykład to go mu podałem.
> 
> Jeśli nawet to jest szkolny przykład to nie oznacza to że trzeba 
> wymyślać "koło na nowo" a ty to próbujesz robić. To po pierwsze
> 
> Po drugie podałeś przykład z sufitu, oderwany od wątku bo autor wątku 
> zakładając wątek pytał o zupełnie inną rzecz.
> 
> > 
> > Zresztą, nie ma nic złego w tym kodzie.
> 
> Jak te próbke kodu nazywasz dobrym kodem to ja nie chciałbym zobaczyć 
> "większego kawałka" bo to byłby groch z kapustą pewnie
> 
> > 
> > A "drutowanie" - to mnie drażni. Osobiścice lubię programować, sprawia mi to przyjemność :)
> 
> Czytałeś wypowiedź Przemka O? Jak nazwał twój kod? Niestety ale miał 
> 100% racji
> 
> Pozdrawiam
> J-23

To ja Ciebie teraz poproszę o alternatywne rozwiązanie zagadnienia które przedstawiłem w kodzie. Dwa check-boxy i dwie kontrolki edycyjne.
Ciekaw jestem jak to będzie wyglądało "bez drutowania"

Paweł

> To ja Ciebie teraz poproszę o alternatywne rozwiązanie zagadnienia które przedstawiłem w kodzie. Dwa check-boxy i dwie kontrolki edycyjne.
> Ciekaw jestem jak to będzie wyglądało "bez drutowania"
> 
> Paweł

Jak cos od poczatku jest "drutem", to rzeczywiscie trudo nie drutowac :-).

1. Uzyj komponentow DB, czyli DBCheckBox i DBEdit (dla przykladu)
2. Powiaz z lokalnym DataSet, np. ClientDataSet (oczywiscie, moze byc ich wiele ...)
3. Uzyj tego co ClientDataSet oferuje z automatu (osobiscie nie uzywam) do zapisu do bazy danych.
4. Napisz automatyzacje kodu zapisu do bazy danych (w tym przypadku DB moze byc dowolna) tego co masz w lokalnym DataSeci'e (ja tak robie)
5. Przyklad kodu SQL'a automatyzacji dla Firebird'a 

function CreateUpdateOrInsertCommand(LocalTable: TDataSet; pozycje: TList;
  tableName: string; MatchingFields: array of string; params: TParams): string;
var
  i: integer;
  poz: string;
  sqlcomm: string;
  sep: Boolean;

  function GetMatchingCondition(MatchingFields: array of string): string;
  var
    i: integer;
    cmd: string;
  begin
    cmd := '';
    for i := 0 to high(MatchingFields) do
      cmd := cmd + MatchingFields[i] + ',';
    cmd := Copy(cmd, 1, length(cmd) - 1);
    Result := cmd;

  end;

begin
  sep := False;
  sqlcomm := 'UPDATE OR INSERT INTO ' + tableName + ' ( ';
  for i := 0 to pozycje.Count - 1 do
  begin
    poz := PString(pozycje[i])^;
    if LocalTable.FieldByName(poz).FieldKind = fkData then
    begin
      if sep = true then
        sqlcomm := sqlcomm + ', ';
      sqlcomm := sqlcomm + poz;
      sep := true;
    end;
  end;
  sqlcomm := sqlcomm + ') VALUES (';
  sep := False;
  for i := 0 to pozycje.Count - 1 do
  begin
    poz := PString(pozycje[i])^;
    if LocalTable.FieldByName(poz).FieldKind = fkData then
    begin
      if sep = true then
        sqlcomm := sqlcomm + ', ';
      sqlcomm := sqlcomm + ':' + poz;
      params.Add;
      params[params.Count - 1].name := poz;
      params[params.Count - 1].DataType := LocalTable.FieldByName(poz).DataType;
      if not LocalTable.FieldByName(poz).IsNull then
        params[params.Count - 1].Value := LocalTable.FieldByName(poz).Value;
      sep := true;
    end;
  end;
  sqlcomm := sqlcomm + ')';
  sqlcomm := sqlcomm + ' MATCHING( ' + GetMatchingCondition
    (MatchingFields) + ')';
  Result := sqlcomm;

end;

Ps.
Jak Ci 3 osby mowia, ze jestes pijany, to poloz sie spac :-)

Pozdrawiam 
----
Roman
 


 

W dniu sobota, 18 maja 2019 12:01:10 UTC+2 użytkownik Roman Wilk napisał:
> > To ja Ciebie teraz poproszę o alternatywne rozwiązanie zagadnienia które przedstawiłem w kodzie. Dwa check-boxy i dwie kontrolki edycyjne.
> > Ciekaw jestem jak to będzie wyglądało "bez drutowania"
> > 
> > Paweł
> 
> Jak cos od poczatku jest "drutem", to rzeczywiscie trudo nie drutowac :-).
> 
> 1. Uzyj komponentow DB, czyli DBCheckBox i DBEdit (dla przykladu)
> 2. Powiaz z lokalnym DataSet, np. ClientDataSet (oczywiscie, moze byc ich wiele ...)
> 3. Uzyj tego co ClientDataSet oferuje z automatu (osobiscie nie uzywam) do zapisu do bazy danych.
> 4. Napisz automatyzacje kodu zapisu do bazy danych (w tym przypadku DB moze byc dowolna) tego co masz w lokalnym DataSeci'e (ja tak robie)
> 5. Przyklad kodu SQL'a automatyzacji dla Firebird'a 
> 
> function CreateUpdateOrInsertCommand(LocalTable: TDataSet; pozycje: TList;
>   tableName: string; MatchingFields: array of string; params: TParams): string;
> var
>   i: integer;
>   poz: string;
>   sqlcomm: string;
>   sep: Boolean;
> 
>   function GetMatchingCondition(MatchingFields: array of string): string;
>   var
>     i: integer;
>     cmd: string;
>   begin
>     cmd := '';
>     for i := 0 to high(MatchingFields) do
>       cmd := cmd + MatchingFields[i] + ',';
>     cmd := Copy(cmd, 1, length(cmd) - 1);
>     Result := cmd;
> 
>   end;
> 
> begin
>   sep := False;
>   sqlcomm := 'UPDATE OR INSERT INTO ' + tableName + ' ( ';
>   for i := 0 to pozycje.Count - 1 do
>   begin
>     poz := PString(pozycje[i])^;
>     if LocalTable.FieldByName(poz).FieldKind = fkData then
>     begin
>       if sep = true then
>         sqlcomm := sqlcomm + ', ';
>       sqlcomm := sqlcomm + poz;
>       sep := true;
>     end;
>   end;
>   sqlcomm := sqlcomm + ') VALUES (';
>   sep := False;
>   for i := 0 to pozycje.Count - 1 do
>   begin
>     poz := PString(pozycje[i])^;
>     if LocalTable.FieldByName(poz).FieldKind = fkData then
>     begin
>       if sep = true then
>         sqlcomm := sqlcomm + ', ';
>       sqlcomm := sqlcomm + ':' + poz;
>       params.Add;
>       params[params.Count - 1].name := poz;
>       params[params.Count - 1].DataType := LocalTable.FieldByName(poz).DataType;
>       if not LocalTable.FieldByName(poz).IsNull then
>         params[params.Count - 1].Value := LocalTable.FieldByName(poz).Value;
>       sep := true;
>     end;
>   end;
>   sqlcomm := sqlcomm + ')';
>   sqlcomm := sqlcomm + ' MATCHING( ' + GetMatchingCondition
>     (MatchingFields) + ')';
>   Result := sqlcomm;
> 
> end;
> 
> Ps.
> Jak Ci 3 osby mowia, ze jestes pijany, to poloz sie spac :-)
> 
> Pozdrawiam 
> ----
> Roman

Człowieku, przecież ty ręcznie ulepiłeś sql-a, podobnie jak ja.

Paweł

W dniu sobota, 18 maja 2019 12:15:28 UTC+2 użytkownik zpksoft napisał:
> W dniu sobota, 18 maja 2019 12:01:10 UTC+2 użytkownik Roman Wilk napisał:
> > > To ja Ciebie teraz poproszę o alternatywne rozwiązanie zagadnienia które przedstawiłem w kodzie. Dwa check-boxy i dwie kontrolki edycyjne.
> > > Ciekaw jestem jak to będzie wyglądało "bez drutowania"
> > > 
> > > Paweł
> > 
> > Jak cos od poczatku jest "drutem", to rzeczywiscie trudo nie drutowac :-).
> > 
> > 1. Uzyj komponentow DB, czyli DBCheckBox i DBEdit (dla przykladu)
> > 2. Powiaz z lokalnym DataSet, np. ClientDataSet (oczywiscie, moze byc ich wiele ...)
> > 3. Uzyj tego co ClientDataSet oferuje z automatu (osobiscie nie uzywam) do zapisu do bazy danych.
> > 4. Napisz automatyzacje kodu zapisu do bazy danych (w tym przypadku DB moze byc dowolna) tego co masz w lokalnym DataSeci'e (ja tak robie)
> > 5. Przyklad kodu SQL'a automatyzacji dla Firebird'a 
> > 
> > function CreateUpdateOrInsertCommand(LocalTable: TDataSet; pozycje: TList;
> >   tableName: string; MatchingFields: array of string; params: TParams): string;
> > var
> >   i: integer;
> >   poz: string;
> >   sqlcomm: string;
> >   sep: Boolean;
> > 
> >   function GetMatchingCondition(MatchingFields: array of string): string;
> >   var
> >     i: integer;
> >     cmd: string;
> >   begin
> >     cmd := '';
> >     for i := 0 to high(MatchingFields) do
> >       cmd := cmd + MatchingFields[i] + ',';
> >     cmd := Copy(cmd, 1, length(cmd) - 1);
> >     Result := cmd;
> > 
> >   end;
> > 
> > begin
> >   sep := False;
> >   sqlcomm := 'UPDATE OR INSERT INTO ' + tableName + ' ( ';
> >   for i := 0 to pozycje.Count - 1 do
> >   begin
> >     poz := PString(pozycje[i])^;
> >     if LocalTable.FieldByName(poz).FieldKind = fkData then
> >     begin
> >       if sep = true then
> >         sqlcomm := sqlcomm + ', ';
> >       sqlcomm := sqlcomm + poz;
> >       sep := true;
> >     end;
> >   end;
> >   sqlcomm := sqlcomm + ') VALUES (';
> >   sep := False;
> >   for i := 0 to pozycje.Count - 1 do
> >   begin
> >     poz := PString(pozycje[i])^;
> >     if LocalTable.FieldByName(poz).FieldKind = fkData then
> >     begin
> >       if sep = true then
> >         sqlcomm := sqlcomm + ', ';
> >       sqlcomm := sqlcomm + ':' + poz;
> >       params.Add;
> >       params[params.Count - 1].name := poz;
> >       params[params.Count - 1].DataType := LocalTable.FieldByName(poz).DataType;
> >       if not LocalTable.FieldByName(poz).IsNull then
> >         params[params.Count - 1].Value := LocalTable.FieldByName(poz).Value;
> >       sep := true;
> >     end;
> >   end;
> >   sqlcomm := sqlcomm + ')';
> >   sqlcomm := sqlcomm + ' MATCHING( ' + GetMatchingCondition
> >     (MatchingFields) + ')';
> >   Result := sqlcomm;
> > 
> > end;
> > 
> > Ps.
> > Jak Ci 3 osby mowia, ze jestes pijany, to poloz sie spac :-)
> > 
> > Pozdrawiam 
> > ----
> > Roman
> 
> Człowieku, przecież ty ręcznie ulepiłeś sql-a, podobnie jak ja.
> 
> Paweł

Ty tak serio ?

Nie widzisz roznicy pomiedzy tym co Ty napisales, a moim przykladem na to, ze kontrolki DB, sa jednak przydatne :-)
Bo jesli tak, to rzeczywiscie przemysl czy programowanie "zarobkowe" to, to co powinienies robic.

Pozdrawiam
----
Roman

W dniu sobota, 18 maja 2019 12:42:28 UTC+2 użytkownik Roman Wilk napisał:
> W dniu sobota, 18 maja 2019 12:15:28 UTC+2 użytkownik zpksoft napisał:
> > W dniu sobota, 18 maja 2019 12:01:10 UTC+2 użytkownik Roman Wilk napisał:
> > > > To ja Ciebie teraz poproszę o alternatywne rozwiązanie zagadnienia które przedstawiłem w kodzie. Dwa check-boxy i dwie kontrolki edycyjne.
> > > > Ciekaw jestem jak to będzie wyglądało "bez drutowania"
> > > > 
> > > > Paweł
> > > 
> > > Jak cos od poczatku jest "drutem", to rzeczywiscie trudo nie drutowac :-).
> > > 
> > > 1. Uzyj komponentow DB, czyli DBCheckBox i DBEdit (dla przykladu)
> > > 2. Powiaz z lokalnym DataSet, np. ClientDataSet (oczywiscie, moze byc ich wiele ...)
> > > 3. Uzyj tego co ClientDataSet oferuje z automatu (osobiscie nie uzywam) do zapisu do bazy danych.
> > > 4. Napisz automatyzacje kodu zapisu do bazy danych (w tym przypadku DB moze byc dowolna) tego co masz w lokalnym DataSeci'e (ja tak robie)
> > > 5. Przyklad kodu SQL'a automatyzacji dla Firebird'a 
> > > 
> > > function CreateUpdateOrInsertCommand(LocalTable: TDataSet; pozycje: TList;
> > >   tableName: string; MatchingFields: array of string; params: TParams): string;
> > > var
> > >   i: integer;
> > >   poz: string;
> > >   sqlcomm: string;
> > >   sep: Boolean;
> > > 
> > >   function GetMatchingCondition(MatchingFields: array of string): string;
> > >   var
> > >     i: integer;
> > >     cmd: string;
> > >   begin
> > >     cmd := '';
> > >     for i := 0 to high(MatchingFields) do
> > >       cmd := cmd + MatchingFields[i] + ',';
> > >     cmd := Copy(cmd, 1, length(cmd) - 1);
> > >     Result := cmd;
> > > 
> > >   end;
> > > 
> > > begin
> > >   sep := False;
> > >   sqlcomm := 'UPDATE OR INSERT INTO ' + tableName + ' ( ';
> > >   for i := 0 to pozycje.Count - 1 do
> > >   begin
> > >     poz := PString(pozycje[i])^;
> > >     if LocalTable.FieldByName(poz).FieldKind = fkData then
> > >     begin
> > >       if sep = true then
> > >         sqlcomm := sqlcomm + ', ';
> > >       sqlcomm := sqlcomm + poz;
> > >       sep := true;
> > >     end;
> > >   end;
> > >   sqlcomm := sqlcomm + ') VALUES (';
> > >   sep := False;
> > >   for i := 0 to pozycje.Count - 1 do
> > >   begin
> > >     poz := PString(pozycje[i])^;
> > >     if LocalTable.FieldByName(poz).FieldKind = fkData then
> > >     begin
> > >       if sep = true then
> > >         sqlcomm := sqlcomm + ', ';
> > >       sqlcomm := sqlcomm + ':' + poz;
> > >       params.Add;
> > >       params[params.Count - 1].name := poz;
> > >       params[params.Count - 1].DataType := LocalTable.FieldByName(poz).DataType;
> > >       if not LocalTable.FieldByName(poz).IsNull then
> > >         params[params.Count - 1].Value := LocalTable.FieldByName(poz).Value;
> > >       sep := true;
> > >     end;
> > >   end;
> > >   sqlcomm := sqlcomm + ')';
> > >   sqlcomm := sqlcomm + ' MATCHING( ' + GetMatchingCondition
> > >     (MatchingFields) + ')';
> > >   Result := sqlcomm;
> > > 
> > > end;
> > > 
> > > Ps.
> > > Jak Ci 3 osby mowia, ze jestes pijany, to poloz sie spac :-)
> > > 
> > > Pozdrawiam 
> > > ----
> > > Roman
> > 
> > Człowieku, przecież ty ręcznie ulepiłeś sql-a, podobnie jak ja.
> > 
> > Paweł
> 
> Ty tak serio ?
> 
> Nie widzisz roznicy pomiedzy tym co Ty napisales, a moim przykladem na to, ze kontrolki DB, sa jednak przydatne :-)
> Bo jesli tak, to rzeczywiscie przemysl czy programowanie "zarobkowe" to, to co powinienies robic.
> 
> Pozdrawiam
> ----
> Roman

Krótka analiza:

Mój kod: 38 linii, 109 słów, 923 znaków,
Twój kod: 60 lnii, 227 słów, 1679 znaków,

cytat z mojego kodu (tworzenie sql):
>    if where='' then where:=' where mat=:mat '
>    else where:=where+' and mat=:mat ';
>    sql:=sql+where;

cytat z twojego kodu (tworzenie sql):
>      if sep = true then
>        sqlcomm := sqlcomm + ', ';
>      sqlcomm := sqlcomm + ':' + poz;


To by było na tyle, odłączam się od tego wątku bo to już tylko bicie piany.

Paweł

W dniu 18.05.2019 o 08:36, zpksoft pisze:
> W dniu piątek, 17 maja 2019 23:37:41 UTC+2 użytkownik J-23 napisał:
>> W dniu 17.05.2019 o 23:16, zpksoft pisze:
>>>> ciach
>>>> Poza tym (trochę odbiegając od wątku) takie tworzenie SQLa jak pokazałeś powyżej to jest "drutowanie" najwyższej klasy. Ogólnie - takie wymaganie (generowania SQLa wg parametrów) to norma, ale na litość opakuj to w jakiś SQL generator. Raz napisany i przetestowany pozwoli unikać błędów i problemów w przyszłości. IMHO to jeden z pierwszych elementów które trzeba ogarnąć gdy odchodzi się od klikanego programowania...
>>>>
>>>> pozdrawiam,
>>>> Przemek O.
>>>
>>> Przecież to jest szkolny przykład. Nie zauważyłeś? Pytający prosił o przykład to go mu podałem.
>>
>> Jeśli nawet to jest szkolny przykład to nie oznacza to że trzeba
>> wymyślać "koło na nowo" a ty to próbujesz robić. To po pierwsze
>>
>> Po drugie podałeś przykład z sufitu, oderwany od wątku bo autor wątku
>> zakładając wątek pytał o zupełnie inną rzecz.
>>
>>>
>>> Zresztą, nie ma nic złego w tym kodzie.
>>
>> Jak te próbke kodu nazywasz dobrym kodem to ja nie chciałbym zobaczyć
>> "większego kawałka" bo to byłby groch z kapustą pewnie
>>
>>>
>>> A "drutowanie" - to mnie drażni. Osobiścice lubię programować, sprawia mi to przyjemność :)
>>
>> Czytałeś wypowiedź Przemka O? Jak nazwał twój kod? Niestety ale miał
>> 100% racji
>>
>> Pozdrawiam
>> J-23
> 
> To ja Ciebie teraz poproszę o alternatywne rozwiązanie zagadnienia które przedstawiłem w kodzie. Dwa check-boxy i dwie kontrolki edycyjne.
> Ciekaw jestem jak to będzie wyglądało "bez drutowania"
> 

Nie musisz drutować wystarczy użyć odpowiednio klasy DataSet i napisać 
sobie generator SQL który ci wygeneruje dowolny kod dla ilu tam CheckBox 
i kontrolek edycyjnych chcesz

Pisałem już tutaj w wątku o oddzielnej klasie która za pomocą property 
(można też bez property, ale wymaga dodatkowego kodu) generuje ci 
odpowiedni sql - i tego się nie da zamknąć w jednej procedurze a klasie 
wtedy masz wszystko w jednym miejscu. Dla całego programu.

Zresztą o generatorze sql nie tylko ja wspominam, wspomina też 
Przemysław O. Poczytaj o możliwościach DataSet wtedy nie będziesz pisał 
bzdur typu że "kontrolki DB są do prostych rzeczy"

Pozdrawiam
J-23

W dniu 18.05.2019 o 14:14, zpksoft pisze:
> Krótka analiza:
> 
> Mój kod: 38 linii, 109 słów, 923 znaków,
> Twój kod: 60 lnii, 227 słów, 1679 znaków,

Ty tak na serio? patrzysz na kod pod względem użycia ilośći znakow czy 
linijek?

> 
> cytat z mojego kodu (tworzenie sql):
>>     if where='' then where:=' where mat=:mat '
>>     else where:=where+' and mat=:mat ';
>>     sql:=sql+where;
> 
> cytat z twojego kodu (tworzenie sql):
>>       if sep = true then
>>         sqlcomm := sqlcomm + ', ';
>>       sqlcomm := sqlcomm + ':' + poz;
> 
> 
> To by było na tyle, odłączam się od tego wątku bo to już tylko bicie piany.
> 
Jesli tak to faktycznie dalsza dyskusja nie ma sensu

Pozdrawiam
J-23