Seeded(int) Identity Columns Vs. UniqueIdentifiers(GUIDs)
Jul 1, 2003
I need gurus input on the pros and cons of Seeded(int) Identity colums vs. UniqueIdentifier(GUIDs) columns for my db design.
As I understand it, merging the data of 2 independent db's both using IDENTITY columns would be very hairy because of the possibility of overlap. GUIDs are much more likely to be unique across different servers.
What I'd like to hear from others are the other pros and cons of the situation. I of course understand the performance hit suffered at the hands of the GUID.
We're trying to set a new standard at my office, of using GUIDs as database ID fields - all new tables in all databases will have a GUID as the ID field, using the UniqueIdentifier data type.
The problem that we are running into, is that different applications interpret the UniqueIdentifier data type differently - ADO 2.x interprets it with the opening and closing { } braces. ADO.NET does not include the { and } in the GUID structure, SQL Server Query Analyzer does not include the { } braces, and SQL Server Enterprise Manage does include the { }
The problem with this is in two parts: 1) VB6 does not have a GUID structure or data type, so we are treating GUIDs as strings... but VB6 doesn't recognize "{012345678-abcd-ef01-2345-6789abcd}" and "012345678-abcd-ef01-2345-6789abcd" as the same string 2) when sending a URL link through an email, the { } braces break the link - in all email applications that we have tested. This include Groupwise 6, Groupwise 6.5, IPSwitch Web IMail, Outlook 2000, and Outlook Express (IE 6).
We're becoming very frustrated with the problems at hand, and need to know how others have worked around these problems. Please respond with any kind of advice or any real life situations where you have encountered this and found a solution, etc.
I am planning to use transacational replication (instead of merge replication) on my SQL server 2000. My application is already live and is being used by real users.
How can I ensure that replicated data on different server would have exact same values of identity columns and date columns (where every I set default date to getdate())?
It is very important for me to have a mirror image of data (without using clustering servers).
Just to confirm, do identity columns and XML columns work OK with database mirroring ? That is, all data types are supported with mirroring, and identities aren't an issue ?
Transactional replication with identity columns was a right pain in the **** in SQL 2000. I'm assuming that mirroring doesn't have these issues, but want to be sure.
My first time using the Membership API for .net 2.0 and Sql Server.The userId column is given a unique identifier instead of an autonumber. Like 011fb845-1269-49ca-b5b0-c01efdab0cff So say I want to see how many goals they have logged. I could do a Select * From pgGoals where UserId = "011fb845-1269-49ca-b5b0-c01efdab0cff" ? Should I keep propagating this unique id? for example the goal table has 3 columns, UserId, GoalName, GoalCatIdWhen I set a new goal for that user I populate the UserId column in the database table with the value 011fb845-1269-49ca-b5b0-c01efdab0cff ?? Will this be hard on the database as opposed to an integer id of say 23 ?
=================================================================== When I try to run the report I receive the following error message:
An error occurred during local report processing An error has occurred during report processing Query execution failed for data set 'my dataset' Incorrect syntax near the keyword 'CONVERT',
The question: How can I use report parameters to hold a default uniqueidentifier and then use that in the dataset query? I have tried using it without the convert function but then the following error is raised.
An error occurred during local report processing An error has occurred during report processing Query execution failed for data set 'my dataset' Error converting data type nvarchar to uniqueidentifier.
Can anyone describe how SQLServer calculates identity columns? Does it use some internal counter when generating the next identity, or something a little more mundane such as gets the highest existing identity value at the point of the insertion and increments it by the IDENT_INCR value of the identity column?I’m not worrying about reliability or gaps in values, but i am wondering if it would be less efficient for me to manually manage the identity/primary key in the form of a counter in another table used to generate the new identity, or simply let the DB do it for me. I dont mind if there are gaps in the sequence etc. so would it be less efficient for me to calculate the field than SQLServer itself? Basically, is the overhead to the DB of me doing it greater than the overhead of the app doing it...Thanks
I have a question about IDENTITY columns. I am working for a client that has an entire employee database that uses IDENTITY columns without any Primary keys defined. I have never seen this done. Is it ok or should I recommend that it be changed to use Primary keys?
The DBA that built the database is no longer with the company and the client has no DBA. Where can I get some information on how to use IDENTITY columns? I did not get much from the help file.
I have been using the following query to identify the IDENTITY columnsin a given table. (The query is inside an application.)select column_namefrom information_schema.columnswhere table_schema = 'user_a' andtable_name = 'tab_a' andcolumnproperty(object_id(table_name), column_name, 'IsIdentity') = 1This works. When "user_a" performs the query, everything is OK.Now, another user wanted to use the same application. So, "user_b"clicks on a button, and the exact same query as above is run. (Nosubstitutions are made; user_b is trying to see the identity column in[user_a].[tab_a]). However, the query returns null, instead of theidentity column name. User_b can read the table and select from itjust fine.Why am I getting two different results against the same query? Do Ineed to rewrite the query to go against different information schemaviews?
I'm seeing some weird behavior regarding identity columns in MSSQL 2000.In a specific client database we have this table: ID Name SecLevDG Flags ----------- ----------------- ----------- ----------- 1029528 xxx 0 01029529 xxx 0 01049676 xxx 0 0 While upgrading this database to a later version of our product, some schema changes are necessary. For this particular table, the changes are
alter table Authority drop constraint apkAuthorityId alter table Authority drop column SecLevDg alter table Authority add new_id integer identity
This code has worked perfectly for years, and even in this particular database, there are no error messages. However, the result isn't quite the expected:
ID Name Flags new_id ----------- ---------------- ----------- ----------- 1029528 xxx 0 167772201029529 xxx 0 167772201049676 xxx 0 16777220
Notice that the new column did NOT get unique values 1, 2, 3, etc... In other tests I manage to get different values, but still not the expected ones. Is this a bug in MSSQL 2000?
DBCC CHECKIDENT returns: Checking identity information: current identity value '1', current column value '1'.
DBCC CHECKDB returns no errors before running the above statement. Afterwards it returns this (only relevant messages included): Server: Msg 8970, Level 16, State 1, Line 1 Row error: Object ID 293576084, index ID 0, page ID (1:277), row ID 0. Column 'new_id' was created NOT NULL, but is NULL in the row. Server: Msg 8970, Level 16, State 1, Line 1 Row error: Object ID 293576084, index ID 0, page ID (1:277), row ID 1. Column 'new_id' was created NOT NULL, but is NULL in the row. Server: Msg 8970, Level 16, State 1, Line 1 Row error: Object ID 293576084, index ID 0, page ID (1:1145), row ID 0. Column 'new_id' was created NOT NULL, but is NULL in the row. [...] CHECKDB found 0 allocation errors and 3 consistency errors in table 'Authority' (object ID 293576084).
I have an app that has multiple users inserting and updating from a couple key tables using SQL Server 2005. In my previous SQL coding life, I was able to make use of sequence.NextVal to find and lock the next available sequence value for a table. Currently I am in the SQL Server 2005 world and cannot do this. I have found all sorts of help for Ident_currentand Identity columns, but nothing on how to accomplish the same as a NextVal did. I can add one to the Ident_Curr but I think I run the risk of that value being used by another user before the current user can get his update in. Is that correct? Is there a way to accomplish what I am trying to do? Basically what I need to do is when a user inserts a record in table "Loads" I need to insert behind the scenes to table "Comments" with the ID of the row created in the "Loads" table. Thank you in advance, Garth
I am using sql 2000 dts package to migrate a databse to SQL Server 2005, everything works except for identity columns, SQL Server reorder the columns, and this breaks the referential integrity. Is there a way to stop that? Your help is appreciated.
I would like to know different possible ways in appending extra values like new uniqueidentifiers, sequence numbers, random number. Can you please tell what type of data flow components helps us ?
I use the identity = yes for my unique columns in most of my tables that need it. I am trying to decide if I should change identity = no, and instead manually update my unique number column myself by adding one when I insert new rows.
The reason I want to do this is for maintainabilty and ease of transfering data for backup to other sql servers. I always have trouble keeping the identity numbers to stay the same as they are in the original database because when they are transfered to a db that has identity = yes, the numbers get rearranged.
It will also make it easier to transfer data from original db to another sql server db and use the data right away without having to configure the destination db to disable identity and then enable it, etc.
I have a production database with about half the tables using IDENTITY columns for PRIMARY KEYS. This system is configured as both a Publisher and a Distributor. We are using Transactional Replication without updates. The SQL Server Agent runs every hour to pick up any changes and replicate them to the Subscriber (another SQL Server machine configured as our failover server).
Both servers are running SQL Server 7.0 (original, no service packs) under Windows NT 4.0 (SP4).
The failover server (the replication Subscriber) will only be used if the primary server goes down. And hopefully, only for a short time before the primary server comes back online. During the time that the failover is actually being used, the application will not make any changes to the database.
The IDENTITY values that are replicated need to stay with their original values. The replication process CANNOT assign new values to these columns when there are inserted into the database on the Publisher (i.e. failover server)
My question is: According to the documention, I can add 'NOT FOR REPLICATION' to the IDENTITY columns and the values will be preserved. But a collegue of mine says that resets the IDENTITY sequence on the subscriber and the 2nd time a row gets inserted on the Publisher, the values get messed up. On his system, he calls a stored procedure for the tables with IDENTITY columns, and in the stored procedure, he executes a 'SET IDENTITY_INSERT OFF', then INSERTS the row, then 'SET IDENTITY_INSERT ON'. He claims that this approach solved his issues with IDENTITY columns.
Who is right? Do I have to create a stored procedure for replication for every table with an IDENTITY column, or can I just add 'NOT FOR REPLICATION' and SQL Server will handle the rest?
NOTE: Upgrading to SQL Server 2000 is NOT an option right now. Although, if a Service Pack for 7 fixes this, that might be an option.
Thanks in advance for any help you can shed on this issue.
We are trying to run replication from one server to another. Most of the tables in the publishing database have identity columns set. At one point the subscribing database had a match of identity columns and primary keys matching the publishing database. Obviously with a primary key set on the subscriber there would be conflicts with duplicate key inserts. We disabled the identity columms and droped the indexes and the data was able to replicate over. However, we discovered that the identity columns, which are used to generate id's on many of our tables, were not replicating over to the subscriber. In fact a null value was being inserted into the subsriber database.
Anyone seen this before? What, if there is one, is the solution?
hi there. I was wondering is there any way that you can use an Identity Column on both a subcribing and Publishing table in Replication, I am receiving errors when I run Replication with Identity Columns, Thanks in advance Fin
Hi folks! I've a merge replication setup b/w two servers. Published tables have columns (INT IDENTITY SEED 1 INCREMENT[NOT FOR REPLICATION]). Whenever i apply the SNAPSHOT, i have to run DBCC CHECKIDENT('table' RESEED) for each table at the subscriber twice, for the values in the columns are almost always greater than the ID-Seed value. For example the last Identity value in the column is 999 but whenever i insert a new row; i get error; couldn't insert duplicate value into the table. When i run the dbcc check i see the following message: "Checking identity information: current identity value '1', current column value '999'." How do i square this away?
Anyone know if MS-SQL Server supports IDENTITY columns that are incremented for each new value of the column it depends on.
For exameple: Let's say I have a client table with a ClientID column as it's PRIMARY KEY. This column can be an auto-incrementing IDENTITY column.
Then I have an orders table. The PRIMARY KEY for the orders table is composed of (ClientID, OrderID). I would like the OrderID to be an IDENTITY field that increments by an arbitrary value (1 in this case) for every new value of ClientID...therefore creating a unique PRIMARY KEY.
MySQL (and maybe other RDMS's...I haven't checked) seems to do this automatically when you set a column as AUTOINCREMENT and then define a composite PRIMARY KEY on two fields. I know this can be done manually using triggers, but I was wondering if there was a better way...
Hi, I noticed that tables containing IDENTITY columns skip IDENTITY values when a transaction is rolled back. Is there any way to avoid this? By "avoid" I mean make the table continue generating IDENTITY values from where the last COMMITTED insert took place.
Example:
CREATE TABLE ATable (A INT IDENTITY, B INT);
INSERT INTO ATable (B) VALUES (39); INSERT INTO ATable (B) VALUES (51); INSERT INTO ATable (B) VALUES (62); INSERT INTO ATable (B) VALUES (93); INSERT INTO ATable (B) VALUES (10);
Is there a way to have SQL-Server continue from where it left off (IDENTITY VALUES 6, 7, 8) without having to generate the numbers manually or occasionnally turning on IDENTITY_INSERT on the relevant table(s)?
In my application I am using Identity columns. When some rows are deleted from table, This identity values are not filling the gap. I mean My current identity is 5. That means 1 to 5 rows sequentially i inserted. If I am deleting 3rd and 4th rows, next identity will still continue with 6. So is there any method to fill the gap between rows
I have a stored procedure which gets data from several tables in database A and inserts them into the same tables in database B. Before the inserts are done, the data in database B is removed currently by using the TRUNCATE statement.
Unfortunately these tables are now being used for replication and you cannot TRUNCATE a table used for replication.
The issue is that these tables contain an Identity column each and using DELETE means the Identity columns will be incremented from the last value each time. I do not want this to happen.
Is there any way of reseeding an Identity column without using the DBCC CHECKIDENT statement because I do not want the procedures to run under the "sa" context if a DBCC statement was to be incorporated into the stored procedure with a DELETE statement?
Hello,I am creating a new database and I was advised to use Sequential Guids.I was reading some information and, as far as I understood, I can use NEWSEQUENTIALID. This can be used when I have a uniqueidentifier column as the key of a clustered index to avoid fragmentation during insert. Ok, so I use NEWSEQUENTIALID instead of NEWID.But I will use LINQ most of the time instead of Stored Procedures.So can I specify in my tables scripts to use Sequential Guids when, for example, a record is created? And am I right when using Sequential Guids?Here is a part of my code:-- Blogs ... create table dbo.Blogs ( BlogID uniqueidentifier not null constraint PK_Blog primary key clustered, Title nvarchar(400) null, Description nvarchar(2000) null, CreatedDate datetime null )
-- Posts ... create table dbo.Posts ( PostID uniqueidentifier not null constraint PK_Post primary key clustered, BlogID uniqueidentifier not null, AuthorID uniqueidentifier not null, Title nchar(1000) null, Body nvarchar(max) null, UpdatedDate datetime not null, IsPublished bit not null, constraint FK_Posts_Blogs foreign key(BlogID) references dbo.Blogs(BlogID) on delete cascade, constraint FK_Posts_Users foreign key(AuthorID) references dbo.Users(UserID) on delete cascade Thanks,Miguel
hi.i am using ms sql server 2000. can somebody tell me what the code would be to remove all the values in a given column and replace them with the associated number of the row with each execution. so, if i have a column:nums|1||2||3||4|and somebody deletes record |2|i would like the nums colum to update to|1||2||3|not:|1||3||4|it seems simple but i am having a hard time with this. how is it done?thanks.
Normally when I have a "Many-toMany" or linkage table where the primary key consists of a foreign key from two different tables, I do not bother to make a separate identiy column instead.Does anyone see a reason why an identity column would be more or less desireable ? For exampleTable Person PK - PersonIDTable Car PK - CarIDTable PersonCar PK (PersonID, CarID)Or would it be better to make an Identity Column such as PersonCarID so then the table would look like the following:Table PersonCarPK - (PersonCarID)FK - PersonIDFK - CarIDCreate Unique Constraint on Person and CarIDAny feedback is appreciated
We have an application that use merge replication between MSDE and Devices with SQL CE.
Due to a major application changes, we have to change our replication on all our workstation. Our process is the following:
- drop current replication
- recreate our replication
After first check our replication seems to work but after some test we have identify that all identity ranges have been reset on the workstation. As side effect, device start to reuse existing range and also existing value in the range.
Can a Primary Key column also be a Identity column? The reason I am asking this question is because I have created a table and each time I insert data into the Address Table I am also inserting the AddressID, how do I get the Primary Key (AddressID column) to self generate ID values.
