/u/13464/Delphi.png?f=community)
"The shell stopped unexpectedly and Explorer.exe was restarted."
Verwijderd
Flikker het in een array mbv een query, en vul je Grid mbv de inhoud van die array.
Als je dan 1 regels van die array wijzigt, zoek je het bijbehorende record op en edit + update je die.
Goed?
Als je dan 1 regels van die array wijzigt, zoek je het bijbehorende record op en edit + update je die.
Goed?
Surrogaat oplossingen kunnen altijd nog.Op dinsdag 27 november 2001 22:41 schreef TriCAT het volgende:
Goed?
"The shell stopped unexpectedly and Explorer.exe was restarted."
Verwijderd
Ah, legacy conversie.
Vergeet wat ik zei over m'n aversie m.b.t. data aware components, en i.p.v. joins idd calculated fields gebruiken. Als die DOS applicatie niet zo bar veel business logic bevat, heb je de kern in een dag of 2 of zo omgezet...
En daarna begint de ellende: rapportage, mailmerge (ging nog met WP 5.1), etc...
Verwijderd
Dat kan met een UpdateSQL, maar ik zou 't niet zo doen. Daarvoor vind ik cached updates te link in een multi-user omgeving.
In dit geval (DOS app porten naar Win) zou ik echt proberen of ik die query zo zou kunnen omvormen dat 'ie niet meer read-only hoeft te zijn, de join eruit halen dus.
Dit is goed te doen met calculated fields en hun OnGetText events: de velden die je nu uit die 2e tabel haalt voeg je toe als calculated fields.
Simpel voorbeeldje: stel je hebt 2 tabellen, Bestellingen en Artikelen. In Bestellingen staan wel de artikelnummers, maar niet de omschrijvingen. Ideaal gevalletje voor een left join dus.
Wanneer je alleen maar de gegevens van Bestellingen in je query ophaalt, en het veld Omschrijving als calculated field toevoegt, zou 't OnGetText event er bv. zo uit kunnen zien:
Geen ideaal voorbeeld (kan nog wel 's te zwaar worden), maar het gaat even om 't idee, en hoe je zoiets kunt optimizen (Omschrijvingen van tevoren in een StringList zetten bv.) weet je zelf ook wel.
Voordeel is, dat je bij je query nu RequestLive op True kunt zetten, en dus rechtstreeks in de resultset kunt editten, inserten, enz.
En nogmaals: ik hou niet van data aware controls, dus ik zou 't zelf bij voorkeur niet op deze manier doen. Maar in single-user of kleine multi-user systemen kan 't prima werken. En 't ontwikkelt wel lekker snel...
In dit geval (DOS app porten naar Win) zou ik echt proberen of ik die query zo zou kunnen omvormen dat 'ie niet meer read-only hoeft te zijn, de join eruit halen dus.
Dit is goed te doen met calculated fields en hun OnGetText events: de velden die je nu uit die 2e tabel haalt voeg je toe als calculated fields.
Simpel voorbeeldje: stel je hebt 2 tabellen, Bestellingen en Artikelen. In Bestellingen staan wel de artikelnummers, maar niet de omschrijvingen. Ideaal gevalletje voor een left join dus.
Wanneer je alleen maar de gegevens van Bestellingen in je query ophaalt, en het veld Omschrijving als calculated field toevoegt, zou 't OnGetText event er bv. zo uit kunnen zien:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| procedure TForm1.Query1OmschrijvingGetText(Sender: TField; var Text: String;
DisplayText: Boolean);
begin
with TQuery.Create(nil) do try
DatabaseName := Sender.DataSet.DatabaseName;
SQL.Add('select Omschrijving from Artikelen where Artikel = :Artikel');
ParamByName('Artikel').AsString := Sender.DataSet.FieldByName('Artikel').AsString;
Open;
if not EOF then
Text := FieldByName('Omschrijving').AsString
else
Text := 'Artikel niet gevonden';
finally
Free;
end;
end; |
Geen ideaal voorbeeld (kan nog wel 's te zwaar worden), maar het gaat even om 't idee, en hoe je zoiets kunt optimizen (Omschrijvingen van tevoren in een StringList zetten bv.) weet je zelf ook wel.
Voordeel is, dat je bij je query nu RequestLive op True kunt zetten, en dus rechtstreeks in de resultset kunt editten, inserten, enz.
En nogmaals: ik hou niet van data aware controls, dus ik zou 't zelf bij voorkeur niet op deze manier doen. Maar in single-user of kleine multi-user systemen kan 't prima werken. En 't ontwikkelt wel lekker snel...
Pagina: 1