While trying to run an application install that needs to write to
master, it fails b/ c it cant create a new object id. So I followed the
instructions in article 827448 for this error:
Server: Msg 2714, Level 16, State 6, Line 1
There is already an object named 'TableName' in the database.
No matter how many times I run the recommended script and increment "i",
I cant seem to create a new object. My object id's are very sporadic.
Only the first 98 objects are in order. The next number jumps to
1,000,000 and the last object (object#1012) ends in 2,145,442,717.
Questions:
1. What can I do to create a new object?
2. What causes the object id's to be out of order like this? I don't
recall any huge deletes of objects. Certainly not 1,000,000 of them,
unless temp tables are given object ids?
3. Having object ids out of wack like this... does it cause any kind of
performance hit?
Thanks much!
Chris> While trying to run an application install that needs to write to master,
> it fails b/ c it cant create a new object id. So I followed the
> instructions in article 827448 for this error:
> Server: Msg 2714, Level 16, State 6, Line 1
> There is already an object named 'TableName' in the database.
> No matter how many times I run the recommended script and increment "i", I
> cant seem to create a new object.
The error seems to be that the table already exists. Why are you
incrementing "i"?
> 2. What causes the object id's to be out of order like this? I don't
> recall any huge deletes of objects.
An object_id is assigned arbitrarily by SQL Server. They are not
incremented linearly.
USE TempDB
GO
CREATE TABLE dbo.foo(id INT);
CREATE TABLE dbo.bar(id INT);
SELECT OBJECT_ID('dbo.bar'),OBJECT_ID('dbo.foo');
GO
DROP TABLE dbo.foo,dbo.bar;
GO
On my system, I get:
1870720859, 1854720802
When I run it again, I get:
59238408, 43238351
> Certainly not 1,000,000 of them, unless temp tables are given object ids?
I thought you were "writing to master"? Are you creating permanent tables
in master, or temp tables, or something else?
And yes, temp tables get Object_ids. Run this multiple times:
USE TempDB;
GO
CREATE TABLE #foo(id INT);
SELECT OBJECT_ID('#foo');
DROP TABLE #foo;
> 3. Having object ids out of wack like this... does it cause any kind of
> performance hit?
No, why would it? It's just an arbitrary lookup number. This is like
saying there would be a change in performance if your first name was Wanda
instead of Chris.
Maybe you could explain exactly what you are doing, why you are using a
counter like i and incrementing it, and what the actual failure is.
Aaron|||Hi Aaron,
I was following the instructions from this article:
http://support.microsoft.com/kb/827448/en-us
I thought object id's were assigned arbitrar numbers. I should have done
a simple test to confirm it (duh) ... but I was taking the word of a
developer. So I second guessed myself.
Aaron Bertrand [SQL Server MVP] wrote:
>>While trying to run an application install that needs to write to master,
>>it fails b/ c it cant create a new object id. So I followed the
>>instructions in article 827448 for this error:
>>Server: Msg 2714, Level 16, State 6, Line 1
>>There is already an object named 'TableName' in the database.
>>No matter how many times I run the recommended script and increment "i", I
>>cant seem to create a new object.
>
> The error seems to be that the table already exists. Why are you
> incrementing "i"?
>
>>2. What causes the object id's to be out of order like this? I don't
>>recall any huge deletes of objects.
>
> An object_id is assigned arbitrarily by SQL Server. They are not
> incremented linearly.
> USE TempDB
> GO
> CREATE TABLE dbo.foo(id INT);
> CREATE TABLE dbo.bar(id INT);
> SELECT OBJECT_ID('dbo.bar'),OBJECT_ID('dbo.foo');
> GO
> DROP TABLE dbo.foo,dbo.bar;
> GO
> On my system, I get:
> 1870720859, 1854720802
> When I run it again, I get:
> 59238408, 43238351
>
>>Certainly not 1,000,000 of them, unless temp tables are given object ids?
>
> I thought you were "writing to master"? Are you creating permanent tables
> in master, or temp tables, or something else?
> And yes, temp tables get Object_ids. Run this multiple times:
> USE TempDB;
> GO
> CREATE TABLE #foo(id INT);
> SELECT OBJECT_ID('#foo');
> DROP TABLE #foo;
>
>>3. Having object ids out of wack like this... does it cause any kind of
>>performance hit?
>
> No, why would it? It's just an arbitrary lookup number. This is like
> saying there would be a change in performance if your first name was Wanda
> instead of Chris.
> Maybe you could explain exactly what you are doing, why you are using a
> counter like i and incrementing it, and what the actual failure is.
> Aaron
>
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment