TFDTable.Active := False - pri spustení programu

[Stanislav Hruška]

Keďže zabúdam tak som urobil nalsedovné

Kód: [Vybrat]

procedure TdtmdBasic.DataModuleCreate(Sender: TObject);
var
  I: Integer;
begin
  for I := 0 to Self.ComponentCount -1 do
  begin
    if (Self.Components[I] is TFDTable) then
       TFDTable(Self.Components[I]).Active := False
    else
    if (Self.Components[I] is TFDStoredProc) then
       TFDStoredProc(Self.Components[I]).Active := False;
  end;
end;
Ale to je už neskoro. Tabuľky sa pripájajú ešte pred volaním tejto udalosti. Ako sa to dá riešiť programovo?

[Radek Červinka]

Jediné dvě varianty co mne napadají:
- máš vlastní podědene následniky a predefinujes SetActive datasetu na neco jako

Kód: [Vybrat]

procedure TDataSetXXX.SetActive(Value: Boolean);
begin
  if (csReading in ComponentState) then
  begin
    inherited(False);
  end
  else
    inherited(Value);
end;

nebo si napises nejaky nastroj, ktery kdyz spustis, tak ti probehne DFM a nastavi Active = False

[Stanislav Hruška]

nebo si napises nejaky nastroj, ktery kdyz spustis, tak ti probehne DFM a nastavi Active = False

To mi stačí hromadne myškou vybrať všetko v DataModul-e a nastaviť Active na False.

Tomu príkladu vôbec nerozumiem.
Ale teraz ma napadlo. Najprv vytvorím DataModulConnection a zruším pripojenia. To už robím. Potom nastavím databázy a aktivujem pripojenia. Až tak vytvorím DataModul-y s tabuľkami, SP a pod. To už bude všetko v poriadku. Nejaké zabudnuté Active =True ma už nebude trápiť. Idem to vyskúšať.

[Radek Červinka]

Tak jen pro uplnost k tomu mému examplu: podle mne je obecne dobre mit vlastni komponenty, i kdyby to bylo jen
TMyCoolQuery = class(TFDQuery)

Má to tu výhodu, že pokud vyměníš komponenty, třeba ADO za FireDAC nebo za UniDAC, tak staci doimplementovat chybejici chovani a OK.

A protože mám vlastní komponenty, tak s tím mohu čarovat.
To SetActive je zapisova metoda pro property TDataSet.Active, a funguje to tak, že během načítání formuláře je nastaveno csReading ve stavu komponenty, a konkretně SetActive to využívá tak, že si poznačí stav Active a až je komponenta načtena, tak tuto zapamatovanou hodnotu použije. No a já jsem udělal to, že jsem tento stav odchytil a manualne ho nastavil na False, tj. jako by se z DFM vzdy nacetlo False. Nezkousel jsem, ale podle implementace SetActive  v TDataset to tímto způsobem funguje.

Jinak už dlouho vytvářím DB komponenty za běhu, takže takové problémy s Active neřeším.

[Stanislav Hruška]

Jinak už dlouho vytvářím DB komponenty za běhu, takže takové problémy s Active neřeším.

Týka sa to aj connection?
To sa snažím aj ja. Ale vytvárať SP (a Connection?) za behu sa mi nevidí až tak dobré riešenie. Musel by som im nastaviť vstupné aj výstupné parametre a ešte neviem čo.

Zásadne používam FireDAC. Nič iné používať určite nebudem.
Celý problém je v tom, že sa nedokážem pripojiť DB v inom adresári. Ak zmením adresár aplikácie.

PS: Ten môj predpoklad sa mi akosi nepotvrdzuje Nedostanem sa do časti Create datamodu-lu s connection.

[Stanislav Hruška]

Upresňujem. Napojím sa ak v čase návrhu, pred kompiláciou, vypnem pripojenia.

[Stanislav Hruška]

No a já jsem udělal to, že jsem tento stav odchytil a manualne ho nastavil na False, tj. jako by se z DFM vzdy nacetlo False.

Kedy a kde, toť otázka. DataModul má len dve udalosti. Create a Destroy. A v create je už NESKORO. A pred vytvorením formulára sa niet o čom baviť. "Počas načítania" je pre mňa zakázaná oblasť.

Samozrejme, že chcem mať connection  počas návrhu. Tak sa mnohé veci robia ľahšie. Napríklad si vytvorím TTable či SP. Všetko vyskúšam a potom môžem vymazať tabuľku a prejsť na jej dynamické vytváranie.

[Radek Červinka]

Ok, tak jinak, ukazi ti hack:
Na zacatek DataModulu, PRED deklaraci datamodulu a za type napis

Kód: [Vybrat]

type
  TFDQuery = class (FireDac.Comp.Client.TFDQuery)
  protected
    procedure SetActive(Value:Boolean); override;
  end;

tady pak bude ten
  TDataModulex = class (TDataModule) nebo (TForm) proste to co tam bylo
a nekde do implementace pak

Kód: [Vybrat]

procedure TFDQuery.SetActive(Value: Boolean);
begin
  if (csReading in ComponentState) then
  begin
    inherited SetActive (False);
  end
  else
    inherited SetActive(Value);
end;

A je to. Zblbl jsem kompilator, tak, ze pouzije moje TFDQuery misto FireDac.Comp.Client.TFDQuery.
To same musis udelat pro FDStoredProc nebo jak se to jmenuje.

Pro info: zkusil jsem to, mel jsem na formulari Query, ktera byla aktivni a po startu uz aktivni neni.

[Daniel_Andrascik]

Jinak už dlouho vytvářím DB komponenty za běhu, takže takové problémy s Active neřeším.

Týka sa to aj connection?
To sa snažím aj ja. Ale vytvárať SP (a Connection?) za behu sa mi nevidí až tak dobré riešenie. Musel by som im nastaviť vstupné aj výstupné parametre a ešte neviem čo.

iba drobna vseobecna poznamka k tomuto pre Stana. Praveze cim viac vlastnosti musis u danej komponenty nastavovat, tym vhodnejsie je tvorit ich za behu, alebo aspon tie vlastnosti nastavovat za behu. Teraz ma vseci klikači budu chciet upalit. Ale ono je to ok pokial na tej aplikacii prave aktivne pracujes a pracujes na nej sam. Ale ked po piatich rokoch otovoris datamodul s 15timi komponentami o ktorych si uz nemapatas ani makke f tak budes pol hodiny rozklikavat vsetky vlastnosti a priradenia a hladat v zaludne pomenovanych connectionoch a datasetoch, ze co je s cim pospajane, co ma jake parametre nastavne a aj tak ziskas len vseobecnu predstavu o koncepcii. A maximalne bude nadavat niekto cudzi ktory zacne po tebe ten projektu studovat. Ak to mas ponastavovane v kode, zvycajne je to v nejakej create alebo init procedure tak si to otvoris a v niekolkych odstavcekoch pekne za 30 sekund vidis koncepciu, nic neprehliadnes. Tot vse co som chcel k tomu povedat

[pf1957]

Samozrejme, že chcem mať connection  počas návrhu. Tak sa mnohé veci robia ľahšie. Napríklad si vytvorím TTable či SP. Všetko vyskúšam a potom môžem vymazať tabuľku a prejsť na jej dynamické vytváranie.

Ja to nikdy nepouzivam.

Na hrani mam piskoviste, kde si Quick&Dirty zpusobem nastrikam, co potrebuju vyzkouset a nezapleveluju si tim aplikaci. A podobne jako Radek, vetsinu veci delam v run-time, protoze nesnasim, kdyz je napr. SQL rozesety po vsech certech: neco v .pas, neco v .dfm apod. Kdyz pak clovek neco potrebuje ve vetsim rozsahu zmenit napr. prechod na jinou knihovnu apod., tak musi rucne editovat .dfm a nebo se uklikat k smrti, nez proleze vsechny komponenty nasazene buhvi kam v design time.

[Stanislav Hruška]

Tak som to aplikoval na connection

Kód: Delphi [Vybrat]

1. type
2.   TFDConnection = class (FireDac.Comp.Client.TFDConnection)
3.   protected
4.     procedure SetConnected(Value:Boolean); override;
5.   end;
6.  
7.  
8. procedure TFDConnection.SetConnected(Value: Boolean);
9. begin
10.   if (csReading in ComponentState) then
11.   begin
12.     inherited SetConnected (False);
13.   end
14.   else
15.     inherited SetConnected(Value);
16. end;
17.  

a funguje to.

Ale to ihrisko sa mi veľmi páči. Občas ho používam, ale takto ma to nenapadlo  
Predpokladám, že napríklad pre Connection sa nastaví Owner
 - buď nil a musím sa postarať o jeho zničenie, alebo
 - napr. MainForm.

Idem do prerobiť do runtime

[Stanislav Hruška]

Dodatok: predpokladám, že žiaden DataModul neexistuje.

[Radek Červinka]

Tak som to aplikoval na connection
....
a funguje to.

No ja to daval na Query protoze v okamziku kdy pak ty se svojim resenim se pripojis do DB, tak se vsechny query, ktere maji Active na True podle mne automaticky otevrou, coz neni to co jsem chtel (ale mozna se pletu)

Ale to ihrisko sa mi veľmi páči. Občas ho používam, ale takto ma to nenapadlo  
Predpokladám, že napríklad pre Connection sa nastaví Owner
 - buď nil a musím sa postarať o jeho zničenie, alebo
 - napr. MainForm.

Nebo treba Self, coz v pripade ze to mas jako promennou Datamodulu, nebo nejakeho objektu tak zaruci, ze se to zrusi s uvolnenim datamodulu.

[Stanislav Hruška]

Nebo treba Self, coz v pripade ze to mas jako promennou Datamodulu, nebo nejakeho objektu tak zaruci, ze se to zrusi s uvolnenim datamodulu.

Ja predpokladám, že sa DataModul-ov treba zbaviť.

Začal som tak, že som vytvoril unit (CreateTable) a tam mám jednu funkciu ktorá vytvorí tabuľku if-else- if... Argument funkcie je názov komponentu. Takže asi najlepšie je nastaviť Owner na nil a sám sa postarať o zničenie.

[Daniel_Andrascik]

datamoduly pouzivam na jedinu vec a to na imagelisty spolocne pre celu aplikaciu. Pre firedac komponenty by som si vytvoril jednu databazovu triedu dakde v separatnej unite ktora by mi vykonavala vsetky poziadavky nad databazou a vo vnutry tej triedy by som mal nadeklarovane vsetky potrebne connectiony, datasety a pod... Ta trieda by sa starala jak o ich vytvorenie, tak o ich znicenie