Support Forums - View Thread

View Thread

The following is the text of the current message along with any replies.

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 Team Elevate	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. >