RefreshQuick Problem

[Justmade]

RefreshQuick has serveral problems when there are more than 1 timestamp fields in a table.

For example, if I got 2 timestamp fields, 1 default to CURRENT_TIMESTAMP and the other default to null, which store some expiring Timing which is usually 1,2 days AFTER current date.

From what I observed,
1. TMyQuery pick the first encountered timestamp field to put in the where clause when doing RefreshQuick. So, I put my real timestamp field at the begining of the field list.
2. TMyQuery pick the largest datetime value from ALL timestamp field rather then the selected timestamp field. As the 2nd timestamp field store value for future, the RefreshQuick function just don't work as they cannot find records modified after the last load.

What I think is TMyQuery should pick the timestamp field which default to CURRENT_TIMESTAMP and only get largest datetime from THAT field.

I know I can use datetime to prevent it, but it take double space in field and index and sort slower.

Please let me know if this will be improved or the behaviour should act like current for some reasons I cannot think of. So, I can decide whether I need to choose between giving up refreshquick or change those extra fields to datetime type.

Thanks in advance for your knid help.

Justmade

[Dimon]

To solve the problem you can set the TMyQuery.SQLRefresh property manually and this SQL will be executed every time the RefreshRecord method is called.

[Justmade]

To solve the problem you can set the TMyQuery.SQLRefresh property manually and this SQL will be executed every time the RefreshRecord method is called.

RefreshQuick also call RefreshRecord?

It seems that RefreshQuick make a call of Select * from [tablename] where [FirstTimeStampFieldName] > [LargestValueOfALLTimeStampField]

Then it use the result to modify / append to the exisiting dataset.

This should be different from calling RefreshRecord?

This is a great feature especially when it is a large dataset but mixing up different timestamp fields make it hard to use in some case.

[Dimon]

Thank you for your inquiry. We will investigate the possibility of changing this behaviour in the near future. As soon as we solve this question we will let you know.

[Justmade]

As I had acquire MyDAC source code recently, I re-look at this issue and find a solution (I believe).

To distinguish between real timestamp field (the only one that auto-update when the record is changed) and other data storage timestamp field, you can check pField.flag against TIMESTAMP_FLAG (1024) in
TMySQLRecordset.InternalInitFields.CreateFieldDescs.CreateFieldDescs

I had do several test and only the real timestamp field will got this flag.

So, if you are willing, you can add a property of the TMySQLFieldDesc class and use this property to control the timestamp field selection as well as populating the tableinfo.maxtimestamp value.

I know I can edit the code myself but when thinking of having to re-editing everytime when I have to update, I would rather to ask you a favour of considering to make the enchantment to make the refreshquick more accurate and reliable.

Thanks again for your consideration.

[Dimon]

Thank you for information. We have reproduced this problem and fixed it. This fix will be included in the next MyDAC build.

[Justmade]

Thank you very much.