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: [email protected] To: [email protected] 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: [email protected] To: [email protected] 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 <[email protected]> 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: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe -- vikas _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
