TDBPlannerMonthView ADOTable synch issue

I am using a TDBPlannerMonthView component hooked to an ADOTable, but with DataBinding.UpdateByQuery set to True.  I trap OnInsertItem and insert into the database via an ADOQuery.

If I then navigate off of the Month I am on, and back to it, my TPlannerItem item has disappeared from the MonthView control.
In the TPlanner/TDBPlanner Developers guide, page 72, there is a comment that if other DB-aware components are used to update the database, the TDBPlanner must be synchronised.  It explains that this synchronisation is achieved by calling the TDBItemSource.SynchDBItems method in the dataset AfterInsert.
With the TDBPlannerMonthView, there is no TDBItemSource, so this is not an option.  I have played with closing and opening the ADOTable, but that (surprisingly to me) brue force approach didn't work, only restarting the app refreshes the view correctly.
Anybody know how this synchronisation can be achieved with the TDBPlannerMonthView component?
Many thanks
Keith Comley 

Do you see the record for the event being inserted in your database? If you have set UpdateByQuery = true, your code should do this. If you see the record inserted, did you inspect its start & end date, i.e. does it match the correct month?

Hello Bruno,

Yes, the data item is correctly inserted with correct start and end times.  I have just tested with pressing the Insert button, as well as creating an item programmatically (via DBPlannerMonthView2.CreateItem etc.) and in both cases the item initially appears, but when you navigate off of the month and then back to it the item disappears.
When you restart the application however the item is correctly shown.

I can only assume the data isn't in the connected dataset. If this is query based, is this a runtime updateable query? Did you try to rerun the query?

It certainly would seem that way, but no I'm afraid the data is present.  Tracking through, the following sequence occurs:

- Press Insert on the DBPlannerMonthView (databinding specifies UpdateByQuery)
- The insert triggers DBPlannerMonthView2InsertItem
- InsertItem builds an ADOQuery which is ExeccSQL'd (INSERT INTO Schedule (foo) VALUES (foo) )
- The item appears in the DBPlannerMonthView, and in the database the entry is created
- Navigate to the next month in DBPlannerMonthView, then navigate back, the item has disappeared
- Without any further action, restart the application, the item is where it should be

It's not clear how you have verified the record is effectively in the dataset from this description.
I'd suggest to connect a TDBGrid to this datasource and check that your new inserted event appears in the TDBGrid. If not, it means your dataset is not refreshed.

Hi Bruno,

This was a good test, and reveals the unusual behaviour of the ADOTable/underlying database.  In answer to your question I had looked into the database, so I knew the record was there.
However, ADOTable didn't synchronise with the tables changes, as hooking up to a DBGrid revealed.  I discovered that after the insertion, repeated calls to ADOTable1.Refresh; do not refresh.  Immediate ADOTable1.Close ADOTable1.Open, following an ADOQuery insertion, did not refresh.  You can Close/Open for perhaps a second or two after the insertion, and the DBGrid still will not refresh.  After a couple of seconds though, the ADOTable Close/Open does work as I would expect, and the DBGrid gets refreshed (and at this point of course the PlannerItem becomes persistent and doesn't display the 'disappearing' behaviour).
I have tried this with both MSAccess (from your demo 23) and SQL server (my primary DBMS), and the behaviour is the same.
After some playing around here is the only solution I have which seems to work consistently, following the insertion of a record:
  DBPlannerMonthView2.DataSource := nil;
  DBPlannerMonthView2.DataSource := DataSource1;
If I omit any one (or pair) of these steps the ADOTable doesn't refresh correctly.  I'm not sure how scalable this is as a solution (performance), but locally it seems fine.
Thanks for your help,
Best regards Keith