[Delphi] Gelaagd programmeren

[Tyf]

Ik moet de voor de eerste keer in mijn "lang" leven programmeren in delphi. Ik kom van de C#.NET en een beetje java wereld waar ik altijd mooi gelaagd programmeer. Dus met presentatie laag (forms), business logic (verwerking van data, ophalen van data, ...) en een database laag die zorgt voor de uitvoer van query's en teruggeven van data uit db.
Nu wil ik dus ook zo gaan programmeren in delphi, ben er zelfs al mee bezig maar het lukt nog niet echt goed.
Ik zit dus met een probleem die ik niet weet hoe juist aan te pakken. Ik heb dus al verschillende klassen geprogrammeerd die deze lagen moeten voorstellen. Gui, verwerkingsklassen, en db klasse.
Het wegschrijven van data is geen probleem.
Maar het ophalen van data is een ramp! Niet gelaagd werken lukt het zonder problemen om data op te halen en af te beelden. Maar ik wil gelaagd programmeren.
Het grote probleem is ik vind geen goede manier om data uit de databank door te geven naar mijn verwerkingslaag die deze dan tenslotte onder de goeie form aan de gui door geeft.
Ik heb al vanalles geprobeerd. Het probleem is dat ik gewoon ben van in C# connectieloos te werken met de databank. Daar vulde ik een dataset, sluit verbinding met db af en geef die dataset door.
Bij java loste ik dit op door een JtableModel te vullen met de data van de db en dan door te geven na het afsluiten van de connectie.
Kunnen er mensen mij eens uitleggen hoe zij dit aanpakken in delphi want er nu toch al mer dan weer mee bezig (inclusief delphi leren, syntax, ...) en het is een warboeltje aan het worden.
Hopelijk is mijn uitleg wat duidelijk, indien niet vraag maar gerust meer uitleg

[Rum]

Gebruik je voor de verschillende lagen verschillende units? Dan moet je namelijk wel aangeven dat bijvoorbeeld je GUI gebruik maakt van je business logic. Dit kun je doen door je unit toe te voegen bij de lijst van used-componenten.

[FendtVario]

Ik ervaar dezelfde problemen met Delphi, ik vind het in Java ook veel makkelijker om gelaagd te programmeren dan in Delphi. Het probleem is dat Delphi het te makkelijk maakt met zijn TDataset-descendants en data-aware componenten. In principe zijn de data-componenten van Delphi al gelaagd (bijv. dbExpress of third-party Zeos, kijk maar eens in de implementatie). Alleen spuugt Delphi geen entity-klassen maar gewoon records, in tegen stelling tot Java waar je een vanuit een DAO en klasse krijgt die een entity-object terug geven. Waar je in Java (meestal) een stap verder gaat met een DAO stopt Delphi al met de ResultSet.

Als je opzoekt bent naar een connectieloos dataset dat lijkt op JTabelModel probeer dan eens de TClientDataSet. Deze wordt gevuld van uit een andere dataset via de TDataSetProvider. Via de TDataSetProvider kun je de gegevens vervolgens ook weer syncen met de database. De data-componenten kun je het beste op een datamodule zetten.

[whoami]

Ik veronderstel dat je een probleem hebt met de TQuery component die je niet direct een resultaat kunt laten teruggeven zoals jij dat zou willen ?

Je kan de resultset van die TQuery gaan overlopen, en dan voor iedere rij in die resultset een (custom) object gaan vullen die je in een collectie propt. Die collectie kan je dan returnen.
Bv, stel je hebt een TQuery waarmee je de klanten ophaalt: maak een class 'Klant', en een class 'KlantCollection'. Overloop de results van de query, en maak dan voor iedere klant die de query gereturned heeft, een klant object en voeg dat toe aan de klantcollection. Dan kan je die collectie gaan returnen.

Je kan anders ook eens kijken naar de DataSet implementatie in Delphi; ik geloof dat Delphi ook een TClientDataSet oid heeft, maar daar heb ik zelf nooit mee gewerkt.

[Tyf]

aha ik lees hier een paar handige zaken.
Ik werk idd met units (kzou nie weten hoe anders )
TClientDataSet is dus connectieloos? kan ik opvullen doorsturen naar andere unit
zonder dat ik als ik hem gebruik rare errors krijg (want delphi en error amai wi)

@whoami
Het werken met objecten doe ik maar dan werk het nog niet.
Databankunit moet alles ophalen en doorsturen al je op de business unit.
Op uw manier zou je de business unit zich bezig moeten laten houden met databank connectie.
of de Databank unit bezig laten houden met verwerken van data.

die TClientDataSet werkt dat samen met ADO?

[FendtVario]

De TClientDataSet kun je vullen vanuit via de TDataSetProvider die zijn data vervolgens ophaalt uit componenten die de IProviderSupport interface implmenteren. Volgens hebben alle door Borland gemaakt TDataSet-descendants een implementatie van IProviderSupport. Voor third-party moet je dat zelf even controleren (bij Zeos is het bijv. nog beta). De TClientDataSet zal dus waarschijnlijk ook wel te gebruiken zijn icm met ADO.

[whoami]

Tyf schreef op dinsdag 22 februari 2005 @ 10:41:
@whoami
Het werken met objecten doe ik maar dan werk het nog niet.
Databankunit moet alles ophalen en doorsturen al je op de business unit.
Op uw manier zou je de business unit zich bezig moeten laten houden met databank connectie.
of de Databank unit bezig laten houden met verwerken van data.

Nee, de data access unit houdt zich bezig met het ophalen van de data, en adhv deze data creeërt deze een business object.

[Tyf]

Ok bedankt, ik ge mij weer verder verdiepen in de wondere wereld van delphi
Ik weet nu al na dit project (pff toch nog minstens 3 maand) zal ik nie te rap meer in delphi willen programmeren ...

[Anoniem: 113889]

Delphi beschikt over een speciaal type form TDataModule om data componenten centraal op te dumpen. Kan handig zijn als je niet al te veel centrale componenten hebt.

Er is geen standaard ondersteuning van ADO door dbExpress. Er zijn wel een paar producten op de markt. Aangezien ADO zelf al een cursorengine is is het de vraag ADO/dbExpress de handigste aanpak is. Alle "native" dbExpress-drives (Oracle, MySQL en nog een paar) zijn echt native drives. Snel, maar niet universeel.

Delphi vindt dat alle VCL-componenten, inclusief dbExpress, op de main thread aangestuurd/uitgevoerd worden. Dit maakt multi-thread database applicaties met hoge performance bouwen in Delphi bijzonder uitdagend .

De idee achter Delphi een programmeer-knutseldoos te hebben voor wanneer je model niet vast is. Delphi programmeren werkt ook zonder model . Dit heeft natuurlijk z'n voors en tegens.
Bijzonder fijn aan Delphi is dat het backward-compatible is. De eerste backward-compatible VisualStudio moet nog gebouwd worden .

[Tyf]

ja de TDataModule gebruik ik ook.
En tis idd een knutseldoos. Soort heel uitgebreide VB met een licht sausje OO.

En niemand zegt da je in visual studio moet programmeren voor .NET
Kladblok in het ergste geval volstaat. Zo blijf je ook backwards compatible.
Maar ik vind het niet erg dat hij nie backwards compatibel is hoor visual studio.
Ben geen MS fan maar als er iets goed is is het wel visualstudio, zeker de 2005.
Die zit zo lekker in mekaar. Denk dat ik een beetje teveel verwend ben

[FendtVario]

@bloog; het is ook helemaal niet nodig om ADO via dbExpress te gebruiken. ADO heeft gewoon zijn eigen componeten (connection, query, table). De TADOTable/Query kan ook via de dataset provider aan de TClientDataset gekoppeld worden.

[Tyf]

@FendtVario

En hoe doe je dit juist?
Is het mogelijk klein stukje code te geven waar je een TADOquery verbind met een TClientDataset?
Dus het is heel zeker mogelijk om via TADOquery data op te halen, in een TClientDataset te steken,
connectie sluiten, TClientDataset door te geven naar andere unit en daar dan de data eruit halen en afbeelden bv?

[FendtVario]

Meestal stel je de relaties design-time in dus ik doe het zo. Als je het in code wilt doen is het alleen toewijzen properties en dat moet denk ik nog wel lukken .

1) Zet een TADOConnection, TADOQuery (ADO-tab), TDataSetProvider en TClientDaset (Data Access) op je datamodule. Configureer je ADOConnection en query.
2) Zet vervolgens zet je de DatasetProvider.DataSet naar ADOQuery1
3) ClientDataSet1.ProviderName naar DataSetProvider1.

Als je nu de ClientDataSet1.Active op true zet wordt de data via de ADOQuery geladen (de ADOQuery hoef je zelf niet aan/uit te zetten). Ik weet niet of je de ClientDataSet echt wilt doorgeven naar een andere unit, je kan deze ook op de data module laten staan dan de data module unit in de uses opnemen van de andere unit.

[jvdmeer]

Ik heb ooit een topic geopend over een ander onderwerp, en daarin kwam op een gegeven moment de volgende constructie voor:

Just_a_Gamer schreef op maandag 15 september 2003 @ 22:49:

Delphi:

with TAdoStoredProc.Create( nil ) do
begin
  try
      Connection := ADOConnection1;
      ProcedureName := 'Test';
      Parameters.CreateParameter('Return_Value',ftInteger,pdReturnValue,10, NULL );
      Parameters.CreateParameter('Initiaal',ftString,pdInput,4,'A');
      Parameters.CreateParameter('Pincode',ftString,pdInput,4,'0000');
      ExecProc;
      ShowMessage( VarToStr( Parameters.ParamByName( 'Return_Value' ).Value ) );
  finally
    Free;   // dit hoeft niet is wel zo netjes :)
  end
end;

En deze constructie gebruik nog steeds regelmatig in combinatie met bijvoorbeeld TAdoQuery.

Delphi:

with TAdoQuery.Create( nil ) do
begin
  try
      Connection := ADOConnection1;
      SQL.Add('select * from tabel');
      Open;
      while not dataset.eof do
      begin
         // Werk met de dataset
         dataset.movenext;
      end;
  finally
    Free;   // dit hoeft niet is wel zo netjes :)
  end
end;

[/quote]

op deze manier heb je dus geen form ofzo nodig, en kan je dit in je db-layer gebruiken om je records in te lezen en over te zetten naar een collectie van objecten.

[Tyf]

@FendtVario
Ja het is de bedoeling de dataset MET de data erin door te geven. Die data moet in de dataset blijven zelfs nadat de connectie met de databank afgesloten is.
Idd ik stel liever @runtime mijn paramters in maar dit is hier geen probleem

@jvdmeer
merci voor de stukjes code zullen zeker nog van handig zijn
voorlopig probeer ik het via dataset op te lossen (heb nu oplossing gevonden maar vind het maar halve oplossing). Ik ga nog testen met wat FendtVario zei.
Als het dan nog altijd niet lukt misschien uw stukjes code gebruiken.

Het is verschrikkelijk om zulke deftige stukjes code te vinden over delphi.
Ik zoek op delphi en krijg zelf hele tijd .NET gedoe maar werkt met delphi 7 dus ben daar niet veel mee.

wel nog paar goeie sites gevonden misschien even mee geven. Wie weet zit er ene bij die jullie ook handig vinden:

http://delphi.about.com/
http://www.nldelphi.com/
http://www.tamaracka.com/

[FendtVario]

Ik weet niet of die de manier is die je bedoelt (en of dit uberhaubt de beste manier) is maar hier een stukje prutswerk. Ik heb even snel een DBE tabel gepakt omdat ik die nog 'op voorraad' had maar dat moet opzich niet uitmaken.

Het volgende stukje is een TDataModule implementatie:

Delphi:

unit Unit2;

interface

uses
  SysUtils, Classes, DBTables, DB, DBClient, Provider;

type
  TDataModule2 = class(TDataModule)
  private
    { Private declarations }
    function getDataSet(const SQLCommand: string): TDataSet;
  public
    { Public declarations }
    function getRelaties: TClientDataSet;
  end;

var
  DataModule2: TDataModule2;

implementation

{$R *.dfm}

{ TDataModule2 }

function TDataModule2.getDataSet(const SQLCommand: string): TDataSet;
begin
  //ik maak hier even snel een BDE dataset, maar je kan natuurlijk ook een ADOQuery of
  //iets maken. Als het maar een afgeleide is van TDataSet.
  Result := TQuery.Create(Self);
  with (Result as TQuery) do
  begin
    DatabaseName := 'c:\database\';
    SQL.Text := SQLCommand;
  end;
end;

function TDataModule2.getRelaties: TClientDataSet;
const
  SQL_RELATIES = 'select * from relatie';
var
  tmpDataSet: TDataSet;
  tmpProvider: TDataSetProvider;
begin
  tmpDataSet := getDataSet(SQL_RELATIES);

  //LET OP: de dataset provider _moet_ een naam hebben en ik dacht ook 
  //dezelfde owner als de TClientDataSet
  tmpProvider := TDataSetProvider.Create(Self);
  tmpProvider.Name := 'dspRelatie'; 
  tmpProvider.DataSet := tmpDataSet;

  Result := TClientDataSet.Create(self);
  with Result do
  begin
    ProviderName := tmpProvider.Name;
    Open;
  end;

  //hier wordt je verbinding met de database verbroken, de resultaten blijven wel in de ClientDataSet staan.
  FreeAndNil(tmpProvider);
  FreeAndNil(tmpDataSet);
end;

end.

en hier een functie die de clientdataset ophaalt en alle relatienamen in een TListBox zet

Delphi:

procedure TForm1.Button1Click(Sender: TObject);
begin
  //ophalen relaties
  with DataModule2.getRelaties do
  begin
    First;
    while not Eof do
    begin
      ListBox1.Items.Add(FieldByName('Naam').AsString);

      Next;
    end;

    Free; //geef de TClientDataSet vrij
  end;

end;

Wil je de TClientDataSet langer gebruiken dan moet je deze ergens bewaren in een variabele, maar dat lijkt me vanzelfsprekend. Je kan de TClientDataSet ook gebruiken voor data-aware componenten in je GUI.

[Anoniem: 14829]

Tyf schreef op dinsdag 22 februari 2005 @ 12:06:
En tis idd een knutseldoos. Soort heel uitgebreide VB met een licht sausje OO.

*slik* Wil je niet zulke rare dingen zeggen?
Delphi's VCL (visual component library) is volledig OO, net als Object Pascal, en een groot deel van de RTL (runtime library) ook. Al zitten daar nog wel een flink aantal non-OO zaken in i.v.m. backward compatibility met TurboPascal en Borland Pascal.
Al met al is het heel goed mogelijk (en wordt 't zelfs aangemoedigd) om puur OO te werken in Delphi. Ik zou niet meer anders willen!

En niemand zegt da je in visual studio moet programmeren voor .NET
Kladblok in het ergste geval volstaat. Zo blijf je ook backwards compatible.

Idem in Delphi, met z'n command line compiler en tools.

Ben geen MS fan maar als er iets goed is is het wel visualstudio, zeker de 2005.
Die zit zo lekker in mekaar. Denk dat ik een beetje teveel verwend ben

Datzelfde gevoel had ik ook toen ik van de Delphi IDE overstapte naar VS.NET... De Delphi IDE is/was m.i. veel doordachter en makkelijker uitbreidbaar met plugins dan die van VS. 't Is maar wat je gewend bent.

[Tyf]

@FendtVario
Merci voor dat stukje code !!!!!!
Morgen keer implementeren, het was zoiets dat ik zocht.

@afterlife
Het is mogelijk idd om OO te programmeren maar het is zeker niet zo makkelijk als in java of .NET.
Die units amai me voeten ze. Nu ken echt nie veel van delphi 90% van de frustratie komt dus ook van het feit dat ik het weet in .NET of java maar het moet in delphi dus dan moet ik zitten zoeken op iets dat ik met gemak in andere taal zou bereikt.

[LordLarry]

Ik zie niet waarom het in Delphi minder goed mogelijk is. Wel als je gebruik wilt blijven maken van DB componenten om ze designtime te koppelen aan de TDataSets. Als je dat los laat houdt echt niets je meer of minder tegen dan in Java.

Bovendien kan Delphi met Delphi 8 en Delphi 2005 ook perfect .Net programma's maken, dus als je denkt dat je het in .Net kan, kan het zeker in Delphi for .Net. Aangezien je dan precies dezelfde code, componenten en classes kan gebruiken als je al kon in C#, maar dan in het Pascal dialect.

[FendtVario]

Het is in Delphi zeker wel mogelijk, ongetwijfeld. Maar de data-aware componenten zijn dermate makkelijk dat je ze niet snel zult opgegeven. Het mooiste is een basis maken waarin je het gemak van Delphi kunt combineren met de kracht van OO. Ik zie het iig niet zitten om dmv eigen code steeds het form te vullen, te controleren en dan weer weg te schrijven. Ook als je er een standaard framework voor maakt, het zal behelpen blijven.

Dat vind ik ook een van de tekort komingen in Java, het gemis aan data-awareness. Het maken van de verschillende lagen werkt prachtig, geeft overzicht en is simpel uit te breiden. Echter, het maken van een database applicatie in Java valt altijd weer tegen. Misschien ook wel omdat ik nog niet zo gedreven ben met Java maar dat terzijde. Mocht iemand daar leesvoer over dan hoor ik dat graag.

[MisterData]

FendtVario schreef op dinsdag 22 februari 2005 @ 21:46:
Het is in Delphi zeker wel mogelijk, ongetwijfeld. Maar de data-aware componenten zijn dermate makkelijk dat je ze niet snel zult opgegeven. Het mooiste is een basis maken waarin je het gemak van Delphi kunt combineren met de kracht van OO. Ik zie het iig niet zitten om dmv eigen code steeds het form te vullen, te controleren en dan weer weg te schrijven. Ook als je er een standaard framework voor maakt, het zal behelpen blijven.

Dat vind ik ook een van de tekort komingen in Java, het gemis aan data-awareness. Het maken van de verschillende lagen werkt prachtig, geeft overzicht en is simpel uit te breiden. Echter, het maken van een database applicatie in Java valt altijd weer tegen. Misschien ook wel omdat ik nog niet zo gedreven ben met Java maar dat terzijde. Mocht iemand daar leesvoer over dan hoor ik dat graag.

offtopic:
Heb je al eens kennisgemaakt met Hibernate? Als je dat eenmaal gewend bent dan schrijf je de eerstkomende tijd geen SQL meer in Java...

[Anoniem: 14829]

Tyf schreef op dinsdag 22 februari 2005 @ 21:15:
Het is mogelijk idd om OO te programmeren maar het is zeker niet zo makkelijk als in java of .NET.
Die units amai me voeten ze.

Voor die laatste zin heb ik ondertiteling nodig...

Voor mij is 't veel gemakkelijker om in Delphi OO te programmeren dan in bv. C#, omdat ik Delphi al een jaar of 8 gebruik en 't op m'n duimpje ken. Bij C# verval ik al gauw tot het bij elkaar klikken van de componenten die ik nodig heb, databindings instellen, etc. Oftewel, dezelfde dingen die jij als nadeel van Delphi aangeeft.

En ja, die frustratie bij een taal die je nog niet kent heb ik ook. Hoort een beetje bij het vak, denk ik.

[FendtVario]

offtopic:
Wel eens snel overheen gekeken maar nog niet gebruikt. Ik dacht dat Hibernate alleen een O/R mapper was en niet het 'probleem' van data-awareness oplost. Het staat iig nog wel op de planning om Hibernate actief te gaan ontdekken.

[Anoniem: 14829]

FendtVario schreef op dinsdag 22 februari 2005 @ 21:46:
Het is in Delphi zeker wel mogelijk, ongetwijfeld. Maar de data-aware componenten zijn dermate makkelijk dat je ze niet snel zult opgegeven.

Tja, da's een kwestie van hoe je de tools wilt gebruiken. In 8 jaar (begonnen met Delphi 2) heb ik in m'n applicaties nog maar 1 data-aware control gebruikt: DBGrid. En dan ook nog read only.
Ik hou er niet van dat edit controls gegevens in de dataset kunnen aanpassen, en dat je die bv. met een DBNavigator kunt opslaan. Dat houd ik liever zelf in de hand.

TClientDataSet komt een heel eind in de richting: de wijzigingen worden locaal uitgevoerd en moet je via de DataSetProvider expliciet naar de database sturen, maar dan nog... Data-aware, dat regel ik zelf wel.

[FendtVario]

En blijkbaar een kwestie van gewenning. Ik ken Delphi sinds v1 en heb eigenlijk altijd de data-aware componenten gebruikt. Ik gebruik Delphi nu bijna 3 jaar professioneel en ben tijdens mijn werk en stages nog niet veel anders tegen gekomen.

Zou je eens een klein voorbeeldje kunnen geven van de structuur van je applicatie en de manier waarop je omgaat met het visualiseren, aanpassen en opslaan van de data? Misschien heeft de TS daar ook nog wat.

[Anoniem: 25556]

Waarom wil je persé een dataset component doorgeven aan je 2e laag?

Definieer classes voor je gegevens, laat je DB-laag objecten instantieren en deze doorgeven aan je business laag.

Dus, heel kort door de bocht:

Delphi:

ThzNaw = class(TObject)
  private
  public
     property voornaam: string;
     property achternaam: string;
  end;

[..]

function mijndatalaag.haalnaw: TObjectlist;
var
  naw: ThzNaw
begin
  result:=TObjectlist.create(true);
  with query do
    begin
      sql.clear;
      sql.add('select * from tbl_naw');
      repeat
         Naw := ThzNaw.create;
         Naw.voornaam := FieldByName('achternaam').AsString;
         Naw.achternaam := FieldByName('voornaam').AsString;
         Result.Add(Naw);
      until EOF
    end;
end;

[Tyf]

@hezik
Dat was ik ook eerst van plan maar dit kost mij echt teveel werk. Doorgeven van dataset werkt veel makkelijker omdat je dan makkelijk gebruik kan maken van je datagrid en andere dataobjecten.
Ik vind dat de oplossing met het doorgeven van dataset de gulden tussenweg is voor mij, tussen mooi OO en gelaagd programmeren en iets zo rap mogelijk klaar krijgen

[Anoniem: 25556]

Tyf schreef op woensdag 23 februari 2005 @ 09:08:
@hezik
Dat was ik ook eerst van plan maar dit kost mij echt teveel werk. Doorgeven van dataset werkt veel makkelijker omdat je dan makkelijk gebruik kan maken van je datagrid en andere dataobjecten.
Ik vind dat de oplossing met het doorgeven van dataset de gulden tussenweg is voor mij, tussen mooi OO en gelaagd programmeren en iets zo rap mogelijk klaar krijgen

Teveel werk? Ik heb in het verleden een class gemaakt die een query omzet in een object met als properties de velden uit die query (en ook van het juiste type enz). Is eenmalig veel werk, maar daarna ben je van al het gezeik af. Je moet niet bang zijn om met RTTI aan de gang te gaan dan, overigens.

Maar goed.. je hebt al een werkende oplossing gevonden, zie ik

* Anoniem: 25556 is nog altijd huiverig t.a.v. clientdatasets, omdat de implementatie ervan tot aan delphi 4 op z'n zachts gezegd 'buggy' was.

[whoami]

Tyf schreef op woensdag 23 februari 2005 @ 09:08:
@hezik
Dat was ik ook eerst van plan maar dit kost mij echt teveel werk. Doorgeven van dataset werkt veel makkelijker omdat je dan makkelijk gebruik kan maken van je datagrid en andere dataobjecten.
Ik vind dat de oplossing met het doorgeven van dataset de gulden tussenweg is voor mij, tussen mooi OO en gelaagd programmeren en iets zo rap mogelijk klaar krijgen

Datasets zijn eigenlijk iets waar ik liever niet mee werk; zeker niet als je ze wilt zien als 'Business Objects'.
Het is gewoon een representatie die te dicht bij het DB model ligt.

[Tyf]

Hmm wel ik heb nu geprobeerd met de clientdataset.
Werkt perfect, juist zoals ik wil. Maar bij grote hoeveelheden data loop mijn programma gewoon vast.
Op vorige manier ging dit wel goed. Is er een beperking op hoeveel data zo'n dataclient kan bevatten?

[FendtVario]

Volgens mij is je interne geheugen de limit. De grootste tabel die ik nu voor handen heb is 14000 records en die laat ie zonder al te veel moeite. Wat vind jij grote hoeveelheden?

[Creepy]

Een clientdataset laad alles in memory en houdt vervolgens alle wijzigingen op die dataset in memory bij. Pas als je aangeeft alle updates e.d. door te laten werken worden de gegevens in de DB daadwerkelijk geupdate en de gewijzigde gegevens in memory geladen.

[Tyf]

De tabel die ik moet ophalen is 46000 records groot. En ik vraag hiervan 3 velden.
Internt geheugen is 128 mb. Hij loopt vast bij .OPEN als ik grote hoeveelheid data opvraag.
Maar intern geheugen? als er te weinig intern geheugen is neemt windows toch zijn virtueel geheugen.
Deze staat hier op auto dus in geval van te weinig geheugen zou ik zelf de melding moeten krijgen dat mijn virtueel geheugen wordt vergroot.

Vind het maar raar probleem. Spijtig want ik was zo blij met de clientdataset oplossing.

[Anoniem: 14829]

FendtVario schreef op woensdag 23 februari 2005 @ 00:56:
Zou je eens een klein voorbeeldje kunnen geven van de structuur van je applicatie en de manier waarop je omgaat met het visualiseren, aanpassen en opslaan van de data? Misschien heeft de TS daar ook nog wat.

Mijn aanpak lijkt in beginsel wel op het voorbeeld wat Hezik gaf, maar dan ietsje ingewikkelder...

Ik gebruik 3 base classes: TObjectField, TObjectFieldList en TObjectFieldListList. Zeg maar representaties van een field, record en dataset.
Al hoeft het niet perse om een TDataSet-afgeleide te gaan: via de DataHelper interface van TObjectFieldListList kunnen dit ook dingen zijn als XML-streams, csv-bestanden, gestructureerde logfiles, Excel sheets, etc.. Zolang die interface maar de Select, Insert, Update, UpdateModified (alleen de gewijzigde velden) en Delete methods implementeert.

De TObjectField class representeert niet alleen de waarde van het bijbehorende veld, maar je kunt er ook een willekeurig TWinControl descendant control aan hangen. Dan moet je er natuurlijk wel voor zorgen dat in de class een correcte implementatie van GetValue en SetValue methods wordt geimplementeerd. (een gauge benader je anders dan een edit control, om maar wat te noemen).

De base classes worden natuurlijk nooit rechtstreeks gebruikt, maar altijd via afgeleiden, waar je dan ook de koppeling met je business logic kunt opnemen.

't Klinkt misschien ingewikkeld, maar zoals Hezik al zei: je ontwikkelt eenmaal een framework, en daarna is het erg snel te hergebruiken in situaties waar een soortgelijk stramien geldt. Zeker als je er components van maakt (of omheen maakt) die design time bv. een tabel om kunnen zetten naar een TObjectFieldListList (niet zo handige naam, maar dat is nu eenmaal zo gegroeid ) descendant of de controls op een form kunnen koppelen aan de TObjectFields in een TObjectFieldList.

[whoami]

Ik vraag me gewoon ff af waarom je in godsnaam al die 46.000 records in het geheugen wilt laden ?
Ga je ze allemaal aanpassen ?

[Anoniem: 14829]

Tyf schreef op woensdag 23 februari 2005 @ 10:57:
De tabel die ik moet ophalen is 46000 records groot. En ik vraag hiervan 3 velden.
Internt geheugen is 128 mb. Hij loopt vast bij .OPEN als ik grote hoeveelheid data opvraag.

Waaraan is de DataSetProvider van je ClientDataSet gekoppeld? Als dat een table is, of een 'select * from table' query, dan worden alle velden van die table opgehaald, ook al gebruik je maar 3 velden in je ClientDataSet (plus evt. primary key velden, om persistency te kunnen waarborgen).

[Tyf]

@whoami
Ja als ze mij zeggen dat ze een volledige lijst willen kunnen zien, dan moeten ze dat kunnen zien
De bedoeling is dat ze dan op een record klikken en deze dan op ander form kunnen aanpassen.
Ik zal navraag doen of er minder getoond kan worden. Maar dan nog vind ik een applicatie die vast loopt bij te weinig geheugen niet echt goed. Dat hij heel traag wordt is aanvaardbaar maar gewoon stoppen met werken kan niet. De pc's hier zijn geen super bakken dusja het moet met minimale specs toch werken.

@afterlife
Hij is gekoppeld aan een "select ... from ..."

[ Voor 39% gewijzigd door Tyf op 23-02-2005 11:18 ]

[FendtVario]

Loopt je programma ook vast als je de dataset opent die aan je DataSetProvider gekoppeld is opent (dus alleen de ADOQuery(?) en niet de ClientDataSet)? Welke dbms gebruik je, hoe snel is dat met 46000 records.

[whoami]

Tyf schreef op woensdag 23 februari 2005 @ 11:17:
@whoami
Ja als ze mij zeggen dat ze een volledige lijst willen kunnen zien, dan moeten ze dat kunnen zien
De bedoeling is dat ze dan op een record klikken en deze dan op ander form kunnen aanpassen.

Ja, maar daarvoor moet je toch niet voor alle xxxx items, het volledige record al in het geheugen hebben?
Als je nu eens een lijst ophaalt met de velden die ze willen zien voor ieder record, en de PK van dat record.
Als ze dan op een record klikken, kan je een ander form openen waar je adhv de PK het volledige record ophaalt, en waar de gebruiker het dus kan wijzigen.

[Tyf]

Ik werk nu met de ADOquery en verbind die direct met de datagrid (voorlopig)
En daarin werkt hij perfect.
Als dbms gebruik ik MS sql server, en die 46000 records worden via de ADOquery in een paar seconden opgehaald en weergegeven in de DBgrid.

Maar hiervoor werk ik dus met connectie, query, en weergeven op zelfde form. Waar ik dus vanaf wil stappen.

@whoami
maar dat doe ik toch ook niet?
Ik selecteer de velden die ik nodig heb, 3 velden (PK).
De rest haal ik dan op eenmaal gekozen is (dit werkt al goed, is ook maar 1 record en dus niet veel data)

[ Voor 24% gewijzigd door Tyf op 23-02-2005 11:39 ]

[LordLarry]

Je kan dus de query, connectie en dataset op een TDataModule zetten die alle forms kunnen gebruiken. Je kan zelfs vrij simpel met Midas/DataSnap een fysiek gescheiden multitier maken. Je kan niet EN wel van de TDB componenten gebruik maken EN niet willen dat het via TDataSets gaat.

[Anoniem: 14829]

Net even geprobeerd op m'n laptopje (P3 600MHz, 192MB geheugen).
ADOConnection -> ADOTable -> DataSetProvider -> ClientDataSet -> DataSource -> DBGrid.

't Duurde "even" (meerdere minuten, incl. melding dat m'n virtual memory low was) voordat de 738.000 records in de ClientDataSet stonden, maar 't werkte wel gewoon. Niet echt handig, maar hij liep niet vast of zo.

(Tabel had 12 velden, met als langste een varchar(50))

[update]
Nogmaals geprobeerd, en de laptop is nu al bijna een half uur bezig, zonder noemenswaardige HD- of netwerk-activiteit. Ik kan zien dat 'ie nog bezig is, maar voor normaal gebruik betekent dit gewoon dat 'ie hangt.
Maar ja, moet ik ook maar niet 700.000+ records op willen vragen...

[ Voor 31% gewijzigd door Anoniem: 14829 op 23-02-2005 12:45 ]

[Anoniem: 25556]

Tyf schreef op woensdag 23 februari 2005 @ 11:17:
@whoami
Ja als ze mij zeggen dat ze een volledige lijst willen kunnen zien, dan moeten ze dat kunnen zien

Ik neem aan dat je het dan over een uitzonderingssituatie hebt.. men kan nooit 46.000 records bekijken, dat zou hooguit nuttig kunnen zijn voor het printen van een lijst. Anders zou ik met limits werken in je queries, en met 'volgende' en 'vorige' knoppen, waarmee de dataset opnieuw opgehaald wordt met een nieuwe limit.

Ik zal navraag doen of er minder getoond kan worden. Maar dan nog vind ik een applicatie die vast loopt bij te weinig geheugen niet echt goed. Dat hij heel traag wordt is aanvaardbaar maar gewoon stoppen met werken kan niet. De pc's hier zijn geen super bakken dusja het moet met minimale specs toch werken.

Tsja.. 2 regels:

1) avoid fetchalls as the plague
2) TClientdataset might be buggy..

Wat ik overigens nog steeds niet helemaal zie.. best leuk dat je gelaagd wil werken, maar waarom moet het binnen dat systeem mogelijk zijn dat er geen verbinding met de database is?

Als ik een datamodule bouw met daarop de queries etc, en geef gewoon de datasets van die queries door aan m'n business-laag, dan heeft dat toch hetzelfde effect? Wat is precies het voordeel van een TClientDataset er tussen te zetten? Die is eigenlijk specifiek bedoeld voor applicaties waarbij geen permanente verbinding met een database aanwezig is, bv. als een monteur op pad gaat met een laptop, zodat hij ter plekke wel alvast zijn handelingen in kan voeren.

Wat is er op tegen om de clientdataset te laten vallen, en gewoon de dataset van een actieve query door te geven?

Los daarvan; ik heb nooit zo goed dat gebruik van data-aware componenten begrepen.. dat handel je toch veel liever zelf af?

[ Voor 39% gewijzigd door Anoniem: 25556 op 23-02-2005 13:34 ]

[FendtVario]

Ik heb eigenlijk weinig problemen met de TClientDataSet hoor. Het enige waar je goed op moet letten is dat je, als je het programma uitgeeft, de juiste midas.dll meeleverd. Ik had eens tot in den treure zitten testen, alles werkte. Kom ik bij een klant, alles overhoop, alle indexen kapot . Terug op de zaak nog eens getest deed alles het weer. Wat bleek, oude versie midas.dll. Dat vind ik het enige nadeel aan de TClientDataSet, daarnaast heeft ie ook heel handige features als AggregateFields.

[Anoniem: 25556]

FendtVario schreef op woensdag 23 februari 2005 @ 13:40:
Ik heb eigenlijk weinig problemen met de TClientDataSet hoor. Het enige waar je goed op moet letten is dat je, als je het programma uitgeeft, de juiste midas.dll meeleverd. Ik had eens tot in den treure zitten testen, alles werkte. Kom ik bij een klant, alles overhoop, alle indexen kapot . Terug op de zaak nog eens getest deed alles het weer. Wat bleek, oude versie midas.dll. Dat vind ik het enige nadeel aan de TClientDataSet, daarnaast heeft ie ook heel handige features als AggregateFields.

Ik zou liever een paar uur extra besteden aan het maken van een eigen set objecten, dan iets aan een klant leveren waarbij de foute versie van één, niet tot het project behorende, dll, kan leiden tot vernaggelde indexxen..

Wat als zo'n klant morgen een applicatie installeert die ook midas.dll gebruikt, maar een andere versie?

[ Voor 6% gewijzigd door Anoniem: 25556 op 23-02-2005 13:45 ]

[Anoniem: 14829]

Anoniem: 25556 schreef op woensdag 23 februari 2005 @ 13:31:
Ik neem aan dat je het dan over een uitzonderingssituatie hebt.. men kan nooit 46.000 records bekijken, dat zou hooguit nuttig kunnen zijn voor het printen van een lijst. Anders zou ik met limits werken in je queries, en met 'volgende' en 'vorige' knoppen, waarmee de dataset opnieuw opgehaald wordt met een nieuwe limit.

Bij MSSQL is dat wat lastiger: die heeft geen LIMIT commando, maar alleen TOP.
Dus wanneer je bv. pagina 30 op wilt vragen (met zeg 20 records per pagina), zul je ook eerst nog de 29 pagina's daarvoor door moeten fietsen.
Of je zult bij je 'vorige'/'volgende' knoppen resp. de PK van het 1e record van de huidige pagina of die van het laatste record mee moeten geven, zodat je 't in je WHERE clause mee kunt nemen.
Te doen, maar 't is wat lastiger...

1) avoid fetchalls as the plague
2) TClientdataset might be buggy..

1) FetchAlls zijn akelig handig bij kleine datasets (picklists, etc.), maar bij meer dan bv. 100 records wil je ze inderdaad niet.

2) Bij Delphi 4 was de TClientDataSet nog heel strak gebonden aan MIDAS, en dat was idd nogal buggy. Net als wel meer onderdelen van D4: uitspraak van een Borland medewerker: "The only advantage of QuickReports was, that it was more buggy than Delphi 4 itself"...
Maar vanaf Delphi 5 is de ClientDataSet een stuk stabieler geworden.

Probleem bij Delphi 4 was, dat het management van Inprise/Borland had besloten dat er elke 3 maanden een release of een update uit moest komen. Resultaat: Delphi 4 is toen uitgebracht terwijl het nog lang niet af was, met alle fouten en problemen van dien.
Daar heeft Borland van geleerd, en nu is 't "when it's ready". (m.i. de enige juiste houding, maar daar zijn m'n klanten 't niet altijd mee eens... )

Los daarvan; ik heb nooit zo goed dat gebruik van data-aware componenten begrepen.. dat handel je toch veel liever zelf af?

Mee eens, maar dat was geloof ik al duidelijk.

[Anoniem: 14829]

Anoniem: 25556 schreef op woensdag 23 februari 2005 @ 13:44:
Wat als zo'n klant morgen een applicatie installeert die ook midas.dll gebruikt, maar een andere versie?

Zolang je die midas.dll in dezelfde directory zet als je exe, en dus niet in System32 of zo, is er niks aan het handje.

[FendtVario]

Anoniem: 14829 schreef op woensdag 23 februari 2005 @ 14:14:
Probleem bij Delphi 4 was, dat het management van Inprise/Borland had besloten dat er elke 3 maanden een release of een update uit moest komen. Resultaat: Delphi 4 is toen uitgebracht terwijl het nog lang niet af was, met alle fouten en problemen van dien.
Daar heeft Borland van geleerd, en nu is 't "when it's ready". (m.i. de enige juiste houding, maar daar zijn m'n klanten 't niet altijd mee eens... )

Bij delphi is de regel niet de even versienummers te gebruiken. 2 was een alleen maar een 32-bit gecompileerde versie van 1 zonder echte toevoegingen. D4 was inderdaad verre van stabiel en ook D6 was brak. D7 was eindelijk weer een goed product.

[FendtVario]

Anoniem: 14829 schreef op woensdag 23 februari 2005 @ 14:18:
[...]
Zolang je die midas.dll in dezelfde directory zet als je exe, en dus niet in System32 of zo, is er niks aan het handje.

Kan wel maar werkt niet, na de installatie van midas.dll moet je deze eerst registreren in windows anders werkt ie nog niet naar behoren

[Johnny Goodbye]

dat gedonder met midas.dll kan je voorkomen door midaslib aan je gebruikte units toetevoegen. Dan gebruik je overal dezelfde versie.

[Tyf]

Ik wou via een clientdataset werken omdat ik het netjes vond om de data op te halen
bij te houden in een object en dan de connectie weer te sluiten.
Maar ik denk dat ik dit idee zal laten varen. De clientdataset krijg ik niet in orde. Kleine hoeveelheid data is geen probleem grote hoeveelheid wel. En ik moet echt al die data tonen.
Deze data zijn bouwgegevens van vloeren. En de gebruikers moeten een bestaande vloer kunne aanduien en op basis daarvan een nieuwe vloer bv ingeven. Of gewoon de vloer aanpassen en bewaren.
Niemand weet dus of ze opeens een vloer van 10 jaar geleden nodig gaan hebben (onwaarschijnlijk maar je weet maar nooit) of niet. Dus ik kan er geen uit filteren.
Enigste dat ik zou kunne doen is dus deeltje per deeltje ophalen. Maar dit lijkt me weer moeilijk doen.

[jvdmeer]

FendtVario schreef op woensdag 23 februari 2005 @ 14:19:
Bij delphi is de regel niet de even versienummers te gebruiken. 2 was een alleen maar een 32-bit gecompileerde versie van 1 zonder echte toevoegingen. D4 was inderdaad verre van stabiel en ook D6 was brak. D7 was eindelijk weer een goed product.

offtopic:
Dat regeltje over even nummers kom je vaker tegen:
Windows NT4 servicepacks: 2,4, en 6 -> absoluut niet gebruiken, beter zijn 3, 5 en 6a.

[Anoniem: 14829]

FendtVario schreef op woensdag 23 februari 2005 @ 14:19:
Bij delphi is de regel niet de even versienummers te gebruiken. 2 was een alleen maar een 32-bit gecompileerde versie van 1 zonder echte toevoegingen. D4 was inderdaad verre van stabiel en ook D6 was brak. D7 was eindelijk weer een goed product.

Mijn stelregel is altijd geweest: pas een Delphi versie in productie gebruiken na 2 update packs, en tot nu toe pakte dat prima uit.
Nu nog even kijken of dat met Delphi 2005 ook geldt, want daar heb ik vandaag de Enterprise versie van besteld...

[Anoniem: 127584]

Bij een client dataset kun je een hoop tunen.
Zo kun je aangeven dat die slechts een beperkt aantal records automatisch inlaad en de rest pas opvraagt wanneer ze nodig zijn. Ook kun je bv als je meerdere views op dezelfde data wilt definieren een extra client dataset aanmaken die naar dezelfde data verwijst (Tclientdataset.clone)
Ooit heb ik aan een applicatie gewerkt waarbij de verschillende lagen via TClientdatasets communiceerden. (of eigenlijk pointers naar de clientdatasets )
Nadeel was dat bij het opstarten de complete(!) Oracle database werd leeggetrokken en gebufferd werd. Dit gaf een performancehit die in die tijd (10mbit netwerk, 64mb intern geheugen maar wel een zware sun server met een complete set geconverteerde productie data van enige jaren) duidelijk te merken was. Uiteindelijk hebben we ervoor gezorgd dat het inladen gebeurde terwijl een gedeelte van de interface al beschikbaar was. Daarnaast laden we alleen maar data in die de gebruiker daadwerkelijk mocht gebruiken.
Door na het inlezen de mastertables te clonen en verschillende datasets aan elkaar te koppelen konden we vanuit de database laag elk soort relatie doorgeven naar de andere lagen.

Een ander nadeel van Clientdatasets is dat in een multiuser omgeving de ene gebruiker andere informatie kan hebben als een andere. Informatie over bijvoorbeeld adreswijzigingen worden niet realtime naar alle clients verspreid. Je zult dus dubbele wijzigingen in hetzelfde record moeten kunnen resolven. In ons geval allemaal geen echt probleem. Maar in andere bedrijfstaken is dat wel een belangrijk probleem.

Mijn ervaring is dat het heel goed kan werken. Je haalt nooit de performance van linked lists met pointers, maar het gebruik van data aware controls is wel erg handig. Wel zijn het geen objecten die je eventjes in een dagje volledig doorgrond. Om er goed mee om te gaan moet je redelijk goed weten hoe ze werken.