[C Builder]TDatasource verliest Dataset

[CRiMiNaL]

Mijn probleem is als volgt, ik heb in mijn eigen programma gemaakt die data uit een SQL database haalt. Het gebeurt in de volgende volgorde :

TADOConnection --> TADOTable --> TDataSource

Nou werkte ik eerst gewoon met panels in mijn programma, tot op het moment dat ik meer dan 4 keer een formuliertje wilde hebben met data.
Toen ben ik opzoek gegaan naar een alternatief, mij leek het beste om iedere pagina een eigen frame te geven. Nu was ik dus bezig om alles te verplaatsen naar een frame. De Connectie en de ADOTable werkte allemaal in de applicatie, in me DBGrid kreeg ik in C Builder ook gewoon de inhoud van de SQL Tabel te zien.
Echter als ik de applicatie run krijg ik nergens op m'n frame meer data te zien.
wat blijkt nu, m'n DataSource verliest elke keer z'n DataSet (ADO Table).
Ik dacht dit op te lossen door dit in de code te verwerken, maar ook dit mag niet baten Kan iemand mijn vertellen waar mijn probleem nog meer kan liggen?

[ Voor 4% gewijzigd door CRiMiNaL op 26-11-2003 10:45 ]

[Verwijderd]

waarom gebruik je een ADOTable? en niet een TTable met een TQuery?

[CRiMiNaL]

Ik gebruik een ADO table omdat de connectie moet via ODBC, dit is een van de systeem vereisten dus ik kan dit ook niet veranderen. Bovendien is dat niet echt van belang op m'n vraag

[Verwijderd]

Verwijderd schreef op 26 november 2003 @ 11:10:
waarom gebruik je een ADOTable? en niet een TTable met een TQuery?

Borland ondersteund/ontwikkeld zelf de BDE al niet eens meer, dus waarom vraag je mensen om gebruik te maken van de BDE door TTable/TQuery componenten? Dit heeft trouwens weinig te doen met de originele vraag.

Ok, dan nu een manier hoe je je data en formulieren mooi kan scheiden.
Borland heeft vanaf Delphi 2 en dus ook van C++Builder (3 was het dacht ik) TDataModules geintroduceerd.
Het mooie van datamodules is dat je je DB-logica kan scheiden van je GUI. Als twee TForm's gebruik willen maken van dezelfde data dan hoeft het ene TForm niet gebruik te maken van het andere TForm zodat resources beter verdeeld blijven.
Zelf zou ik het volgende doen; is misschien wel iets te uitgebreid, maar het werkt wel beter naarmate je project groeit.
1) Je creeert een TDataModule. Hier in plaats je alleen je TADOConnection.
2) Je creeert nog een TDataModule. Hier in plaats je je TADOQuery's. Hoewel je ook TADOTables gebruikt is het een goede gewoonte om toch TADOQuery's te gebruiken. Je 'include' je ADOConnection-datamodule middels de toetscombinatie Alt-F11. Je zet nu op je ADOQueries/ADOTables de Connection op je ADOConnection-component.
3) Je creeert je formulieren en zet daar je DBAware componenten op (DBGrid etc). Hier zet je ook je datasources op. Met Alt-F11 include je vervolgens je ADOQueries/ADOTables datamodule. Je kunt nu op de normale wijze je datasources aanwijzen.
4) In je Project Options moet je zorgen dat je DataModules in de goede volgorde worden gecreeerd (eerst datamodule met ADOCconnection, daarna datamodule met queries). Pas daarna mag het TForm/TFrame worden gecreeerd.

[LordLarry]

Verwijderd schreef op 26 november 2003 @ 12:25:
Borland ondersteund/ontwikkeld zelf de BDE al niet eens meer, dus waarom vraag je mensen om gebruik te maken van de BDE door TTable/TQuery componenten? Dit heeft trouwens weinig te doen met de originele vraag.

Wij blijken Borland allemaal verkeerd begrepen te hebben. BDE wordt nog (voorlpig) wel ondersteund, alleen de SQL Links niet meer. In Delphi 8 for .Net zijn dan ook weer gewoon de TTable en TQuery componenten te vinden.

En ODBC koppelingen kunnen ook via de BDE gemaakt worden, maar ik ben het met je eens dat het niets met de vraag van de TS temaken heeft of ie wel of niet de BDE gebruikt.

[Verwijderd]

LordLarry schreef op 26 november 2003 @ 12:54:
Wij blijken Borland allemaal verkeerd begrepen te hebben.

Dat is ook niet zo gek omdat Borland niet altijd duidelijk is geweest over de toekomst van de BDE.

BDE wordt nog (voorlpig) wel ondersteund, alleen de SQL Links niet meer.

Ook de BDE wordt niet meer verder ontwikkeld (zo ver ik het weet).

In Delphi 8 for .Net zijn dan ook weer gewoon de TTable en TQuery componenten te vinden.

Zou ik heel onlogisch vinden van Borland want wat zou het voordeel nog kunnen zijn ten opzichte van ADO.Net. Misschien backwards compatibliteit, maar daar houd het wel zo'n beetje mee op. Daarbij, CBuilderX en C#Builder hebben helemaal geen BDE meer.

En ODBC koppelingen kunnen ook via de BDE gemaakt worden

Dat is nou werkelijk de meest lugubure oplossing die ooit bedacht is imho. Je gaat dus via een dubbele data engine (eerst BDE, daarna via ODBC) connectie maken met de database. Lijkt me dat dit de snelheid/stabiliteit niet ten goede zal komen.

maar ik ben het met je eens dat het niets met de vraag van de TS temaken heeft of ie wel of niet de BDE gebruikt.

Inderdaad, TTable/TQuery of TADOQuery of TADOTable erven toch allemaal van TDataSet af.

[LordLarry]

Verwijderd schreef op 26 november 2003 @ 14:24:

Ook de BDE wordt niet meer verder ontwikkeld (zo ver ik het weet).

Klopt, maar nog wel ondersteund dus.

Zou ik heel onlogisch vinden van Borland want wat zou het voordeel nog kunnen zijn ten opzichte van ADO.Net. Misschien backwards compatibliteit, maar daar houd het wel zo'n beetje mee op. Daarbij, CBuilderX en C#Builder hebben helemaal geen BDE meer.

Het is iig gedaan om een makkelijke overgang te maken ja. Beide andere pakketten die jij noemt hebben ook geen VCL en daar is dit onderdeel van.

Dat is nou werkelijk de meest lugubure oplossing die ooit bedacht is imho. Je gaat dus via een dubbele data engine (eerst BDE, daarna via ODBC) connectie maken met de database. Lijkt me dat dit de snelheid/stabiliteit niet ten goede zal komen.

Ook ADO doet het op dezelfde manier. Eerst ADO dan ODBC. In feite zijn de BDE en ADO ontwikkeld voor hetzelfde doel.

[CRiMiNaL]

bedankt voor je uitleg hvdberg, ik denk dat ik het dan inderdaad maar met die Tdatamodules ga proberen.

[Verwijderd]

LordLarry schreef op 26 november 2003 @ 15:00:
Klopt, maar nog wel ondersteund dus.

Het is natuurlijk discutabel wat ondersteuning dan nog inhoudt.

Het is iig gedaan om een makkelijke overgang te maken ja. Beide andere pakketten die jij noemt hebben ook geen VCL en daar is dit onderdeel van.

Klopt toch niet helemaal. VCL en BDE staan los van elkaar. De originele data access components vanaf Delphi 1 maken echter wel gebruik van de BDE (denk hierbij aan de TDatabase/TTable/TQuery). De BDE is echter al ouder en via een API (met name bedoeld voor C++) bruikbaar, net als ODBC.

Ook ADO doet het op dezelfde manier. Eerst ADO dan ODBC. In feite zijn de BDE en ADO ontwikkeld voor hetzelfde doel.

Het doel mag dan gelijk zijn, toch is de technische implementatie heel anders. In ieder geval bedoelde ik meer dat als je via de BDE (Borland), ODBC (Microsoft), eventueel nog voorafgegaan door ADO (ook Microsoft), databases wilt gaan benaderen dit toch wel een hele omweg is als je het vergelijkt tot een simpele TADOConnection. Daarbij wil je het je eindgebruikers, en jezelf, toch niet aandoen om een BDE te gaan installeren, alleen maar om een ADOConnection op te bouwen.

In ieder geval: de TS komt er hopelijk uit en deze discussie raakt een beetje off-topic.