[DUG] MSSQL DBGrid Refresh
Eric A
eaa603 at hotmail.com
Thu May 17 09:31:30 NZST 2012
Neven,
Thanks for the response.
Yes, it is also my understanding that the ADO implementation is just a wrapper (like a number of the Delphi components). I did research the cursor options and try those but without a lot of success, although I must confess that I never looked at the resolver methods.
I'm not sure whether it is authoritative or not, but I recently found an article that claimed there were numerous problems with TADOTable and advocated using TADOQuery and/or issuing raw SQL commands via the ADOCommand or ADODataset object. From memory that might have been the site : http://www.prestwoodboards.com.
As this stage I've simply removed the TADOTable components as it transpired that for this simple (two tables with no relationships) application I didn't need them.
One of the big issues is that I can't see any way of getting notifications that other users have changed data, short of just using a timer to regularly refresh the datasets - not really a good solution. Normally you just get a message when you try to modify a record. Its not a major issue for this project although on larger projects some years ago it resulted in some pain...
Date: Thu, 17 May 2012 07:44:44 +1200
From: neven at mwk.co.nz
To: delphi at listserver.123.net.nz
Subject: Re: [DUG] MSSQL DBGrid Refresh
Eric
Please forgive me if I'm not 100% with my terminology, its been
years since i did my last ADO project on MSSQL, As I recall ADO is a
thinly disguised wrapper around MSSQL cursors, so its not so much if
you use ADOTable or ADOQuery (both wrap the the ADO commandSet?
object) but there are a couple of properties which determine which
type of SQL cursor it uses (static, dynamic, fast forward), the
resolver method (timestamp, PK?) and the update (row or batch).
In the end I was so frustrated with it I used kBMMemtable, kbm
Custom resolvers and relegated the ADO to executing fetch and
update queries!
Its one on those situations where basically you *have* to understand
what it expects you to do because if you vary from its methodology
it is just painful
HTH Neven
On 16/05/2012 9:39 a.m., Eric A wrote:
No, I've tried the Requery method and as I understand it the
Requery method is effectively doing the same as the Open and
Close sequence, i.e. forcing the select statement to be reissued
against the database.
For record deletion I call the nbDelete button method on the
DBNavigator followed by closing/opening the ADOQuery and that
does result in the data being refreshed in the DGBrid.
For adding and editing records I am using the ADOTable
"Append"/"Edit" and "Post" methods on the table followed by
closing/opening the ADOQuery (or ADOQuery.Requery) and for some
reason (which presently escapes me) the data is not refreshed in
the grid.
The question is should I even be using the ADOTable and would I
better off just issuing raw SQL commands via the ADOCommand or
similar component?
Eric
Date: Tue, 15 May 2012 21:09:31 +1200
From: vikas.image at gmail.com
To: delphi at listserver.123.net.nz
Subject: Re: [DUG] MSSQL DBGrid Refresh
Hi Eric,
With AdoQuery you can try Requery method.
This article might help.
http://edn.embarcadero.com/article/23011.
Hope it helps
Regards
Vik
On Tue, May 15, 2012 at 8:51 PM, Eric A <eaa603 at hotmail.com>
wrote:
I am using a DBGrid with an ADOQuery component for
display, with modifications to table data (edits,
deletes, adds) being done using a ADOTable
component. CRUD operations are done using the table
methods rather than raw SQL code. There's a lot of
fields in the database table so coding the
operations in SQL would be a pain.
Despite trying to refresh the data in the DBGrid by
closing then re-opening both the ADOTable and the
ADOQuery component the data in the DBGrid is not
updated (unless I exit the application and restart.
I've seen this problem mentioned in various postings
but haven't yet seen a solution. Can someone supply
the elusive technique to get the DBGrid data to
refresh after the ADOTable data is changed?
Eric.
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz
with Subject: unsubscribe
--
vikas
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to
delphi-request at listserver.123.net.nz with Subject: unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz with Subject: unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz with Subject: unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20120517/778da3a3/attachment-0001.html
More information about the Delphi
mailing list