Timestamp Fields -- Are They Necessary?

Timestamp Fields -- Are They Necessary?

Post by Andrew Schmid » Mon, 06 Jan 1997 04:00:00



I am developing an app in VB4 32 Bit and SQL Server 6.5 using RDO. Should I
be using Timestamp columns in my tables? If so, in all tables or just some
tables. If I do use timestamps, I presume its for performance purposes. How
do I take advantage of them via RDO?
Thanks
--
Andrew Schmidt
Applied MicroSystems Corporation
(612) 975-0872

 
 
 

Timestamp Fields -- Are They Necessary?

Post by Michael Leu » Tue, 07 Jan 1997 04:00:00


Hi Andrew:

Keep in mind that a "Timestamp" for SQL Server is not really the
actual time and date.  The timestamp is stored internally as a binary
value.  It is primarily used to compare to see whether or not the
value has changed since you retrieved it last.

Michael

On Sun, 05 Jan 1997 22:19:10 -0800, "Andrew Schmidt"


>I am developing an app in VB4 32 Bit and SQL Server 6.5 using RDO. Should I
>be using Timestamp columns in my tables? If so, in all tables or just some
>tables. If I do use timestamps, I presume its for performance purposes. How
>do I take advantage of them via RDO?
>Thanks
>--
>Andrew Schmidt
>Applied MicroSystems Corporation
>(612) 975-0872


 
 
 

Timestamp Fields -- Are They Necessary?

Post by Paulo Cesar Zered » Wed, 08 Jan 1997 04:00:00


You can obtain more precise information about why and when use a timestamp
field under the Upsizing Tools Help file. You can download Upsizing Tools
from Microsoft.
Part of the help file follows:
A timestamp field contains a unique value generated by SQL Server which is
updated whenever the record is updated. Microsoft Access uses the value in
timestamp fields to determine whether a record has been changed before
updating it.
A timestamp field provides the best performance and reliability. In the
absence of a timestamp field, the Microsoft Access Jet database engine must
check all the fields in the record to determine if the record has changed,
which slows performance.
--
Paulo Zeredo

http://tba.com.br



Quote:> I am developing an app in VB4 32 Bit and SQL Server 6.5 using RDO. Should
I
> be using Timestamp columns in my tables? If so, in all tables or just
some
> tables. If I do use timestamps, I presume its for performance purposes.
How
> do I take advantage of them via RDO?
> Thanks
> --
> Andrew Schmidt
> Applied MicroSystems Corporation
> (612) 975-0872

 
 
 

Timestamp Fields -- Are They Necessary?

Post by John Edward Mille » Wed, 08 Jan 1997 04:00:00


Quote:> I am developing an app in VB4 32 Bit and SQL Server 6.5 using RDO. Should I
> be using Timestamp columns in my tables? If so, in all tables or just some
> tables. If I do use timestamps, I presume its for performance purposes. How
> do I take advantage of them via RDO?
> Thanks

Timestamps on all tables that get multi-user update activity.  Yes, it's
necessary.

The ODBC driver will supposedly use them automatically if you use
RD_CONCUR_ROWVER concurrency control.  If you need to write T-SQL to use
them
you use the horribly documented TSEQUAL() function that was part of
SELECT...
FOR BROWSE way back when, I guess...

John.

 
 
 

Timestamp Fields -- Are They Necessary?

Post by Andrew Schmid » Sat, 11 Jan 1997 04:00:00


Paulo,
I have read the following passage. It does not address VB accessing SQL
Server via RDO. I am not going through jet. I have yet to find anything
that tells me if timestamps are even usefull when accessing SQL Server this
way.
Seen anything specific on RDO?
Andy



> You can obtain more precise information about why and when use a
timestamp
> field under the Upsizing Tools Help file. You can download Upsizing Tools
> from Microsoft.
> Part of the help file follows:
> A timestamp field contains a unique value generated by SQL Server which
is
> updated whenever the record is updated. Microsoft Access uses the value
in
> timestamp fields to determine whether a record has been changed before
> updating it.
> A timestamp field provides the best performance and reliability. In the
> absence of a timestamp field, the Microsoft Access Jet database engine
must
> check all the fields in the record to determine if the record has
changed,
> which slows performance.
> --
> Paulo Zeredo

> http://tba.com.br



> > I am developing an app in VB4 32 Bit and SQL Server 6.5 using RDO.
Should
> I
> > be using Timestamp columns in my tables? If so, in all tables or just
> some
> > tables. If I do use timestamps, I presume its for performance purposes.
> How
> > do I take advantage of them via RDO?
> > Thanks
> > --
> > Andrew Schmidt
> > Applied MicroSystems Corporation
> > (612) 975-0872

 
 
 

Timestamp Fields -- Are They Necessary?

Post by Andrew Schmid » Sat, 11 Jan 1997 04:00:00


John,
I can use rdConcurRowVer when executing SQL UPDATE commands via RDO. I
presume from the limited documentation I've seen that this option causes
ODBC to use the timestamp field to determine if the underlying record has
been changed since read before proceeding with the UPDATE. Can I also infer
that a column by column comparison would be required if the timestamp field
was not present? And finally, I don't see the need to use the TSEQUAL()
function. When would its use come into play.
Thanks
Andy



Quote:> > I am developing an app in VB4 32 Bit and SQL Server 6.5 using RDO.
Should I
> > be using Timestamp columns in my tables? If so, in all tables or just
some
> > tables. If I do use timestamps, I presume its for performance purposes.
How
> > do I take advantage of them via RDO?
> > Thanks

> Timestamps on all tables that get multi-user update activity.  Yes, it's
> necessary.

> The ODBC driver will supposedly use them automatically if you use
> RD_CONCUR_ROWVER concurrency control.  If you need to write T-SQL to use
> them
> you use the horribly documented TSEQUAL() function that was part of
> SELECT...
> FOR BROWSE way back when, I guess...

> John.

 
 
 

1. Verify the presence of necessary fields in a table

I am upgrading a database product that uses Paradox tables.

In the new version, some of the tables have more fields than
in the old version.  When the user upgrades, I want the
new version to be able to check a particular directory,
determine if all the necessary fields are there, and if
they are correct size and type, and if necessary,
add new fields and change size and type.

1.  Does anyone have a good algorithm to do this?

2.  Since question #1 could be quite complicated, how
do I add or insert a field in an existing table?  I can't find
a Delphi way to do this, can it only be done with a BDE API
call?

3.  How is this upgrade type of problem normally handled?

--
Bob-o-Bob
Delphi and MFC Programming

2. selecting more than on record

3. printing a varchar field as wide as necessary

4. XML feed.

5. How can i get only the time in am/pm format from datetime field

6. Connect VB to mailing label reports in Access

7. I am getting this message when i am tring to export or import anything using

8. JET 4.0 BAD PERFORMANCE WORKAROUNDS

9. WHAT DBGRID FIELD AM I

10. Getting AM/PM Time formatting in a field with two Times

11. In wich field am I?

12. error ORA-01855: AM/A.M. or PM/P.M. required

13. Busy Day = Slowdown from 12 AM - 5 AM