Getting the time down to milliseconds

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Getting the time down to milliseconds.

I am trying to get the time down to the millisecond so I can use it to
create primary keys. Can I get the time down to the millisecond in Access
2002 in VBA?

I have tried to use the Now() function and to put it into a Double, but it
doesn’t reflect the millisecond when I test it out. When i click the button
it pretty much returns it down to the same second. I imagin that if i can
get it down to the millisecond that I won't be able to add records fast
enough to give it the same time.

(Example)

PlatoonID
38353.6403819444
38353.6403819444
38353.6403935185
38353.6403935185
38353.6403935185
38353.6403935185
38353.641099537
38353.641099537
38353.6411111111
38353.6411111111
38353.6411111111
38353.6411111111
38353.6411226852
38353.6691319444
38353.6691435185
38353.6691435185
38353.6691435185
38353.6691550926
38353.6691550926

Thanks
 
Getting the time down to milliseconds.

I am trying to get the time down to the millisecond so I can use it to
create primary keys. Can I get the time down to the millisecond in Access
2002 in VBA?

I have tried to use the Now() function and to put it into a Double, but it
doesn’t reflect the millisecond when I test it out. When i click the button
it pretty much returns it down to the same second. I imagin that if i can
get it down to the millisecond that I won't be able to add records fast
enough to give it the same time.


Public Declare Function GetClock _
Lib "winmm.dll" Alias "timeGetTime" () As Long

But I agree with Rob. Why not use an autonumber field?
 
I am creating an application that right now has about 37 remote groups (a
bunch of troops running around Iraq). They will be batching updates of their
data to the main database. (Once I figure out how, I ‘m planning to use SQL
Server 2000 with Sharepoint server) I want to use replication to synchronize
the data and application, but I don’t really trust the random number
generator with so many records being updated.

What do you guys think? Using the time is a bad idea for the primary key as
apposed to Autonumber.


Thanks for the Help!

Sorry it took so long to reply, reformated computer, problems with software...
 
Hmmm. That makes more sense. I don't really have any experience of the
kind of situation you describe, so I may be talking garbage here, but....

I would tend to still avoid using times as a PK - it may well work but isn't
going to be 100% reliable. Though that's obviously dependent on the number
of records they're adding.

Think I'd probably go for something like creating a multiple field PK from a
combination of an AutoNumber and something unique to the remote group -
login name, machine name, a code assigned to that version of the db maybe.
Presumably, in the synchronised version you're going to want to know which
of the 37 was responsible anyway, so that info is already going to be there.

I'll be interested to see what Marsh comes up with....
 
Nevie said:
I am creating an application that right now has about 37 remote groups (a
bunch of troops running around Iraq). They will be batching updates of their
data to the main database. (Once I figure out how, I ‘m planning to use SQL
Server 2000 with Sharepoint server) I want to use replication to synchronize
the data and application, but I don’t really trust the random number
generator with so many records being updated.

What do you guys think? Using the time is a bad idea for the primary key as
apposed to Autonumber.


I think Rob described the issues very well. The time value
has a slight chance of not being unique and trying to code
around that will be a mess.

OTOH, a compound PK with a group ID and an AutoNumber (with
the AutoNumber field set as a unique index in its own right)
will provide a way to identify the source of the data. I
use this approach for your kind of situation and have a
small table or file to hold the group/machine code. (Just
remember that an AutoNumber field should never be expected
to have any meaning beyond uniqueness.)

This makes merging new data records a simple matter of
running an append query. Updating existing master records
that have edited in the field is also simply a delete query
followed by an append query.

You may also want a date/time field for record creation, but
this is not part of the PK discussion.

I've always shied away from using replication, because it
comes with too much additional baggage for me to use it
where it is not absolutely required. However, a replication
AutoNumber field is a GUID so there couldn't be a conflict.

I'm not sure if you said you were thinking of using
replication to administer installation of code changes to
the field, but if you were, forget it. This is not the
intent of replication and everyone I've ever heard of that
tried it ran into all kinds of trouble. Stick with the
standard front end, back end configuration and just copy new
versions of the front end to the field machines when needed.
 
Ok, thanks for the advice!!

I already have the unique group information for them in a constants table,
but I was concerned that using text in there would slow it down. Although I
see that it’s going to make things more complicated to make it so code
dependent. But thanks for the time code, it worked, but you are right about
it not being the best approach.


I was thinking about using the replication for the code also, but the more
I’m reading about it, the more I shy away from it. I’ll split the database
and it’ll be easy to push the updated front end, and will give me more
flexibility.

Would you recommend using replication in VBA (on the split database data
component) to synchronize the data or would you recommend something else.
I’ll be synchronizing over the internet and making it upload only because I’m
not sure how to make it so that the server doesn’t push the data for the
other groups. I only want each of the troops (teams) to see their own data.

Thanks guys, if I ever see you around I’ll get you a drink.
 
Like I said before, I have managed to avoid using
replication, so I'm the wrong guy to answer your last
question.

My recommendation is to have a really hard look at your
requirements and only use replication if it's the only way
to meet them. You may get different advice from someone
else.
 
Back
Top