Vraag & Antwoord

Programmeren

query component kopieren naar returnwaarde functie (delphi)

7 antwoorden
  • beste lezer, in onderstaand stukje code ik dat 'query' gekopieerd wordt naar de Returnwaarde van de functie alvorens 'query' wordt opgeruimd. ik dacht dat ik dit zo goed had gedaan, maar blijkbaar wordt de query niet gekopieerd, want als de functie is afgesloten is de returnwaarde niet gevuld met de query... Code: function Tdm.GetAllRecords(tabelnaam: string): TADOquery; var query: TADOquery; begin Result := nil; query := TADOQuery.Create(nil); query.Connection := adocnBeofactuur; query.SQL.Text := 'SELECT * FROM '+tabelnaam+' '; query.Open; Result := query;//hier moet de kopie gemaakt worden query.Close; query.Free; end; wie weet hoe ik dit op de juiste manier kan wijzigen? alain dacier
  • Die result := nil lijkt hem zijn geheugen te ontnemen, probeer 't eens zonder?
  • hier ligt het niet aan, zonder deze regel reageert ie precies hetzelfde zo doet ie het wel, maarja je begrijpt dat ik die laatste 2 regels niet als commentaar erbij wil. [code:1:d5de37521a]function Tdm.GetAllRecords(tabelnaam: string): TADOquery; var query: TADOquery; begin Result := nil; query := TADOQuery.Create(nil); query.Connection := adocnBeofactuur; query.SQL.Text := 'SELECT * FROM '+tabelnaam+' '; query.Open; Result := query; //<<<probleem! query.First; ShowMessage(query.FieldByName('categorienaam').AsString); Result.First; ShowMessage(Result.FieldByName('categorienaam').AsString); //query.Close; //query.Free; end;[/code:1:d5de37521a] dus dit betekend dat hij de result 'doorlinkt' en niet kopieert, maar hoe moet ik die dan toch KOPIEREN ??? alain
  • Het is vrij logisch, je sluit op het laatst het object (close) en haalt het uit het geheugen (free). Daardoor ben je ook het resultaat kwijt. Ik gebruik meestal een tijdelijk object die ik bij het begin van het programma aanmaakt die ik door het programma gebruik om snel even wat resultaten te gebruiken. Kopieren gaat door een tweede object te maken en daar de resultaten naar toe te kopieren.
  • Inderdaad, zoals RK al zei, je object is uit het geheugen. 'query' is in dit geval alleen een verwijzing naar een geheugenplek waar je object is opgeslagen. Als je dus invoert: [code:1:728966823a]Result := query;[/code:1:728966823a] Dan kopieert hij alleen de locatie van het geheugenplekje waar je object staat naar Result. Als je vervolgens het object op die locatie opschoont, dan is de verwijzing van Result dus ook onjuist.
  • ok ik begrijp het, maar hoe moet ik dan de data die de query heeft opgehaald teruggeven, zonder dat ik een geopende query heb? alain
  • [quote:49fdd35de8="20010196dacier"]ok ik begrijp het, maar hoe moet ik dan de data die de query heeft opgehaald teruggeven, zonder dat ik een geopende query heb?[/quote:49fdd35de8] [url=http://groups.google.nl/group/borland.public.delphi.database.ado/browse_thread/thread/6978eef98779fb9e/4285d9a5c678206e?lnk=st&q=delphi+disconnected+recordsets&rnum=2&hl=nl#4285d9a5c678206e]Heb je hier wat aan?[/url] [i:49fdd35de8] Disconnected Recordsets All this knowledge of batch updates allows us to take advantage of our next ADO feature: disconnected recordsets. A disconnected recordset is a recordset that has been disconnected from its connection. What is impressive about this feature is that the user cannot tell the difference between a regular recordset and a disconnected one; their feature sets and behavior are almost identical. To disconnect a recordset from its connection, the CursorType must be set to clUseClient and the LockType must be set to ltBatchOptimistic. You then simply tell the dataset that it no longer has a connection: ADODataSet1.Connection := nil; Hereafter, the recordset will continue to contain the same data, support the same navigational features, and allow records to be added, edited, and deleted. The only relevant difference is that you cannot update the batch because you need to be connected to the server to update the server. To reconnect the connection (and use UpdateBatch): ADODataSet1.Connection := ADOConnection1; This same feature is available to the BDE and other database technologies by switching over to TClientDataSets, but the beauty of the ADO solution is that you can build your entire application using dbGo dataset components and be unaware of disconnected recordsets. At the point that you discover this feature and want to take advantage of it, you can continue to use the same components that you always used. So why would you want to disconnect your recordsets? For two reasons: . To keep the total number of connections lower . To create a briefcase application [/i:49fdd35de8] Zo zie je maar, Delphi had dit allang geimplementeerd voordat het in .NET zat.

Beantwoord deze vraag

Weet jij het antwoord op deze vraag? Registreer of meld je aan met je account

Dit is een gearchiveerde pagina. Antwoorden is niet meer mogelijk.