sql - Does the precision of datetime field change when used with bigint field to form a composite key or Unique Index? -

i need use composite key or unique index comprised of bigint data type , datetime data type. however, i've noticed seconds element of datetime has been rounded nearest minute , causes duplicate key violation when trying import dataset.

the dataset transactional data, our id (stored in bigint field) repeated, hence need inclusion of datetime field in unique key.

to give example: following 2 rows cause 'duplicate key row' error:

id field (bigint) | actiondate (datetime)
--------------------- |--------------------------
1050000284002 | 2016-01-08 15:51:24.000
1050000284002 | 2016-01-08 15:50:35.000

the values different (and stored correctly in database) error shows:

the duplicate key value (1050000284002, jan  8 2016  3:51pm). 

(it's worth adding created composite key , have since replaced unique index; error outlined above generated index in place.)

my questions are:

1. is datetime field being rounded because i'm using integer in key/index?
2. is there reason lose accuracy of time component of datetime field?
3. how can rectify issue example wouldn't result in key violation?

if using index of form (index on columns a,b) , not formulaic 1 (index on columns + b), no, datatype of 1 column have no effect on contents of other.

based on description, i'd check following:

• the actual datatype of datetime column. datetime? (datetime round nearest 333rd of second, though that's not issue here.)
• the actual definition of index. defined think defined? perhaps indexing on date(datetimecolumn)?
• the actual data being stored. whatever loading data table perhaps truncating seconds?

---

further suggestions based on edit:

if data importing contains unique datetime values, yet sql not identifying unique date values, something's data import process.

try loading data table without index in place. load? match source data millisecond? now, data loaded, create index (primary key, unique constraint, whatever). fail? where's duplicate data coming from? in short, mess around data , loading processes , see falls out.