altering tables and constraints

I'm in the process of trying to convert a database such that all the strings
(VARCHAR) are converted to wide strings (NVARCHAR). I have a script that
accomplishes this by removing all the primary key constraints, converts the
necessary columns, and then replaces the constraints. The script walks the
sysnames table and stores all the constraints in a table variable, and
constructs a script to recreate all the constraings based on the 'xtype'
column from sysindexes (this is based on the system stored procedure
sp_pkeys). The script creates a constraint if the xtype is of type 'PK', or
creates an index based on the INDEXPROPERTY of the index, whether it be
unique, and either clustered or non-clustered.
This works for the most part, but I have found that there are constraints
being created on some columns that did not exist before the conversion. For
example, I have a table which has a primary key on it's identity columns
defined to automatically insert a new value at each insert incremented by 1.
After the conversion, there is an additional constraint placed on this table
which prevents a value of NULL from being added, which should be a problem
due to the IDENTITY column, yet attempting to do an insert on this table
generates an error saying that a NULL value cannot be inserted. I'm not
manually inserting anything, this should just bump the id value by one and
do the insert, but this new constraint prevents this, leaving me with a
table I can no longer insert into.
In another case, I have several varchar columns that have default
constraints (simple text strings), which are also dropped before conversion.
Upon replacing the constraints read from sysnames, I get similar errors
regarding not being able to insert nulls into these columns, which I didn't
get before, as these columns had default values.
My questions are, is it possible to exactly recreate constraints
programmatically? Is there a preffered method for converting databases from
narrow to wide character?
Thanks for any advice,
-GaryPlease do not post the same message to multiple newsgroups independently.sql

altering tables and constraints

I'm in the process of trying to convert a database such that all the strings
(VARCHAR) are converted to wide strings (NVARCHAR). I have a script that
accomplishes this by removing all the primary key constraints, converts the
necessary columns, and then replaces the constraints. The script walks the
sysnames table and stores all the constraints in a table variable, and
constructs a script to recreate all the constraings based on the 'xtype'
column from sysindexes (this is based on the system stored procedure
sp_pkeys). The script creates a constraint if the xtype is of type 'PK', or
creates an index based on the INDEXPROPERTY of the index, whether it be
unique, and either clustered or non-clustered.
This works for the most part, but I have found that there are constraints
being created on some columns that did not exist before the conversion. For
example, I have a table which has a primary key on it's identity columns
defined to automatically insert a new value at each insert incremented by 1.
After the conversion, there is an additional constraint placed on this table
which prevents a value of NULL from being added, which should be a problem
due to the IDENTITY column, yet attempting to do an insert on this table
generates an error saying that a NULL value cannot be inserted. I'm not
manually inserting anything, this should just bump the id value by one and
do the insert, but this new constraint prevents this, leaving me with a
table I can no longer insert into.
In another case, I have several varchar columns that have default
constraints (simple text strings), which are also dropped before conversion.
Upon replacing the constraints read from sysnames, I get similar errors
regarding not being able to insert nulls into these columns, which I didn't
get before, as these columns had default values.
My questions are, is it possible to exactly recreate constraints
programmatically? Is there a preffered method for converting databases from
narrow to wide character?
Thanks for any advice,
-Gary
Please do not post the same message to multiple newsgroups independently.

altering tables and constraints

I'm in the process of trying to convert a database such that all the strings
(VARCHAR) are converted to wide strings (NVARCHAR). I have a script that
accomplishes this by removing all the primary key constraints, converts the
necessary columns, and then replaces the constraints. The script walks the
sysnames table and stores all the constraints in a table variable, and
constructs a script to recreate all the constraings based on the 'xtype'
column from sysindexes (this is based on the system stored procedure
sp_pkeys). The script creates a constraint if the xtype is of type 'PK', or
creates an index based on the INDEXPROPERTY of the index, whether it be
unique, and either clustered or non-clustered.
This works for the most part, but I have found that there are constraints
being created on some columns that did not exist before the conversion. For
example, I have a table which has a primary key on it's identity columns
defined to automatically insert a new value at each insert incremented by 1.
After the conversion, there is an additional constraint placed on this table
which prevents a value of NULL from being added, which should be a problem
due to the IDENTITY column, yet attempting to do an insert on this table
generates an error saying that a NULL value cannot be inserted. I'm not
manually inserting anything, this should just bump the id value by one and
do the insert, but this new constraint prevents this, leaving me with a
table I can no longer insert into.
In another case, I have several varchar columns that have default
constraints (simple text strings), which are also dropped before conversion.
Upon replacing the constraints read from sysnames, I get similar errors
regarding not being able to insert nulls into these columns, which I didn't
get before, as these columns had default values.
My questions are, is it possible to exactly recreate constraints
programmatically? Is there a preffered method for converting databases from
narrow to wide character?
Thanks for any advice,
-GaryPlease do not post the same message to multiple newsgroups independently.

Alter Table - Add Constraint

Hi All,
Is there a way to SPEED up the process of alter table - Add constraint on a
table with PRE_EXISTING data? This is a LARGE table.
What I am trying to do here is REMOVE the old constraint and add a NEW
one...
Here is what I am figuring as a way to speed things up...
1) bcp out
2) drop constraints
3) truncate table
4) bcp in
5) add constraints
Found this link while searching past posts:
http://sqljunkies.com/WebLog/amacha...onstraints.aspx
Thanks...MALTER TABLE WITH NOCHECK
prevents the new restraint from checking existing data at add time.
"Michelle" <smiley2211@.yahoo.com> wrote in message
news:etvWhKyWFHA.3348@.TK2MSFTNGP14.phx.gbl...
> Hi All,
> Is there a way to SPEED up the process of alter table - Add constraint on
a
> table with PRE_EXISTING data? This is a LARGE table.
> What I am trying to do here is REMOVE the old constraint and add a NEW one
..
> Here is what I am figuring as a way to speed things up...
> 1) bcp out
> 2) drop constraints
> 3) truncate table
> 4) bcp in
> 5) add constraints
> Found this link while searching past posts:
> [url]http://sqljunkies.com/WebLog/amachanic/articles/ScriptTableConstraints.aspx[/url
]
>
> Thanks...M
>|||But note that it only applies for check and FK constraints.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Erik Moore" <erikmoore@.austin.rr.nospam.com> wrote in message
news:uUJn2lyWFHA.2060@.tk2msftngp13.phx.gbl...
> ALTER TABLE WITH NOCHECK
> prevents the new restraint from checking existing data at add time.
>
> "Michelle" <smiley2211@.yahoo.com> wrote in message news:etvWhKyWFHA.3348@.T
K2MSFTNGP14.phx.gbl...
>

Alter Table

I want to disable all the triggers of a data base (and enable all of then
after the execution of a process).
I can find out the name of the user tables looking for then in the
sysobjects table and then I can run "alter table <name> disable all" but I
have to repeat it with all the tables.
My question is: Can I write a store procedure to do this? I tried to do it
with a cursor with the name of all the tables but it doesnt't work because
the alter table expects a table name, not a variable.
Thank you.Hi,
Try out this script.
declare @.x varchar(255)
select @.x = @.x + 'alter table '+name+ 'disable trigger all'
from master.dbo.sysobjects where type='u'
exec (@.x)
go
Thanks
Hari
MCDBA
"Alberto" <alberto@.nospam.com> wrote in message
news:O9OY8kluDHA.2408@.tk2msftngp13.phx.gbl...
> I want to disable all the triggers of a data base (and enable all of then
> after the execution of a process).
> I can find out the name of the user tables looking for then in the
> sysobjects table and then I can run "alter table <name> disable all" but I
> have to repeat it with all the tables.
> My question is: Can I write a store procedure to do this? I tried to do it
> with a cursor with the name of all the tables but it doesnt't work because
> the alter table expects a table name, not a variable.
> Thank you.
>|||I thought you might need a cursor to do this. How can you tell what would
need a cursor and what would not ?
"Hari" <hari_prasad_k@.hotmail.com> wrote in message
news:u8VcsuluDHA.3140@.TK2MSFTNGP11.phx.gbl...
> Hi,
> Try out this script.
>
> declare @.x varchar(255)
> select @.x = @.x + 'alter table '+name+ 'disable trigger all'
> from master.dbo.sysobjects where type='u'
> exec (@.x)
> go
> Thanks
> Hari
> MCDBA
>
> "Alberto" <alberto@.nospam.com> wrote in message
> news:O9OY8kluDHA.2408@.tk2msftngp13.phx.gbl...
> > I want to disable all the triggers of a data base (and enable all of
then
> > after the execution of a process).
> >
> > I can find out the name of the user tables looking for then in the
> > sysobjects table and then I can run "alter table <name> disable all" but
I
> > have to repeat it with all the tables.
> >
> > My question is: Can I write a store procedure to do this? I tried to do
it
> > with a cursor with the name of all the tables but it doesnt't work
because
> > the alter table expects a table name, not a variable.
> >
> > Thank you.
> >
> >
>

ALTER PK

As I'm in the process of planning replication of two
tables to from one database in one location (country) to
another location (another country) I need to change the
tables using an ALTER TABLE statement so that the UNIQUE
index acting as the primary key, changed to a declared
primary key.
Since I will be applying this change to a live production
environment will there be any issues when applying this
change.
The key column is defined currently as:
data type: uniqueidentifier
allow nulls: no
default value: newid()
Thanks,
AnjelinaAnjelina
I don't see any negative issues if you are going to apply this change. If a
table is large then it will take time to arrange keys with ascending order.
BOL says:
"Creating a PRIMARY KEY or UNIQUE constraint automatically creates a unique
index on the specified columns in the "table
"anjelina" <ajturner@.canada.com> wrote in message
news:078701c38e21$cd144af0$a401280a@.phx.gbl...
> As I'm in the process of planning replication of two
> tables to from one database in one location (country) to
> another location (another country) I need to change the
> tables using an ALTER TABLE statement so that the UNIQUE
> index acting as the primary key, changed to a declared
> primary key.
> Since I will be applying this change to a live production
> environment will there be any issues when applying this
> change.
> The key column is defined currently as:
> data type: uniqueidentifier
> allow nulls: no
> default value: newid()
> Thanks,
> Anjelina
>|||If the primary key constraint will be a clustered index, all of the
non-clustered indexes will automatically be re-built. This can take some
time on a large table, and users will not be able to access the table
during this time.
Kick everyone off of the system prior to beginning.
drop the unique constraint.
then create the primary key constraint.
When complete, be sure to back up the database with a full or differential
backup.
--
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"anjelina" <ajturner@.canada.com> wrote in message
news:078701c38e21$cd144af0$a401280a@.phx.gbl...
> As I'm in the process of planning replication of two
> tables to from one database in one location (country) to
> another location (another country) I need to change the
> tables using an ALTER TABLE statement so that the UNIQUE
> index acting as the primary key, changed to a declared
> primary key.
> Since I will be applying this change to a live production
> environment will there be any issues when applying this
> change.
> The key column is defined currently as:
> data type: uniqueidentifier
> allow nulls: no
> default value: newid()
> Thanks,
> Anjelina
>

Alter Database while "Suspect"

Hi

I got the following error
Error: 823, Severity: 24, State: 4
I/O error 33(The process cannot access the file because another process has locked a portion of the file.) detected during write at offset
0x0000000a796000 in file xxxxxxxxx.ndf'.

and the respective database could not be brought online - this was just due to a problem with a .ndf file containing only indexes...is there any way to connect to/alter a database while it is in this transitional state? (it would be no loss if i could just remove the file & its filegroup)

(i tried starting with -f -c, but no go)

thanks in advance
desCheck in your virus scan software to see if it ignores *.mdf, *.ndf and *.ldf. I am assuming this is on startup of the database? Say after recycling the SQL Server service, or rebooting the machine?

Also, you will want to do some diagnostics on the disk (check with hardware vendor), in order to make sure the disk has not suddenly gone bad.

Good luck, and let us know what happens.|||What had happened was the folder/drive I put the index file on was set to compress contents (accidentally)...I figure the windows compression had a hold on it...happened after rebooting the machine (I thought it took real long to build those indexes - now i know why!)

Disk seems fine though...

Thanks for advice
cheers
des

(what happened ultimately was db loss & a 12 hour snapshot delivery...eughh. wish i couldve just removed the index file somehow...)|||I thought I read it somewhere not to use compression on any files SQL touches, maybe with the exception of the error logs. You can lock out any interactive access to the data and log folders to prevent future mishaps.

ALTER DATABASE dynamic SQL

I am in a bind.
I am writing a stored proc that needs to change the logical name of a
database as one step in the process. The issue is that I can't seem to pass
the database in a variable to the Alter Database command.
What are the options I have for making this work?
Code snippet:
DECLARE @.NewDB
@.NewDB = 'TestDB'
@.NewLogicalName = 'TestDB'
@.OldLogicalName = 'TemplateDB'
ALTER DATABASE @.NewDB <-- This generates an error
MODIFY FILE (
NAME = @.OldLogicalName,
NEWNAME = @.NewLogicalName
)
Thanks!!!!!
RSHRSH wrote:
> I am in a bind.
> I am writing a stored proc that needs to change the logical name of a
> database as one step in the process. The issue is that I can't seem to pa
ss
> the database in a variable to the Alter Database command.
> What are the options I have for making this work?
> Code snippet:
> DECLARE @.NewDB
> @.NewDB = 'TestDB'
> @.NewLogicalName = 'TestDB'
> @.OldLogicalName = 'TemplateDB'
> ALTER DATABASE @.NewDB <-- This generates an error
> MODIFY FILE (
> NAME = @.OldLogicalName,
> NEWNAME = @.NewLogicalName
> )
> Thanks!!!!!
> RSH
You will have to use EXEC for that. For example:
EXEC (@.alter_stmt)
Where @.alter_stmt is a string containing your ALTER DATABASE statement.
But why would you want to do such a thing in a proc?
David Portas
SQL Server MVP
--|||Thanks.
It is a long story but basically we have template databases and when a new
company is created we backup the template database and restore it to a new
name. It works good and everything changes except the Logical name so i
needed a way to change the logical name to the new database name.
This stems from the fact that our application was built using Access
databases in which this was standard procedure. We are moving over to SQL
and unfortunately we can't justify writing a few thousand lines of
application code, so we are stuck bending a few best practices here and
there to initially get things running.
Thanks,
RSH
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1133963892.610144.63210@.z14g2000cwz.googlegroups.com...
> RSH wrote:
>
> You will have to use EXEC for that. For example:
> EXEC (@.alter_stmt)
> Where @.alter_stmt is a string containing your ALTER DATABASE statement.
> But why would you want to do such a thing in a proc?
> --
> David Portas
> SQL Server MVP
> --
>|||RSH wrote:
> This stems from the fact that our application was built using Access
> databases in which this was standard procedure. We are moving over to SQL
> and unfortunately we can't justify writing a few thousand lines of
> application code
Experience suggests this is a recipe for failure. Virtually every
Access database I've ever seen is incompatible with good design in SQL
Server (or in most other database systems for that matter!). Wait until
you can justify rewriting it is my advice. No solution at all is
frequently better than a bad solution.
Good luck.
David Portas
SQL Server MVP
--|||> It is a long story but basically we have template databases and when a new
> company is created we backup the template database and restore it to a new
> name.
I use model for this. Life is much simpler (except when I need to create a
database that's not based on the template).
A|||RSH (way_beyond_oops@.yahoo.com) writes:
> It is a long story but basically we have template databases and when a new
> company is created we backup the template database and restore it to a new
> name. It works good and everything changes except the Logical name so i
> needed a way to change the logical name to the new database name.
But why would you worry about the logical name? If all files in all
databases have the same logical name, so what? Easier to manage, because
you always know what the names are. :-)
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||If the database named SALES_GA_2005 had a logical file name of SALES_FL and
physical name of SALES_2001.MDF, it could be confusing for the administrator
who manages the server.
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9725AFA87588BYazorman@.127.0.0.1...
> RSH (way_beyond_oops@.yahoo.com) writes:
> But why would you worry about the logical name? If all files in all
> databases have the same logical name, so what? Easier to manage, because
> you always know what the names are. :-)
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pr...oads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodin...ions/books.mspx|||I fixed it by calling the stored procedure Alter Database from my
application rather than parameterize it in a SP.
I agree in a perfect world it would be nice to re layout the DBs from
scratch and modify the application logic to utilize it...but the fact of the
matter is the people with the wallets want a solution and while it isn't
perfect it will work for the meantime. We are going to be porting our
application to .Net next year and that is when we are going to be revamping
things to take advantage of SQL server but until then we have to keep
generating revenue.
The logical name needs to be changed because I will still be referencing the
template database by name and I can't very well have 100 logical names all
the same...that would be quite an administrative nightmare.
Thanks for the help and insight.
:-)
"JT" <someone@.microsoft.com> wrote in message
news:eB$Odu0%23FHA.3464@.TK2MSFTNGP15.phx.gbl...
> If the database named SALES_GA_2005 had a logical file name of SALES_FL
> and physical name of SALES_2001.MDF, it could be confusing for the
> administrator who manages the server.
> "Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
> news:Xns9725AFA87588BYazorman@.127.0.0.1...
>|||> If the database named SALES_GA_2005 had a logical file name of SALES_FL
> and physical name of SALES_2001.MDF, it could be confusing for the
> administrator who manages the server.
Well, the intent was probably more like giving the logical file names a more
generic descriptor, like "data" and "log"... of course the MDF/LDF file
names would have to be unique, unless each pair is in its own folder.|||RSH wrote:
> The logical name needs to be changed because I will still be referencing t
he
> template database by name and I can't very well have 100 logical names all
> the same...that would be quite an administrative nightmare.
>
Are you sure you understand what the logical file name is? A database
is never referenced by its logical file name (for one reason because
there are at least two logical file names per database). The only time
you reference the logical name is if you need to change one of the file
properties such as size, location, growth, etc. In that case you always
need the database name as well. So I can't make sense of why it would
be an "administrative nightmare" to have the same names in each DB. In
some ways it makes things easier if you do this stuff dynamically.
I do agree that it makes sense to have a good naming convention but I'm
not convinced you understand what the logical file name is for.
David Portas
SQL Server MVP
--

Alter Column to IDENTITY

I used Select Into... to duplicate a table, but lost the IDENTITY and PK
constraints in the process. How do I get those back? Thanks.
Here are the details:
Original Table:
TABLE A (
[ID] INT IDENTITY PRIMARY KEY
, ColA smallint NOT NULL
, ColB varchar(20) NOT NULL
, ColC int NULL
, ColD numeric(38, 6) NULL
)
After SELECT * INTO TABLE_B FROM TABLE_A:
TABLE B (
[ID] INT NOT NULL
, ColA smallint NOT NULL
, ColB varchar(20) NOT NULL
, ColC int NULL
, ColD numeric(38, 6) NULL
)
I tried something like this, but it didn't work:
ALTER TABLE TABLE_B
ALTER COLUMN [ID] INT IDENTITY PRIMARY KEY> I tried something like this, but it didn't work:
> ALTER TABLE TABLE_B
> ALTER COLUMN [ID] INT IDENTITY PRIMARY KEY
You can't do this; T-SQL does not allow you to add or drop the IDENTITY
property. What you need to do can be better illustrated by performing the
action in Enterprise Mangler and viewing the code that it produces. It's
rather ugly, basically it creates a work table, moves all the data over,
drops the original and renames the new. All with a huge xlock, of course.
I shouldn't have to tell you what this means on a large-ish table.|||Short answer - you can't. But you can add a *new* identity column to the
table then drop the old column. Easiest way might be to make the change via
EM - design table and save the change script.
HTH
Jerry
"Boddhicitta" <Boddhicitta@.discussions.microsoft.com> wrote in message
news:6E0241AC-792C-4D1A-92E4-9CFCF99413AF@.microsoft.com...
>I used Select Into... to duplicate a table, but lost the IDENTITY and PK
> constraints in the process. How do I get those back? Thanks.
> Here are the details:
> Original Table:
> TABLE A (
> [ID] INT IDENTITY PRIMARY KEY
> , ColA smallint NOT NULL
> , ColB varchar(20) NOT NULL
> , ColC int NULL
> , ColD numeric(38, 6) NULL
> )
> After SELECT * INTO TABLE_B FROM TABLE_A:
> TABLE B (
> [ID] INT NOT NULL
> , ColA smallint NOT NULL
> , ColB varchar(20) NOT NULL
> , ColC int NULL
> , ColD numeric(38, 6) NULL
> )
> I tried something like this, but it didn't work:
> ALTER TABLE TABLE_B
> ALTER COLUMN [ID] INT IDENTITY PRIMARY KEY|||Drop the column and add it again as an Identity column
http://sqlservercode.blogspot.com/
"Boddhicitta" wrote:

> I used Select Into... to duplicate a table, but lost the IDENTITY and PK
> constraints in the process. How do I get those back? Thanks.
> Here are the details:
> Original Table:
> TABLE A (
> [ID] INT IDENTITY PRIMARY KEY
> , ColA smallint NOT NULL
> , ColB varchar(20) NOT NULL
> , ColC int NULL
> , ColD numeric(38, 6) NULL
> )
> After SELECT * INTO TABLE_B FROM TABLE_A:
> TABLE B (
> [ID] INT NOT NULL
> , ColA smallint NOT NULL
> , ColB varchar(20) NOT NULL
> , ColC int NULL
> , ColD numeric(38, 6) NULL
> )
> I tried something like this, but it didn't work:
> ALTER TABLE TABLE_B
> ALTER COLUMN [ID] INT IDENTITY PRIMARY KEY|||Thanks everyone. These are all kind of yucky for different reasons. Is
there a better way to copy a table and retain the constraints? DTS?
"Boddhicitta" wrote:

> I used Select Into... to duplicate a table, but lost the IDENTITY and PK
> constraints in the process. How do I get those back? Thanks.
> Here are the details:
> Original Table:
> TABLE A (
> [ID] INT IDENTITY PRIMARY KEY
> , ColA smallint NOT NULL
> , ColB varchar(20) NOT NULL
> , ColC int NULL
> , ColD numeric(38, 6) NULL
> )
> After SELECT * INTO TABLE_B FROM TABLE_A:
> TABLE B (
> [ID] INT NOT NULL
> , ColA smallint NOT NULL
> , ColB varchar(20) NOT NULL
> , ColC int NULL
> , ColD numeric(38, 6) NULL
> )
> I tried something like this, but it didn't work:
> ALTER TABLE TABLE_B
> ALTER COLUMN [ID] INT IDENTITY PRIMARY KEY|||Sure, create the table with the constraints in place, then insert the data
(specifying all columns except the identity column).
A
"Boddhicitta" <Boddhicitta@.discussions.microsoft.com> wrote in message
news:40361790-544E-4404-91B0-8F88D1F97B97@.microsoft.com...
> Thanks everyone. These are all kind of yucky for different reasons. Is
> there a better way to copy a table and retain the constraints? DTS?|||Try this:
CREATE TABLE B (
[ID] INT IDENTITY PRIMARY KEY
, ColA smallint NOT NULL
, ColB varchar(20) NOT NULL
, ColC int NULL
, ColD numeric(38, 6) NULL
)
GO
SET IDENTITY_INSERT B ON
GO
INSERT INTO B ([ID], ColA, ColB, ColC, ColD)
SELECT [ID], ColA, ColB, ColC, ColD FROM A
SET IDENTITY_INSERT B OFF
GO
"Boddhicitta" <Boddhicitta@.discussions.microsoft.com> wrote in message
news:40361790-544E-4404-91B0-8F88D1F97B97@.microsoft.com...
> Thanks everyone. These are all kind of yucky for different reasons. Is
> there a better way to copy a table and retain the constraints? DTS?
> "Boddhicitta" wrote:
>|||> Enterprise Mangler
LOL!! Thanks, I really needed that! HA HA HA HA!
Peace & happy computing,
Mike Labosh, MCSD
"When you kill a man, you're a murderer.
Kill many, and you're a conqueror.
Kill them all and you're a god." -- Dave Mustane|||Oops, typo. :-)
"Mike Labosh" <mlabosh@.hotmail.com> wrote in message
news:%23j9uk1O1FHA.3376@.TK2MSFTNGP14.phx.gbl...
> LOL!! Thanks, I really needed that! HA HA HA HA!|||While I grateful for the DDL, I hope that you are not you actaully
using IDENTITY as a key? FUNDAMENTA! WRONG ! Look for a relational
key.
Surely you had enough basic to know that code like "IDENTITY PRIMARY
KEY " means thart you have ABSOLUTELY NO CONCEPT OF RbMS.