Please start any new threads on our new site at We've got lots of great SQL Server experts to answer whatever question you can come up with.

Our new SQL Server Forums are live! Come on over! We've restricted the ability to create new threads on these forums.

SQL Server Forums
Profile | Active Topics | Members | Search | Forum FAQ
Register Now and get your question answered!
Save Password
Forgot your Password?

 All Forums
 Old Forums
 CLOSED - General SQL Server
 Managing your own primary keys
 Forum Locked
 Printer Friendly
Author Previous Topic Topic Next Topic  

Ask SQLTeam Question

0 Posts

Posted - 07/12/2002 :  09:13:35  Show Profile  Visit AskSQLTeam's Homepage
James writes "We are developing a distributed application using SQL Server as the back end.

We do not want to use Identities for the primary keys. We are planning on making a "NextID" table that consists of each table name with the "next" ID that should be used.

Is there another way on managing primary keys without using Identities, especially when concurrency is an issue?


Flowing Fount of Yak Knowledge

2878 Posts

Posted - 07/12/2002 :  09:16:25  Show Profile
Yes! Use the table's NATURAL KEY....

Go to Top of Page

Constraint Violating Yak Guru

479 Posts

Posted - 07/14/2002 :  22:03:44  Show Profile
By all means, use the natural key. Failing that, consider the amount of traffic on the system before you implement any solution where every transaction will be going to the same table and updating the same row.

Go to Top of Page

Jedi Yak

2489 Posts

Posted - 07/15/2002 :  11:22:58  Show Profile  Visit MichaelP's Homepage
Another solution that works well with distributed applications is GUIDs.

Look up unique identifier and NewID() in BOL.


<Yoda>Use the Search page you must. Find the answer you will.
Go to Top of Page
  Previous Topic Topic Next Topic  
 Forum Locked
 Printer Friendly
Jump To:
SQL Server Forums © 2000-2009 SQLTeam Publishing, LLC Go To Top Of Page
This page was generated in 0.05 seconds. Powered By: Snitz Forums 2000