i struggling figure out commands want use after changing database. i'm learning via sqlite3 , db-aware controls, , here's understanding ...
when user types in db-aware control (or otherwise puts in memory dataset edit state), post store change in memory. controls automatically, or implicitly, you.
although have post before changes recognized anywhere, changes have not been sent actual database file on disk. they're in memory. sending changes disk requires applyupdates.
even after being sent file on disk via applyudates can still changed, or rolled back. it's hitting undo. not permanently saved disk until commit has been invoked.
does sound right? i'd know i'm doing i'm not copying , pasting code. please feel free copy, paste, , edit attempt in reply.
the answer question post, applyupdates , commit entirely different things , typically occur in different places (processes) , contexts in database app.
post , applyupdates both client-side operations, whereas commit sql operation may (or not) need explicitly called on server side complete transaction.
it's easiest understand differences if consider three-tier server. sqlite bit of oddball, because it's not true sql server of sort that's designed respond calls different processes on different machines (though can back-end of 3-tier system_.
about simplest traditional 3-tier arrangement has middle-tier delphi server sits between sql server, ms sql server, , client-tier, typically delphi program running on client machine. borland/emba's traditional technology implement datasnap.
the client tier contains tclientdataset (or 3rd-party equivalent) receives data back-end sql server via server-specific tdataset descendant in middle tier. although getting data sql server middle tier involves transaction on sql server, once data loaded cds in client tier, there no transaction pending on sql server (unless go out of way keep transaction open on server, not friendly other users of server , consumes lock resources on server, finite).
when edit data in cds (or tdataset descendant, actually), puts dataset dsedit state (see online tdatasetstate). changes made provisional, meaning can undone in cds until call .post, saves them cds's data (in case of tclientdataset, changes client-side data can rolled event after calling .post, long .applyupdates hasn't been called). remember there no transaction pending on sql server (or @ least, there shouldn't be) when .post called on cds in client tier.
calling .post not cause changes propagated counterpart middle-tier dataset. initiate that, call applyupdates on client-tier cds, ripples through tdatasetprovider in middle tier interfaces cds middle-tier's server-facing dataset. it's datasetprovider (or, more accurately tsqlresolver associated it) generates sql sent sql server apply changes sql database. so, in standard datasnap 3-tier set-up, don't have direct control on whether commit called or not.
commit sql operation performed sql server 1 of 2 possible ways complete transaction (the other being rollback). ms sql server, f.i., connection server may configured automatically wrap received update, insert , delete statements in implicit transactions.
the extent need concern transaction control depends on back-end server you're using , app's requirements in terms of concurrency other use of server data. if you're interested in slite's handling of transactions, consult docs dbcomponents you're using or source cide.
some delphi component libraries working true sql servers support expose facilities controlling server-side transactions, e.g. ibx ones interbase.
btw, in delphi terms, cachedupdates hang-over long-obsolete bde, borland's first attempt @ common db-access framework variety of back-end servers. persists in tdataset-descendant implementations , (regrettably, imo) has made of comeback in firedac, emba's latest cross-database offering.
Comments
Post a Comment