![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 5 of 5 total |
![]() |
Wed, Jul 25 2012 10:04 PM | Permanent Link |
Adam H. | Hi,
I was wondering if someone could please clarify this property for me. Does this reflect the last time the TDBISamTable dataset was updated, the table according to the relevant session, or the actual table on the disk itself? I'm testing this with a local application. I have tried modifying a table in DBSYS while the application was running but the application still seems to be pointing to the same original datetime stamp from prior to me editing the table. Just wondering if I'm doing something wrong my end, or whether I'm misunderstanding the property. Thanks & Regards Adam. |
Thu, Jul 26 2012 4:22 PM | Permanent Link |
Raul ![]() | It's the table itself so even if you have multiple sessions (and/or multiple apps) then they would detect the new timestamp (note that if another sessions and/or app has the table open duing the change it might need to do a refresh to see the updated timestamp Raul On 7/25/2012 10:04 PM, Adam H. wrote: > Hi, > > I was wondering if someone could please clarify this property for me. > > Does this reflect the last time the TDBISamTable dataset was updated, > the table according to the relevant session, or the actual table on the > disk itself? > > I'm testing this with a local application. I have tried modifying a > table in DBSYS while the application was running but the application > still seems to be pointing to the same original datetime stamp from > prior to me editing the table. Just wondering if I'm doing something > wrong my end, or whether I'm misunderstanding the property. > > Thanks & Regards > > Adam. |
Thu, Jul 26 2012 7:53 PM | Permanent Link |
Adam H. | Hi Raul, Thanks for that. I think I've found my problem. (Embarrassing mistake) It would appear as though I should execute a TTable.Refresh command before looking for the lastupdated property. Once again, thanks for the reply, and have a great weekend! Cheers Adam. On 27/07/2012 6:22 AM, Raul wrote: > > It's the table itself so even if you have multiple sessions (and/or > multiple apps) then they would detect the new timestamp (note that if > another sessions and/or app has the table open duing the change it might > need to do a refresh to see the updated timestamp > > Raul > > On 7/25/2012 10:04 PM, Adam H. wrote: >> Hi, >> >> I was wondering if someone could please clarify this property for me. >> >> Does this reflect the last time the TDBISamTable dataset was updated, >> the table according to the relevant session, or the actual table on the >> disk itself? >> >> I'm testing this with a local application. I have tried modifying a >> table in DBSYS while the application was running but the application >> still seems to be pointing to the same original datetime stamp from >> prior to me editing the table. Just wondering if I'm doing something >> wrong my end, or whether I'm misunderstanding the property. >> >> Thanks & Regards >> >> Adam. > |
Thu, Jul 26 2012 7:54 PM | Permanent Link |
Adam H. | Hi Raul,
Thanks for that. I think I've found my problem. (Embarrassing mistake) It would appear as though I should execute a TTable.Refresh command before looking for the lastupdated property. Once again, thanks for the reply, and have a great weekend! Cheers Adam. On 27/07/2012 6:22 AM, Raul wrote: > > It's the table itself so even if you have multiple sessions (and/or > multiple apps) then they would detect the new timestamp (note that if > another sessions and/or app has the table open duing the change it might > need to do a refresh to see the updated timestamp > > Raul > > On 7/25/2012 10:04 PM, Adam H. wrote: >> Hi, >> >> I was wondering if someone could please clarify this property for me. >> >> Does this reflect the last time the TDBISamTable dataset was updated, >> the table according to the relevant session, or the actual table on the >> disk itself? >> >> I'm testing this with a local application. I have tried modifying a >> table in DBSYS while the application was running but the application >> still seems to be pointing to the same original datetime stamp from >> prior to me editing the table. Just wondering if I'm doing something >> wrong my end, or whether I'm misunderstanding the property. >> >> Thanks & Regards >> >> Adam. > |
Thu, Jul 26 2012 7:54 PM | Permanent Link |
Adam H. | Hi Raul,
Thanks for that. I think I've found my problem. (Embarrassing mistake) It would appear as though I should execute a TTable.Refresh command before looking for the lastupdated property. Once again, thanks for the reply, and have a great weekend! Cheers Adam. On 27/07/2012 6:22 AM, Raul wrote: > > It's the table itself so even if you have multiple sessions (and/or > multiple apps) then they would detect the new timestamp (note that if > another sessions and/or app has the table open duing the change it might > need to do a refresh to see the updated timestamp > > Raul > > On 7/25/2012 10:04 PM, Adam H. wrote: >> Hi, >> >> I was wondering if someone could please clarify this property for me. >> >> Does this reflect the last time the TDBISamTable dataset was updated, >> the table according to the relevant session, or the actual table on the >> disk itself? >> >> I'm testing this with a local application. I have tried modifying a >> table in DBSYS while the application was running but the application >> still seems to be pointing to the same original datetime stamp from >> prior to me editing the table. Just wondering if I'm doing something >> wrong my end, or whether I'm misunderstanding the property. >> >> Thanks & Regards >> >> Adam. > |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |