I have a table with a [TimeCreated] field, datatype date/time, contains date AND TIME the record is created. This field is indexed (no duplicates). Any reason I shouldn't just use this field as the PK?
I have a table with a [TimeCreated] field, datatype date/time, contains date AND TIME the record is created. This field is indexed (no duplicates). Any reason I shouldn't just use this field as the PK?
If you could insert multiple records using an Insert query , then you may get errors, as the datetime field may end up being the same.
Not sure as I've never used it as a PK in Access.
SQL Server timestamps are not actually a date time field, so that may be confusing you.
DLookup Syntax and others http://access.mvps.org/access/general/gen0018.htm
Please use the star below the post to say thanks if we have helped !
↓↓ It's down here ↓↓
No, in just using Access. Conflicting times shouldn't be a problem as there won't be any batch inserts. Field is already unique.
As Minty pointed out, there is a risk of errors during inserting rows but there is also another issue. Date/time columns take up more space than an int or long integer which would slow up searches using the column as a primary key when you need to join it to another table and take up more space.
The only time that I've found where a primary key on a date column/field makes sense was in a time dimension which is beyond the scope of this question.
Ah, I had it in my head that long and date/time (double) both used 8 bytes, but it looks like long only uses 4 bytes. Thanks for the heads up.